It's been made plain to me I've done a bad job of explaining myself on
debian-private, and besides it's really the wrong list. The main
thrust of this post is Debian has done a very poor job of maintaining
it's policy on expelling members, followed by suggestion for
improvements to the policy.
As far as I can tell, the only place document that defining Debian
current policy on expelling members is published is here:
http://lists.debian.org/debian-devel-announce/2005/08/msg00005.html
That would be a 13 year old post to a mailing list. To be fair a link
to that post is in the DAM Wiki page, filed under the heading
"Interesting Links".
Compare that to how we treat our engineering policies. They are
available at several places on the web in several different formats,
are regularly updated and we get notified when that happens. I refer
to them often not only because they easy to find and fast to look up
(packaged, no less), but also because I know people (and bots, the bots
are the worst) are verifying I follow them. The "I forgot" excuse
isn't likely to fly.
Recent events have shown the expulsion policy is not nearly as well
respected. That's not a complete surprise, I am somewhat amazed people
knew we have a policy until recently.
It's also not a surprise because for the most part we have no idea
whether it's being followed or not. There is no way the project
members can verify the people appointed to execute this policy are
following the procedures we agreed on 13 years ago, because all that
policy says about disclosure to the members is "if the nominee decided
to make the discussion public, we will inform the debian-project
mailing list, otherwise the debian-private list will get the
information". The "information" is the DAM's decision on whether to
expel them or not, only. To put it bluntly: "the people we are acting
for have no right or need to understand the reasons for our decisions".
I presume we agree to do this because "trust us, we are the DAM". I
don't know how well that went over at the time, but I'm pretty sure the
trust side of equation has changed so much the approach untenable now.
Still, I expect we could reach a consensus on "trust but monitor". To
achieve that we need transparency. For me that means at the very least
when the DAM expels someone our policy must require they justify their
actions in as much detail as the Technical Committee does, and it does
it in a post all members receive. This is about expelling members,
after all.
Accordingly, I suggest we update our current expulsion policy to say:
If the DAM decides to expel a Developer they will publish the
evidence they relied on and their reasoning that lead to the
expulsion. The evidence must include:
- Links to all public information,
- The number of private representations they received,
- How many dealt with each type of accusation (eg, abuse,
deliberate obstruction, policy violations),
- The DAM's opinion on quality of corroborating evidence in
those representations (eg, none, hearsay, beyond reasonable
doubt).
If the nominee decided to make the discussion public we will publish
this one debian-project mailing list, otherwise to the debian-
private list.
That is my first point.
My second point is about blunting the impact of discussions we have on
the reasons Developers are expelled. These discussions will always be
divisive. I think that is unavoidable. However, having them after
concrete action has been taken, when the only way to change the outcome
is GR is good way of ensuring these discussions end up looking more
like debates to the death, because in some ways they are.
Public warnings have their own advantages - warnings give the Developer
the chance to modify their behaviour, and them being public lets
everyone verify they have been given that chance. However in the
context of this discussion their main advantage is they give us more
gradual way to deal with discussions on why people are expelled by
providing an opportunity to discuss the reasons for the expulsion when
the stakes are far lower. If there is GR on the subject, it can be
about policy, not about the actions of some poor DAM member who is just
trying to do his job to the best of their ability. Once the policy is
decided, the DAM can go about their business without everybody having
to voice their opinion on their ability to do it.
Therefore I suggest we alter the expulsion process to give three
warnings, with no more than 5 years (pick a number) between the first
and the last, and no less than 1 month (pick a number) between
warnings. The last "warning" will be the expulsion notice, meaning the
DAM will execute the expulsion before issuing it. These warnings will
published in exactly the same manner as the expulsion above.
Finally, there are things requiring immediate action. These things
have one common element: they put the projects core activity of
creating and distributing a trusted distribution at immediate risk.
Examples are attacks on our infrastructure, leaking project
credentials, adding back doors to packages. For these cases I suggest
we allow the DAM to suspend account and uploading privileges
immediately without notice, but in such cases they must publish their
reasons for doing so in the same manner as above within 2 weeks (pick a
number) of suspension. After a maximum of 2 months (pick a number) for
comments and further investigation the DAM must either reverse their
decision, or publish a their reasons for proceeding to full expulsion.Attachment:
signature.asc
Description: This is a digitally signed message part