Re: Draft Delegation for the Community Team
TL;DR: The concern Scott raises is a good one, and I think he caught me
out on a wording problem in the delegation text.
>>>>> "Scott" == Scott Kitterman <debian@kitterman.com> writes:
Scott> Constitution 5.1.4 give the DPL the power to "Make any
Scott> decision for whom noone else has responsibility." Some of
Scott> the items listed seem to be things that the DPL has
Scott> historically done, like "respond to concerns raised by
Scott> members of the project or people interacting with them".
In section 5.1.1, the constitution explicitly forbids the DPL from
second guessing a decision ("withrawing the delegation of the
decision is the wording used in the constitution) once *that
specific decision* is made by the delegates.
I think that's the thing that the DPL absolutely cannot do.
Similarly, I think that the DPL cannot delegate things that are under
the exclusive authority of individual developers, the TC, or the
secretary. Second guessing decisions or having the DPL violate those
separation of powers would be highly problematic.
Beyond that, I think we should assume flexibility in section 5.1.4 and
allow delegation text to be written either in a manner that precludes
the DPL from being involved while the delegation stands, or in a manner
that makes things be a shared responsibility.
If people decide to take a hard line on 5.1.4 and say that we cannot
write delegation text to permit the DPL and a team to work together on
an issue, then I'd be happy to try to get support to reword 5.1.4 after
my DPL term expires.
That said, it's often a very good idea for the DPL to hand something
over to a team and let them full control.
It empowers people and provides an important separation of
responsibility.
Scott> Have you assessed the potential constraints this delegation
Scott> might place on future DPLs? What is your perspective on
Scott> things the DPL has traditionally done that will now be
Scott> delegated to this team?
I did make that assessment and tried to write text that made it clear
which responsibilities were exclusive, but I think I misfired.
I think the following responsibilities are exclusive to the team:
>> * To coordinate responses (both inside and outside the project)
>> to ongoing harassment of the Debian community as a whole or
>> portions there-of; including working with additional volunteers
>> when the community team's members are insufficient.
The DPL can be involved, but the CT is leading this.
The CT gets to decide how involved the DPL is.
This year, DAM and DPL were leading a lot of the coordination with other
orgs, and turning this over to the CT is an explicit decision.
>>
>> * To work with event organisers to make sure that Debian Events
>> have adequate incident response teams to respond to any concerns.
I don't think DPLs have traditionally done this, and I think giving the
CT (and event organizers) seem like a good fit for this.
The following responsibilities are intended to be shared.
>> * To respond to concerns raised by members of the project or
>> people interacting with them, working with individuals to help
>> them.
my intent was that if you write to the DPL, the DPL responds.
If you write to the CT, the CT responds.
If you write to both, they cooperate.
I agree the above bullet doesn't say that; good catch on your part.
>> * To work with teams responsible for communications channels
>> within the community such as listmasters, the owner of the Bug
>> Tracking System, administrators of Debian Planet and others to
>> provide advice; where desired by these teams, helping to deal
>> with contentious and difficult issues that impact the community.
I think the DPL can provide advice if they like, and I think that bullet
is fine.
>> * To work with the DPL, Debian Account Managers and others to
>> provide advice on interpreting the Code of Conduct. Such advice
>> may form the basis of interpretations of the Code of Conduct that
>> help teams in the project set policy around community standards.
That was explicitly worded not to make it an exclusive responsibility of
the CT.
>> * To write reports to other teams such as the Planet Admins,
>> Listmasters, or Debian Account Managers in response to extreme
>> incidents or repeated patterns of problematic behavior.
It would be amusing if we could prevent anyone but the CT from writing
reports.
So, if this all makes sense, I'll try to work on wording for the first
bullet point that makes it clear you can still write to the DPL if you
like.
Thanks so much for bringing this up.
Reply to: