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 <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.
That all seems reasonable. Thanks, Scott K
signature.asc
Description: This is a digitally signed message part.