Dear nominees,
Thank you for standing for the office of Debian Project Leader (DPL).
Prompted in part by many years of reflection on the project's strengths
and weaknesses, I have a slate of recommendations regarding the
management of delegates under section 8 of the Debian Constitution.[1]
One is specific to the Community Team; the other four are general.
1. Strike the words "and Code of Conduct violations" from the Community
Team delegation charter.
2. Articulate a policy that no Debian Developer shall occupy more than
one delegated role at a time.
3. Ask any Debian Developers enjoying multiple delegations to resign
from all but one of their choice.
4. Establish a policy that all delegations made by the Debian Project
Leader shall be renewed no less frequently than once per DPL term.
5. Affirm and 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.
I ask the nominees to publicly endorse the foregoing proposals, or
articulate why they feel they cannot.
One can embrace any of the foregoing proposals for any reasons one
likes. I offer my own rationales below so that people understand why I
take the trouble to write, but do not ask that anyone hold my views.
Those short on time may wish to skip the remainder of this message.
A. We've seen repeated expressions of confusion and feelings of
intimidation arising from emails sent by the Community Team. Some
of our membership feel that such an email is an indication that
punitive measures such as suspension or expulsion from the Project
via the Debian Account Management (DAM) team is imminent. Others
have interpreted the Community Team's emails as thoroughly informal
coaching without disciplinary weight. I suspect that both opinions
are rationally defensible, and if so, a problem is thereby revealed.
The Community Team this month published a FAQ on the Debian Wiki.[2]
As of a few minutes ago, it read in part:
"We may send a stronger message where we think this is necessary. If
we believe you are violating the CoC [Code of Conduct] in a message,
we will say so explicitly."
I welcome this clarification, but members of the Community Team
(some formerly of it, I think) have in other writings been at pains
to emphasize that their communications carry no special weight in
any official determination of a Code of Conduct violation, nor of
what measures will be taken in addressing such a violation.
By noting the Code of Conduct explicitly in the Community Team's
charter, its membership is pulled in multiple directions, as are the
perceptions of the broader Project membership when interpreting
communications from that team. I note that the team, in its FAQ,
could have resolved to make explicit in _all_ cases whether its
members perceived a Code of Conduct violation. I have myself
proposed model language making explicit the default that the team's
FAQ encourages the reader to infer.
> This is not a disciplinary matter and no alteration of your privileges
> as a Debian Developer is contemplated. The role of the Community Team
> is to encourage friendly, collaborative communications within the
> Debian Project to avoid unnecessary discouragement of our contributors
> so that we work more effectively and productively as a group. The
> Community Team undertakes counseling at its own subjective discretion.
No member of the Community Team has yet expressed to me their
assessment of the foregoing wording.
Removing the words "and Code of Conduct violations" from the
Community Team's charter would, I predict, aid the team to direct
its activities with more focus, reduce any rational component of
fear or sense of threat that recipients of the Team's mails
experience, and reinforce the understanding that upholding the Code
of Conduct via non-disciplinary means is the responsibility of _all_
members of the Debian Project--not one that has been shifted onto
the Community Team by the Project Leader's delegation.
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.
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.
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.
E. Item 5 is already done for good reasons, some of which I might not
be aware of. I note it explicitly on the same basis as Item 4,
which I think it is mutually reinforcing.
Thank you for your attention and especially for reading this far.
Have a good campaign!
Regards,
Branden
[1] https://www.debian.org/devel/constitution#item-8
[2] https://wiki.debian.org/Teams/Community/FAQ
Attachment:
signature.asc
Description: PGP signature