I agree the discussion is useful. Let's start by adding the ASF CoC and some Q&A about it to the website, point to that page in the monthly roundup for April and gradually adjust when we need to. About the "discuss every so often": are there any ASF guidelines on this, e.g. add a (very brief) section about CoC related items to the podling reports?
On Mon, Apr 12, 2021 at 11:50 PM Julian Hyde <[email protected]> wrote: > The “welcome bot" is a nice idea. But I also think discussions such as > this email thread are very useful - they remind people that we care about > making this a welcoming place. Let’s have these discussions every so often > - and not just when there has been an issue. > > I forgot to mention that some projects *do* have their own code of > conduct, so we don’t have to stop with the ASF one. (In fact CouchDB had > one first [2], and the ASF adopted it foundation-wide.) > > Julian > > [2] https://couchdb.apache.org/conduct.html > > > On Apr 12, 2021, at 12:33 PM, Bart Maertens <[email protected]> > wrote: > > > > We talked about adding a welcome bot to the chat a while back. > > That needs to happen anyway (will start a different thread), could be a > > good opportunity to point new joiners to the ASF CoC. > > > > There could be bot options for periodic reminders, or to let folks > > acknowledge (once) they've read and agree with the CoC. We'll need to > look > > into it. > > > > Regards, > > Bart > > > > > > > > > > > > > > On Mon, Apr 12, 2021 at 9:08 PM Matt Casters <[email protected] > .invalid> > > wrote: > > > >> Thanks for the link Julian. We should do our best to communicate that > >> we're following this CoC policy as a sort of constant reminder. > >> Adding it to our community pages on the website is great. Perhaps > periodic > >> reminders by a chat bot? > >> > >> Cheers, > >> Matt > >> > >> On Mon, Apr 12, 2021 at 5:46 PM Julian Hyde <[email protected]> wrote: > >> > >>> Thanks for starting this conversation, Matt. FYI, ASF has a CoC [1] > >>> and it automatically applies to the Hop community, but it's great if > >>> Hop wants to extend it with its own culture/values. > >>> > >>> Julian > >>> > >>> [1] https://www.apache.org/foundation/policies/conduct > >>> > >>> On Mon, Apr 12, 2021 at 7:40 AM Matt Casters > >>> <[email protected]> wrote: > >>>> > >>>> Dear Hoppers, > >>>> > >>>> In our short history we've been on the receiving end of very little > >>>> negative feedback. It's been a very fun experience to help each other > >>> out > >>>> and the source code in general is very accomodating to doing your own > >>> thing > >>>> in your own plugin without getting in the way of others. > >>>> > >>>> However, when negative feedback does come on occasion (it does and it > >>> will) > >>>> we need to be a bit more prepared for it. As such I would like to > >> have > >>> a > >>>> developer/community "code of conduct" on our website so that we can > >> help > >>>> people to react appropriately to negative feedback. > >>>> > >>>> I believe that in essence any conflict in software or architecture is > >> an > >>>> opportunity for improvement. I would very much like such an attitude > >> to > >>> be > >>>> the leading principle in this scenario. > >>>> > >>>> Can we come up with a list of advice for recipients of negative > >> feedback? > >>>> Or perhaps a checklist? > >>>> > >>>> - Take a deep breath, read the message a few more times. Do not reply > >>>> immediately. > >>>> - If you can not give a constructive response, consider not responding > >> at > >>>> all or with a question asking for clarification. > >>>> - Empathically consider that the person in question is perhaps > >>> frustrated / > >>>> using a foreign language / stressed out / in a pinch / ... > >>>> - If you feel you are bothered by the feedback; can you figure out > >>>> why exactly this is? The tone of the feedback should be disregarded. > >>> Its > >>>> actual content should be taken seriously. > >>>> - Consider the opportunities for improvement of our software. A lot > of > >>>> people take software as is and are not even aware that we can fairly > >>>> quickly change a lot of things. > >>>> - Consider creating JIRA cases based on the feedback to capture > >> negative > >>>> feedback with bug reports, improvements or even taks for architectural > >>>> changes. > >>>> > >>>> Anyway, feel free to pile on. > >>>> Cheers, > >>>> Matt > >>> > >> > >
