There are no ASF guidelines for this, just my personal opinion: we should not just publish a CoC, we should live our values.
As for the podling reports (and the board reports, when Hop graduates), whoever writes the report should be thinking about the health of the community. If someone has been trolling the lists, or if a discussion among community members has become so heated that members have left the community, or if the community isn’t diverse and inclusive, then we need to fix something. In Calcite, we elect a new PMC chair every year (on the anniversary of graduation) and around the same time we have a “state of the project” discussion covering everything from technical goals to the state of the community. This is not required by ASF policy (in fact Calcite is the only project that does this) but in my opinion it works well, because it helps keep our thinking fresh. Julian > On Apr 12, 2021, at 10:51 PM, Bart Maertens <[email protected]> wrote: > > 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 >>>>> >>>> >> >>
