On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: I join other respondents, with a risk of redundancy, with a few notes due to the decision of not having delegated powers and being an undelegated advisory group.
> The (CT) is the team responsible for interpreting the Code of Conduct > (CoC) when necessary. I feel strongly against this: "The team" hints at being the only team, and "Responsible" hints at having power. I believe strongly that anyone who is /the/ person/team responsible for interpreting the Code of Conduct needs to gain that responsibility from an official delegation, and absent a delegation, I believe that the only person ultimately responsible for interpreting the CoC when necessary is the DPL, overridable by a GR. However, I also believe that any member of the Debian community is responsible for upholding the Code of Conduct, and I'm fine with the idea that one or more people or groups could make themselves available to help with CoC interpretation or supporting people if things get heated. At that point, however, the CoC interpretation is not a responsibility but an offer of help, whose value can maybe come from experience and reputation of a person or team members inside the project. > Finally, the CT will also work in combination with event organisers to > deploy incident response teams on the ground and ensure that the CoC > is observed for Debian events. In the same light as above, I suggest s/work/make itself available/, as any other group could make themselves available to event organisers to help with Debian or event-specific CoC. > Responsibilities include > ======================== I agree with what Mathias Behrle wrote about this session. > Examples of things the team does *not* do > ========================================= > > * Remove blogs from community forums like Planet Debian This I think is something the team could actually do, just as any Debian Developer could do it, having commit access to the planet config. > * Take punitive measures or actions against members of the Community. I find this point a bit tricky, because I think that what is "punitive" is up for subjective interpretation. For example, feeling forced to engage with individuals wearing a Community Team badge could already be seen by some as a punitive measure. You may want to remove this point entirely, as it's mostly covered by the other examples of what the team does not do. - - - Some more general feedback points. I suggest to review your notes with the idea that there could be two or more such teams in Debian posting the same set of notes, and they shouldn't conflict. Also, given the idea that there can be multiple groups doing this, the name "Community Team" sounds possibly problematic name to me, as it hints indeed at being /the/ team for Debian Community issues, which could potentially be setting the wrong kinds of expectations. Although I would prefer a name that would make it explicit that we're talking about /a/ /self-appointed/ group, I wouldn't consider the naming a blocker: I know names are hard, and I don't want you all to spend your energy picking names. Still, I'd acknowledge and keep in mind that the name does sound ambitious, and as a consequence I'd expect you all to be extremely careful in all team descriptions and team actions to make it clear that you are /a/ community team, not /the/ community team. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: PGP signature
