On Friday, April 10, 2020 9:14:43 AM EDT Sam Hartman wrote:
> 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.
That all seems reasonable. Thanks,
Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.