[this message is long; no one requires you to read it] Hi Andreas, Gianfranco, Matthias, and Gerardo, At 2025-03-21T09:00:23+0100, Andreas Tille wrote: > Please take my deliberate silence as a signal that, as a potential > DPL, I am not willing to reinforce a pattern that has been frequently > criticized. Use of passive voice makes your meaning unclear. Who has made criticisms, and which (of many possible) patterns do you perceive? At 2025-03-21T08:46:56+0000, Gianfranco Costamagna wrote: > I wanted to write some more detailed answers in previous questions, > but I also know that writing long emails have two bad side effects: > > 1) I waste people time if I dont summarize enough > 2) I have less and less readers every additional word I write. Claude Shannon established a limit to data compression. The more information you impart in a message, the longer it _must_ be. Concision respects one's audience. Oversimplification, evasion, and omission of pertinent material insult--or worse, deceive--that audience. 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. > The questions for DPL should be concise, easily readable for > non-native speakers, and require possibly short answers Good advice. I believe my questions satisfy these criteria. If you disagree, please be specific. All can be satisfactorily answered with "yes" or "no". > (and try to avoid flames, I never play part of flame wars game, I like > to spend my time with activities that makes me feel better not worse). Again a limiting principle applies: difficult problems can be tiresome or unpleasant to work on. One reason we have an elected Project Leader--and their delegates--is to tackle problems that the individual developer cannot, or for which spontaneous volunteers are unavailable. > For this reason I'll happily answer you if you can provide the above. Thank you; I look forward to it. At 2025-03-21T15:42:41+0100, Matthias Urlichs wrote: > On 20.03.25 20:35, Jonas Smedegaard wrote: > > > [Soren wrote:] > > > I believe the question is if the nominees would be willing to > > > support the ideas explained in this email. > > > > > > I feel it is appropriate to ask nominees for the DPL what they > > > think about specific issues as well as if they would support > > > specific actions/solutions to problems. > > > […] > > I similarly found the implied question from Branden appropriate, and > > hereby second the encouragement for the candidates to express their > > opinions on the proposed changes. > > I'm of two minds here. On the one hand, yes we might want to think > about some of what Branden wrote. > > On the other, the form is not appropriate IMHO. "What do you think > about [1000+ words with several semi-related recommendations the > future DPL might adopt]" doesn't lend itself to constructive > discussion. That depends on the content of the 1000+ words, IMO. Even then, Gerardo was curious to hear even more background <https://lists.debian.org/debian-vote/2025/03/msg00096.html>. How could I satisfy both him and you? Regardless, I stripped all the motivating material, added question marks, and re-posed the 5 brief and simple questions <https://lists.debian.org/debian-vote/2025/03/msg00100.html> > A third point: the DPL's role is only partially to lead Debian. IMHO > a rather important part of the job is to simply represent the > principles and/or rough consensus of the project's members. My questions' concern lay not in ceremonial or representative/diplomatic functions, but with the exercise of the powers of the office of Project Leader under the Debian Constitution. > Branden's missive doesn't represent any views other than his own As far as I know, that is true. At least two other people have publicly expressed a desire to see my questions answered; that doesn't mean they endorse any view I hold, but it does mean I'm not alone in wanting to know how the candidates would answer the questions. > More to the point, I'm sorry but I don't *quite* see why any of his > recommendations should be particularly relevant to my decision on who > to vote for. It's okay if you are uninterested in the exercise of Project Leader's powers under the Constitution. Your vote counts as much as any other Developer's. Not everyone, however, will share your priorities. At 2025-03-21T15:41:32+0000, Gianfranco Costamagna wrote: > Hello, let me answer to this non-question :) [snipped quote of Matthias, already included above] > I really think you got the point, thanks for that. A Leader role is > not to check all the single lines of code, to check every decision, to > check all the techical discussions. The role of a leader is to lead, > to give directions, make sure all the Teams are in good shape and not > understaffed, appoint delegates, speak for the project as one single > voice and various of other not funny things. Let me abbreviate you: "The role of a leader is to ... appoint delegates ..." _All_ of my questions pertain to exercise of the DPL's delegation power. > A Leader should let people make their choice in a free way, Yes (as should their delegates). > not push people against or for a specific idea. The evidence is against this claim. For example, the incumbent, Andreas, ran on a platform of pushing for _several_ specific ideas <https://www.debian.org/vote/2024/platforms/tille>. It is reasonable to infer that his election to the role of DPL reflects a rough endorsement of his goals by the electorate. > As a Leader, I would like to increase the roles and power of the > Teams, 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? > and make sure that the voting weight of DPL is the same as the newest > DD joined the project. 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>. > The Leader should stay away from flame wars, otherwise the role will > be undermined, and this isn't acceptable. I disagree. When we can assume good faith as the Code of Conduct advises us to do, conflicts arise because people care about things. They therefore offer an opportunity for leadership. If the DPL believes they can lower the temperature of (that is, make productive) a dispute-- stifling it is not the same thing--they should do so. If they exhibit a track record of succeeding at that, they demonstrate a valuable talent. I would also counsel us collectively not to characterize any conflict of opinions as a "flame war". That term is properly applied to disputes where most or all of the communications are abusive or derogatory, from all sides; in other words, where (almost) everyone involved is probably disregarding the Debian Code of Conduct. It is foolish to believe that our developers will never have conflicts. Conflicts are a consequence of having independent brains. An objective of the Code of Conduct is to encourage _constructive_ expression of conflict. See item 1 <https://www.debian.org/code_of_conduct>. > When a person is elected, it becomes the Leader of *everybody*, not > just his voters. This has to be clear. Agreed. At the same time the DPL cannot adopt contradictory positions held by developers in conflict. By voicing a view in a dispute, the DPL takes a side. By not voicing a view, the DPL fails to lead. That said, there are situations where intervention would be futile or detrimental. Occasionally, leadership has to come from sites other than the Project Leader. We should know that: our Constitution offers an example in the Technical Committee. But that's not the only other place. 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. > thanks for the non-question, it helped a lot specify what to me is a > question for a running DPL, and what is a risky, useless flame war. In my experience, aversion to conflict is not a desirable trait in a DPL. A problem that faces every DPL taking office is how to manage conflicts that are already underway when they're elected. When faced with a problem that they don't feel they can help to resolve, a DPL should report that determination to the membership. I acknowledge that this can be a hard thing to do. At 2025-03-24T11:57:51+0100, Gerardo Ballabio wrote: > Jonas Smedegaard wrote: > > I similarly found the implied question from Branden appropriate, and > > hereby second the encouragement for the candidates to express their > > opinions on the proposed changes. > > I suppose I miss the context behind Branden's question (and behind > other people's reactions). There is some risk in asking for such context; it could lead to me writing (additional) long emails, a practice that at least one Debian Developers has characterized to me privately as "destructive". > Actually, from an external observer's point of view, it isn't easy to > assess how the Community Team is working, This is an excellent point. > because most of their activity happens in private for good reason. 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). > Maybe the team should send regular "bits from" mails with some > statistics, e.g., in this month we were contacted by N persons and > reached out to M other persons for reasons X, Y and Z and it went such > and such -- of course all anonymized. Yes, that would be a big improvement! > But that is really off topic for DPL election. I strongly disagree. The exercise of the powers and responsibilities of the Project Leader's delegates is solidly on topic. If the membership (the DDs) have insufficient insight into the activities of delegates, that is a concern they should express at any time, and especially in an election campaign. Delegates exercise power granted to them by Project Leader on behalf of the membership--the Debian Developers. Delegates must be accountable to the Developers just as the DPL is. Since the delegates are not elected, but selected by the DPL, the DPL _must_ supervise them. Delegates can reduce the burden of that supervision to the extent that they make their activities visible and accountable to the membership. > What is in topic for DPL election is that, since Community is a > delegated team, if there are issues that suggest that their delegation > should be revised, it would be up to the DPL to act on that. Yes. The scope, or charter, of a delegation is as material as the transparency and accountability of the delegates themselves. > As I understand, the issue raised by Branden seems to be that there is > some confusion about the actual powers of the team and how they > exercise it. I raised 5 issues, only 1 of which has to do specifically with the CT, but yes. I am not alone in expressing confusion, and I think you can find evidence of it elsewhere if you look. Some, unfortunately(?), has been expressed in non-public fora. > Again, I miss the context to assess whether that is true and how > pressing of an issue it is. Branden (or anybody else) might want to > provide more information. I'm curious: has anyone been in touch with you privately to advise you against seeking that information? > On the general "no more than one delegation per person" issue, I'm not > aware that this has ever been a problem. Again, Branden might want to > elaborate why he thinks it is. I did. Items B, C, and D in my original rationale all pertain <https://lists.debian.org/debian-vote/2025/03/msg00060.html>. Thank you for your patience. Regards, Branden
Attachment:
signature.asc
Description: PGP signature