>>>>> "Enrico" == Enrico Zini <enr...@enricozini.org> writes:
Enrico> On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote:
Enrico> I join other respondents, with a risk of redundancy, with a
Enrico> few notes due to the decision of not having delegated powers
Enrico> and being an undelegated advisory group.
>> The (CT) is the team responsible for interpreting the Code of
>> Conduct (CoC) when necessary.
Enrico> I feel strongly against this: "The team" hints at being the
Enrico> only team, and "Responsible" hints at having power.
Enrico> I believe strongly that anyone who is /the/ person/team
Enrico> responsible for interpreting the Code of Conduct needs to
Enrico> gain that responsibility from an official delegation, and
Enrico> absent a delegation, I believe that the only person
Enrico> ultimately responsible for interpreting the CoC when
Enrico> necessary is the DPL, overridable by a GR.
Enrico> However, I also believe that any member of the Debian
Enrico> community is responsible for upholding the Code of Conduct,
Enrico> and I'm fine with the idea that one or more people or groups
Enrico> could make themselves available to help with CoC
Enrico> interpretation or supporting people if things get heated.
I strongly support the above.
It's going to be a day or two before I get a chance to comment on the
team's proposal.
I think that interpreting the CoC is something that requires a
delegation.
I think that ultimately the project could use interpretation of the CoC
in some cases, and that eventually a delegated community team will be
something the project needs.
>> 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.
Enrico> In the same light as above, I suggest s/work/make itself
Enrico> available/, as any other group could make themselves
Enrico> available to event organisers to help with Debian or
Enrico> event-specific CoC.
This is an area where I actually think the project needs a single
delegated entity to coordinate IRTs with events.
I agree with Enrico that being *the entity* is not something that an
individual group of developers can do.
But I think that there are significant advantages in having project-wide
consistency in how we approach IRTs and to do that, I think a delegation
would be necessary.
Enrico> Some more general feedback points.
Enrico> I suggest to review your notes with the idea that there
Enrico> could be two or more such teams in Debian posting the same
Enrico> set of notes, and they shouldn't conflict.
Enrico> Also, given the idea that there can be multiple groups doing
Enrico> this, the name "Community Team" sounds possibly problematic
Enrico> name to me, as it hints indeed at being /the/ team for
Enrico> Debian Community issues, which could potentially be setting
Enrico> the wrong kinds of expectations.
Enrico> Although I would prefer a name that would make it explicit
Enrico> that we're talking about /a/ /self-appointed/ group, I
Enrico> wouldn't consider the naming a blocker: I know names are
Enrico> hard, and I don't want you all to spend your energy picking
Enrico> names.
Enrico> Still, I'd acknowledge and keep in mind that the name does
Enrico> sound ambitious, and as a consequence I'd expect you all to
Enrico> be extremely careful in all team descriptions and team
Enrico> actions to make it clear that you are /a/ community team,
Enrico> not /the/ community team.
Enrico> Enrico
Enrico> -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Enrico> <enr...@enricozini.org>
