Hello
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.
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)
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.
I agree
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?
We can't satisfy everybody's needs, we need to try to satisfy the majority of them whenever is possible.
https://xkcd.com/1172/
You two can engage a private discussion and enjoy writing a summary of it :)
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.
ok
"The role of a leader is to ... appoint delegates ..."
yes.
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.
Pushing an idea as DPL is a good thing, but at the end, ideas becomes
a thing when people start implementing them :)
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 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).
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,
on a case-by-case analysis. 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)
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, if somebody is harmful to the project because of multiple delegations, the answer
becomes yes for them, not in general.
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. Having such a rule won't be beneficial for the Team itself.
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.
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 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.
As a DPL, I wouldn't enforce any GR without asking for sponsors.
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.
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.
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)
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.
Indeed.
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.
Flame wars is when people don't assume good faith, when they use
the wrong wording. 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)
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>.
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.
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.
voicing a view might be also ask people to step down, take some rest, change wording and try to find a common way of handling the specific situation/dispute without saying what is the current position.
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.
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
More rules won't make the job easier, at least in general
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.
I already answered above to this.
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".
not me :)
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
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?
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.
C. Item 3 manifests fair and equal treatment of delegates. All
delegates serve at the pleasure of the Project Leader, and
ultimately the membership. "Grandfathering in" extra powers or > privileges of sitting delegates is not necessary, bestows extra
status, and--in an approximate form involving the overhang of
Debian's pre-Constitutional history--is known to have troubled the > governance of the Project in the past.
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.
D. Item 4 intends to aid the Project Leader to undertake review of all > delegated roles at least once in their annual term. It
unfortunately sometimes happens that once-prominent contributors > fade without explicitly resigning or stepping away, or struggle to > admit that they no longer have the resources necessary to attack the > problems their delegated status is crafted to address. It should be > easy for a person's delegated status to end uneventfully without > rancor or any presumption of diminished fitness for the role. While > I suspect happy endings to delegations are already common, it might > not be equally true of all delegated roles. Let's do more to ensure > that it is. In my experience, people entrusted with a portion of > shared responsibility welcome the availability of graceful
off-ramps; those with an unhealthy attachment to power do not.
This might be a good idea, to ping people once a year, and ask if they still have bandwith
to fullfill the role responsibilities.
Gianfranco
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)