[This lengthy message resists summary, so I offer a single "pull quote"
in lieu thereof.
The delegation mechanism is not primarily for the benefit of the
delegates. Delegation exists to benefit the DPL and the Project.]
Hi Richard, Julian, Andreas, Gerardo, Gianfranco, and Soren,
I'm arranging this message to reply first to the DPL candidate who
directly responded to my questions (and two who did so indirectly), on
the premise that a dialogue with the DPL candidates is of greater
general interest to this list's subscribers.
At 2025-03-25T22:30:05+0100, Andreas Tille wrote:
> Am Tue, Mar 25, 2025 at 12:06:31PM -0500 schrieb G. Branden Robinson:
> > Thanks to Andreas, Gianfranco, and others for pointing out that my
> > questions to the candidates would be improved by question marks.
> >
> > As Debian Project Leader (DPL),
> >
> > 1. Will you remove the words "and Code of Conduct violations" from
> > the Community Team delegation charter?
>
> No, I believe the inclusion of "and Code of Conduct violations" is
> important for maintaining a clear understanding of the scope of the
> Community Team's responsibilities. Removing these words could
> potentially create ambiguity about the team's role in addressing such
> violations.
My impression from multiple messages to the -private list is that the
ambiguity already exists, and the recently published Community Team FAQ
doesn't do as much as it could; that team does not pledge that future
communications will clearly state that the team does _not_ allege a Code
of Conduct (CoC) violation.
The intention of my proposal is to rectify ambiguity by removing CoC
enforcement from the Community Team's delegation. If a member of that
team wants to raise such a charge, they would be doing so without more
authority than any other Developer, or concerned member of the public.
We should admit that if someone who is a "big deal" in the Project
accuses a "lesser deal" of a CoC violation, witnesses are likely to
perceive greater authority in the allegation anyway. A thumb rests on
the scale already; in my view, we don't need to attach the weight of
delegated authority to it, when DAM and mailing list administrators are
already tasked with handling disciplinary responses to CoC violations.
> > 2. Will you articulate a policy that no Debian Developer shall
> > occupy more than one delegated role at a time?
>
> I would gladly suggest this as a general guideline rather than a
> strict policy. However, this would only be feasible if we had a large
> pool of willing and qualified volunteers to fill delegated roles,
> which is currently not the case.
How aggressively have we recruited?
Might volunteers be discouraged from pursuing a role on certain teams
because they are intimidated by the current membership, and/or perceive
the team to be poor at practicing the levels of camaraderie and
collaboration one otherwise associates with the term "team"?
> Moreover, I do not see a strong need for such a policy as long as
> holding multiple delegated roles does not create a conflict of
> interest.
How do we discern potential or actual conflicts of interest?
Do we have any guidelines to aid us in such a determination?
> > 3. Will you ask any Debian Developers enjoying multiple delegations
> > to resign from all but one of their choice?
>
> No. See my answer to 2.
Acknowledged.
> > 4. Will you establish a policy that all delegations made by the
> > Debian Project Leader shall be renewed no less frequently than
> > once per DPL term?
>
> No, I do not see a need for this policy. Delegations should be made
> based on the needs of the project, and there is no reason to set a
> rigid renewal timeline if the current delegates are doing their work
> effectively.
How do you measure the accomplishment of effective work by delegates?
Referring again to <https://www.debian.org/intro/organization>, how many
of these delegates (or their teams) have accounted for themselves to you
or to the Developers in the past year?
If you don't know, shouldn't you? Can you make a confident guess off
the top of your head? If not, it seems likely to me that some
delegations have been permitted to languish, perhaps for years.
I note that "accounting for themselves" could take a variety of forms.
A periodic "Bits from the XXX" email to a relevant Project mailing list
is only one possible vehicle. A self-updating Web-based "dashboard"
that records a team's relevant activities is another.
The _mechanism_ of accountability should not be burdensome to delegates;
however, a hazard exists that a delegate who has served for a long time
with few expectations comes to regard the _fact_ of accountability
itself as burdensome. Such an attitude jeopardizes the Project.
> > 5. Will you continue the practice that team delegation
> > announcements by the DPL implicitly withdraw the delegations of
> > any sitting team members not mentioned in that same delegation
> > announcement?
>
> Yes, I would continue this practice, as it is an established method of
> communication. Since this is already explicitly stated, I see no need
> to change it.
I appreciate your candid and forthcoming responses.
At 2025-03-25T22:10:25+0100, Julian Andres Klode wrote:
> On Tue, Mar 25, 2025 at 03:53:24PM -0500, Richard Laager wrote:
> > On 2025-03-25 12:06, G. Branden Robinson wrote:
> > > 2. Will you articulate a policy that no Debian Developer shall
> > > occupy more than one delegated role at a time?
> > >
> > > 3. Will you ask any Debian Developers enjoying multiple
> > > delegations to resign from all but one of their choice?
[see below for Richard's message]
> It's also quite frankly silly in a whole lot of cases:
This characterization does not constitute serious comment; it is
dismissive and unhelpful to voters' understanding of the issues.
> Outreach and Publicity Teams, Treasury, why should I not be a part of
> the publicy team and the treasury?
A prospect that springs to mind is that publicity activities frequently
cost money, sometimes unavoidably so. But I admit I don't know enough
about the real activities of the publicity team, or of what, if any,
costly publicity efforts the DebConf committee undertakes to promote our
annual conference.
> I also think in some cases more overlap would be helpful, such as
> release team and ftpteam.
Can you be more specific about where you see potential synergy here?
> And I don't understand for the life of me why we would not want
> ftpmasters to be in the backports team or the tag2upload delegates.
Given recent developments, those concerns would appear to have separated
themselves. In any case, if you peruse Ian Jackson's mail from earlier
today,[1] I think you'll see that the barrier to tag2upload's progress
appears not to be of the sort that concerns you; Sean Whitton enjoyed
delegations to both teams yet _still_ was frustrated in advancing the
tag2upload state of affairs. If Ian's summary is accurate, it is hard
to imagine how making the entire existing archive administration team
simultaneous tag2upload delegates would have helped.
Your imagination may prove richer than mine.
At 2025-03-26T10:04:13+0000, Gianfranco Costamagna wrote:
> >Some people will practice poor judgment and/or self-control when
> >reading what you write. As DPL, you will find you have more such
> >readers. As with data compression, there is a limit to how much you
> >can help them. They, not you, are responsible for how they behave.
>
> I agree, but we need also to deal with people lifes, consider that we
> have hundreds of people reading us, so every word is a time loss for a
> huge list of people, and a risk of them not reading at all (as said by
> multiple people). "Repetita iuvant", but not in this case :) (and I'm
> not referring to young people, with an attention span of 5s)
Indeed not. I'm as concise as I can manage, knowing that when I offer
any observation longer than a Tweet, I invite stern critique.
> We can't satisfy everybody's needs, we need to try to satisfy the
> majority of them whenever is possible.
I don't think a majority has been established with statistical
reliability in this case.
> You two can engage a private discussion and enjoy writing a summary of
> it :)
Because I am talking about Debian's problems and how we might use our
mechanisms of governance to address them, I would prefer to keep the
discussion public.
See item 3. <https://www.debian.org/social_contract>
> >1. Will you remove the words "and Code of Conduct violations" from
> > the Community Team delegation charter?
>
> No. I disagree. To me Community Team should have more power, and maybe
> be tied together with DAM to better understand who should be in charge
> of handling every specific situation (like one single email, and then
> an answer as a single team with the action taken). I have been
> bounced back and forth by DAM/CT for an issue I arised years ago, to
> me this looks like a bad experience for a contributor, it would be
> really better to have one single team, or to just let the two teams
> cooperate together more closely (maybe some delegate might join both
> teams or other ideas).
You say "let" the two teams cooperate more closely. In your assessment
as a DPL candidate, what do you perceive the existing barriers to their
cooperation to be? Before asserting contra my proposal that the wording
of either or both teams' delegation charter is a barrier, I would urge
you to consider others, and to marshal evidence to support your view,
whatever factors you identify.
> >2. Will you articulate a policy that no Debian Developer shall
> > occupy more than one delegated role at a time?
>
> No, if there are specificy roles that can conflict with others, the
> DPL shall not appoint the person,
Where is that written?
> on a case-by-case analysis.
Have any such case-by-case analyses ever been recorded and shared with
the Developers?
> Ubuntu has many people with different roles, as well as Debian, and as
> long as people can follow all the topics, this is ok by me. (unless
> you have *specific* cases to tell, nobody can generally answer a yes)
I'm afraid I didn't understand this part of your answer (after
"Debian,"). Can you please recast it?
I could answer "yes" to the question, if I were a DPL candidate.
> >3. Will you ask any Debian Developers enjoying multiple delegations
> > to resign from all but one of their choice?
>
> No, but I already answered above, we should check conflicts of
> interests on a case-by-case basis and at the end,
I'll ask you what I asked Julian:
How do we discern potential or actual conflicts of interest?
> if somebody is harmful to the project because of multiple delegations,
> the answer becomes yes for them, not in general.
What is our procedure for making this determination? Has it ever been
made before? Do you think it has ever been the case before, regardless
of any overtly expressed determination by the DPL or a Developer?
> >4. Will you establish a policy that all delegations made by the
> > Debian Project Leader shall be renewed no less frequently than
> > once per DPL term?
>
> why? If a team is not working as expected the DPL should delegate new
> people.
Yes. How do we know when a team is or is not working as expected? What
evidence do we have that the Debian Project is reliable at replacing
failing or overworked delegates in a timely manner?
> Having such a rule won't be beneficial for the Team itself.
I think it would be. I think it would help delegates to recognize when
their level of investment in the role is declining.
Also, the delegation mechanism is not primarily for the benefit of the
delegates. Delegation exists to benefit the DPL and the Project.
> >5. Will you continue the practice that team delegation announcements
> > by the DPL implicitly withdraw the delegations of any sitting
> > team members not mentioned in that same delegation announcement?
>
> yes, the new delegation automatically deletes all previous delegates.
Thank you for addressing all of my proposed reforms.
> > Can you expand on this? What new roles would you like to see? What
> > new powers do you envision for (delegated) teams? Are these powers
> > within the DPL's capacity to grant?
>
> CT/DAM
I understand you to mean that you'd like to see these teams enlarged
and/or combined.
> >I believe that is already the case, with the sole exception of §4.2.4
> >of the Constitution, which grants the DPL a "casting" (tie-breaking)
> >vote in the "Standard Resolution Process" (including GRs)
> <https://www.debian.org/devel/constitution#item-4>.
>
> yes, this is why I would say that many of the questions are not DPL
> related. we have GR for changes, and this is the preferred form of
> changing things in Debian.
I don't think this is true. I perceive a widespread (but not universal)
reluctance to exercise the GR process. Consider Soren Stoutner's
proposal to put some technical points of email formatting to a GR; he's
heard feedback with a tone nearing anguish. Some people evidently feel
that employing the GR process for that question is a waste of resources.
Debian does not govern itself like a parliament.
I counter-propose that the preferred means of changing a thing in Debian
is to wait until someone volunteers to change it, and if no volunteer
arises, then collectively we're prepared to wait forever.
> As a DPL, I wouldn't enforce any GR without asking for sponsors.
I'm not sure you mean the word "enforce" here. The DPL cannot rule by
decree, but the office is uniquely empowered to propose GRs without
sponsorship. The DPL cannot, however, make them pass.
See Debian Constitution §5.1.5, "When proposed by the Project Leader,
sponsors for the General Resolution or ballot option are not required;
see §4.2.1."[2]
> Having sponsors is a good thing to make sure the GR is useful for the
> project, and I would like to not use this power.
That's likely not a disadvantageous admission; my understanding is that
the §5.1.5 power has been exercised rarely. I never used in it my term.
> >I disagree. When we can assume good faith as the Code of Conduct
> >advises us to do, conflicts arise because people care about things.
>
> yes, but DPL should be "super partes", whenever possible. As already
> said, DPL welcomes everybody on the project, regardless of their view
> on specific topics. This has to be clear.
I agree. Viewpoints should not (cannot?) disqualify a person from
participation in the Debian Project; only bad conduct can do so.
> And DPL should try to conciliate parts and different views, instead of
> participating on flame wars. (this is a general discussion, without
> specific examples, I guess the answer doesn't make much sense)
I think you've identified a problem with trying to remain above the
fray. Sometimes a community is better served by resolving a dispute,
especially one that proven resistant to resolution via discussion, than
by enduring further sustained contest over it. I wasn't around for the
init system conflict, but was aware of it despite my disengagement from
the Project, thanks to LWN and other resources.
That episode I have seen described as the single most traumatic thing
the Project has ever dealt with. That's consistent with my perception
that, culturally, Debian is notably conflict-avoidant...and not in a
healthy way.
> Flame wars is when people don't assume good faith, when they use
> the wrong wording.
I don't think everybody shares your definition. I've been informed that
an email message length above some unstated threshold satisfies the
criterion of "flaming", no matter how mild its emotional register.
> We can disagree on what we write, but good faith and good behaviour
> must be the baseline of *every* discussion (I, as example, don't agree
> with anything you wrote, but I don't call my answer a flame war)
I wouldn't call it that either. But I do point out that you did
manage to agree with a point of mine nevertheless. ;-)
> Conflict are a good thing, because they express democracy, different
> point of views, discussions, and resolution to something better. I
> like conflicts, as long as they are constructive.
[content warning: history of mathematics]
I think reality is even more complicated, and point to Bishop Berkeley's
critique of Newton and Leibniz's foundation of calculus on the concept
of infinitesimals. Berkeley did not argue in good faith, resorting
frequently to ridicule, and predicated his attacks on ulterior motives,
perceiving the development of mathematical analysis as a threat to his
theological belief that God directs the motion of every particle in the
cosmos. We can say that he shouldn't have done so, but his mockeries of
missing rigor in the foundations of calculus in his day did motivate
mathematicians to undertake research to rebut him. Cauchy and
ultimately Weierstrass refuted Berkeley's _stated_ arguments,[3] and
nowadays we have an equally rigorous nonstandard analysis that has
redeemed infinitesimals, thanks to Abraham Robinson and others.
That said, if one wants to resolve a conflict on a time scale shorter
than centuries, _constructive_ conflict is likely the better route.
> voicing a view might be also ask people to step down, take some rest,
Yes. Hence my proposals 2, 3, and 4.
> If I hear two people fighting over system* init system, I can give
> advice to ask Technical Committee, open a GR, ask to change wording,
> say that flame wars and bad wording won't help a technical discussion
> in any way. This answer won't expose my POV on that topic. People
> should be aware of the fact that good behaviour is what we should
> pursue in our discussions regardless of the outcome. We had many toxic
> people in the project in the past, and to me, the project gained from
> their expulsion (but, if they want to come back with a less disruptive
> behaviour, they are free to join back). Forgiveness is also something
> we should try to enforce as personal behaviour.
Your capacity for optimism is laudable.
> >To be clear: my observation that a DPL can fail to lead is not a
> >condemnation of anyone. The role faces many problems and challenges.
> >I think every DPL likely fails to lead in one way or another, and in
> >some cases we're better off that they fail. The DPL cannot solve all
> >of our problems for us--only some. That is why my questions focus on
> >the DPL's specific powers under the Debian Constitution.
>
> Every DPL, will fail everytime in something, but I don't think more
> changes in Constitution will help in any way
I'm confused. Who proposed a change to the Debian Constitution lately?
> More rules won't make the job easier, at least in general
See my comments above regarding things that we should be measuring that
we seem not to be. Such tools for measurement could be characterized as
"rules", and yet could be beneficial.
> >I'm not sure the reason is all that good. The default mode of the
> >Community Team's messages, we were recently told, is that a Code of
> >Conduct violation is _not_ being asserted
> ><https://wiki.debian.org/Teams/Community/FAQ>. A friendly email can
> >be sent publicly. If it's not friendly, then yes, a private channel
> >may be more appropriate. The fact of an un-friendly outreach by the
> >CT should be logged and reported (with personally identifying
> >material disclosed only to the DPL or debian-private list).
>
> I agree
You agreed with something I said after all. ;-)
> >B. Item 2 reflects the possibility that any clarity that item 1
> > brings can be forfeit if any member of the Community Team is also
> > empowered through independent delegation to exercise disciplinary
> > powers that members of the Community Team emphasize that they do
> > not possess. It also alleviates the potential for a conflict of
> > interest via the exercise--or the selective neglect--of
> > non-disciplinary delegated powers as a proxy for disciplinary
> > ones.
> >
> > If Item 1 is not adopted, I think Item 2 becomes more pressing,
> > not less.
>
> why not propose a GR on this?
I don't yet perceive it as necessary.
> To me CT/DAM should be one bigger team, not two different, and
> internally they should have a way to vote/not vote/act on a
> case-by-case basis.
How would we know if they exercised such a process?
> we are volunteers, there is always lack of people, so this is
> theoretically possible and a good thing, but pratically, enforcing
> this might be an harm in the future if not enough people are found to
> cover all the roles.
Why not undertake an experiment that can tell us if our limiting factor
is the quantity of unique volunteers rather than the resources available
to the 103 existing delegates, ~40% of whom bear multiple delegations?
> This might be a good idea, to ping people once a year, and ask if they
> still have bandwith to fullfill the role responsibilities.
We might have found ourselves in agreement on a second point. ;-)
At 2025-03-25T15:53:24-0500, Richard Laager wrote:
> On 2025-03-25 12:06, G. Branden Robinson wrote:
> > 2. Will you articulate a policy that no Debian Developer shall
> > occupy more than one delegated role at a time?
> >
> > 3. Will you ask any Debian Developers enjoying multiple delegations
> > to resign from all but one of their choice?
>
> I have some concerns about this.
>
> It seems like this could just lead to broader delegations. For
> example, instead of having "General Team" with A, B, C, D, & E, and
> "Specific Team" with A, B, and C, just drop the "Specific Team". For a
> partially made-up example, imagine we had system administrators and
> then separate sub-teams for different subsets (e.g. web sysadmins,
> email sysadmins). Forcing an "only one delegation" rule here doesn't
> help anything, as the DPL would just eliminate the sub-teams in favor
> of one overall team. Where the subteams are used to limit access, this
> change would thus violate the Principle of Least Privilege.
That's a reasonable concern and not just the DPL but the Developers
should look upon overbroad or overpowered delegations with concern.
I would therefore bring to your attention two points that I think make
your concern less concrete than it would otherwise be.
A. Item 1 from the mail to which you responded, which envisioned
explicitly narrowing the scope of an existing delegation to better
fit what seems to be, based on admittedly limited evidence, the
preferences of the that team as currently constituted.
B. In a thread that has started on this list since this one,[4] Sean
Whitton pointed out that the package archive administration team has
(at least) a dual portfolio: copyright license evaluation, a highly
specialized discipline; and maintenance, development, and operation
of the software that manages the life cycle of a Debian package in
the archive. Sean stressed that people with skill and interest in
undertaking both of those roles are scarce.
> Additionally, the fact that people are wearing multiple hats probably
> indicates that was necessary to get the job done. There are 142
> person-delegations to 103 persons. [1]
[...]
> [1] https://www.debian.org/intro/organization
Thanks for citing this resource.
I would venture instead that this figure represents about 39 missed
opportunities to give newer, younger Debian Developers some experience
with delegated authority.
> Losing the duplicates seems like it would negatively impact the
> available volunteer time.
I don't think that necessarily follows; it could also be the case that
volunteer time is available but not being exercised because it is idling
in people who want to contribute more and/or differently to the Project,
but find unfulfilling the prospect of adopting yet another package.
At 2025-03-26T10:24:24+0100, Gerardo Ballabio wrote:
> G. Branden Robinson wrote:
> > I'm curious: has anyone been in touch with you privately to advise
> > you against seeking that information?
>
> No. I didn't get any feedback in private about my message.
Thanks for the reassurance.
At 2025-03-27T11:47:06-0700, Soren Stoutner wrote:
> So, the point I was making is that those who were being rude while
> claiming the emails were too long were committing an obvious breach of
> the Code of Conduct, much worse than any problems caused by the length
> of the emails they were responding to.
That may be, but it could also be that some episodes of rudeness get a
"free pass", if they are conducted against certain Developers, or
expressed in opposition to a collectively disfavored viewpoint.
> "In a project the size of Debian, inevitably there will be people with
> whom you may disagree, or find it difficult to cooperate. Accept that,
> but even so, remain respectful. **Disagreement is no excuse for poor
> behaviour or personal attacks**, and a community in which people feel
> threatened is not a healthy community."
I can only point to (relatively) recent list traffic on -private.
Regards,
Branden
[1] https://lists.debian.org/debian-vote/2025/04/msg00003.html
[2] https://www.debian.org/devel/constitution#item-5
[3] I recommend Judith Grabiner's book on the subject.
[4] https://lists.debian.org/debian-vote/2025/04/msg00006.html
Attachment:
signature.asc
Description: PGP signature