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 <deb...@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.