On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote:
> With this message we define a way to appeal a DAM action,

I'm treating this as if it's a first draft and open to comment.

> 1. Appealing DAM decisions
> --------------------------
> Any person who had their Debian membership suspended or revoked by DAM may
> appeal the decision.

Based on the process you describe, I'd suggest phrasing this as "may
ask for the decision to be reviewed by the New Members Committee".
An "appeal" (at least in legal terms) usually goes to the more powerful
body, but in this case, DAM is the more powerful body.

Having the boss's decision reviewed by people who report directly to
the boss is kind of a dodgy structure; and people on the new member
committee will probably want to maintain good relations with DAM, at
least if they want to continue doing new member work.

> 2. DAM statement
> ----------------
> Within 72 hours DAM will provide a statement to the NMC and the appealer
> with their reasoning for the account status change.

I think by this point DAM should have already provided the reasoning
for the expulsion to -private (or -project if the person being expelled
agreed), so this should be redundant.

> DAM may also send additional material to the NMC only, encrypted to the
> individual members, if they deem it necessary for the case, and if
> presenting this to a wider public might cause issues of confidentiality for
> involved third-parties.

> [1] The NM-Committee is defined as:
>        - All members of DAM and FrontDesk.
>        - All application manager that are marked as active and
> processed at least one NM in the last 6 months.
>    There is a mail alias <nm-commit...@nm.debian.org> which reaches all
> members, it is regularly regenerated by FrontDesk.

All AMs that have processed an NM in the last 6 months is a fairly
broad group, and not one that's particularly selected for dealing with
particularly sensitive information. It doesn't seem like a great idea to
send sensitive info to them that you wouldn't feel comfortable sending
to any random developer to me, so again sending the detailed reasoning
to -private still seems like the right approach, removing personally
identifying details in the rare cases where that's necessary.

> The NMC members are expected to avoid disclosing
> this material to anyone else, including the appealer.[3]

Doing things that way avoids this risk/caveat.

I don't really think providing sensitive material to the new member ctte
in this way is helpful anyway: if they can't pass it on to the person
who got expelled they can't ask "is this true? what's your side of the
story?" either, which is pretty essential if you want to have a remotely
fair process.

> 3. Appealer statement
> ---------------------
> Within a further 72 hours, the appealer has the opportunity to respond to
> the DAM statement with their own statement.

DAM should be providing the full reasoning to the person being expelled
when they're expelled; if that person's going to ask for review, they
already have all they need to provide their side of the story as part
of the request for review, avoiding the need for this 72h period.

Both the above changes would cut the appeal time down by a week, from:

 - expulsion happens
 - <30 days, review is requested
 - 3 days for DAM to do an update
 - 3 days for expelled person to provide a statement
 - 7 days for discussion
 - 3 days for vote

to something more like:

 - expulsion happens, affected member and -private given detailed
   reasoning
 - <30 days, review is requested and statement from expelled person is
   provided to newmaint-ctte
 - 7 days for discussion
 - 3 days for vote

This setup avoids giving the expelled developer the opportunity to
pick Christmas or Easter or the start/end of the freeze or some other
inconvenient time to start the process, and immediately triggering a 3
day deadline for DAM members.

> 4. NM Committee review
> ----------------------
> The NMC has 7 days to review the received material and discuss the matter in
> private. They are expected not to solicit further input, as this is not an
> inquiry but a peer review of the DAM decision.

One of the things appeals courts in real life can do is send the case back
to a lower court with a requirement to fix up mistakes in fact finding,
which gives them an easy opportunity to avoid having to do any fact
finding themselves. Since the balance of power is the other way around
here; I'd expect that if the new member committee isn't just going to be
a rubber stamp for DAM, then they'd need to be able to solicit further
input in cases where DAM's summary of events doesn't match the expelled
developer's take on what happened.

(Another difference between the proposed process and court appeals is
that appeals courts can provide detailed opinions as to why the original
decision was wrong which helps avoid making the same mistakes in future;
this process doesn't really have that feature)

> 5. NM-Committee vote
> --------------------
> After 7 days discussion, or earlier if unanimously agreed by the NMC,
> NM-Frontdesk will ask the secretary to conduct a secret, 3-day-long vote,
> with the following options:
> 1. Uphold the decision of the DAMs
> 2. Overturn the decision of the DAMs
> Committee members otherwise involved in a case must abstain.
> DAM members are not allowed to partake in the vote.

I think "involved" should probably be more explicit. If the expulsion
came from a recommendation from the anti-harassment team, which in turn
resulted from a complaint, does that mean members of the AH team and the
complainant must abstain? How about if someone said "hey, tone it down"
on a mailing list, and this was used as part of the evidence that it was
an ongoing problem, but they weren't otherwise involved in the expulsion?

A rule that could work might be:

 - DAM will only directly expel people for DMUP violations and similar
   serious, urgent and unambiguous breaches of trust
 - Other expulsions will be initiated by other developers following the
   process described in 2005 (or some updated replacement)
 - If a review is required, neither DAM or the developers who
   initiated/seconded the expulsion process are allowed to participate
   in the review process (nor is the expelled developer, obviously)

If discussions are to be held on a private list that the expelled member
doesn't have access to, DAM etc probably should also be excluded from
that list while the discussion takes place.

> A simple majority decides the vote; in the event of a tie, the decision is
> not overturned.
> Abstained or absent votes are not counted. If more than half of the NMC
> (excluding DAM) abstain or do not vote, the decision is not overturned.

A quorum of 50% is pretty high; using the same formula for Q from the
constitution would probably make more sense. Not counting explicit
abstentions as part of quorum also is pretty unusual.

I'd suggest explicitly making this a secret ballot, like DPL elections.

> 6. Action
> ---------
> If the decision is overturned, the suspension or revocation of the account
> will be turned into a warning.

If DAM wrongfully expels someone, I think the stress of going through
the wrongful expulsion and the review process is probably more than
punishment enough for whatever they actually did, and it's better to
write the whole saga off, instead of making a note on their personnel
file, or whatever "turning it into a warning" means.

As I've said on -private, I don't really think putting the burden
on the expelled developer is the right way to do things: if you get
expelled you're going to be pretty annoyed/frustrated/angry/etc, and as
a result you'll be a very bad advocate for yourself. It's better IMO to
inform the project as a whole (ie, send a detailed explanation of what
caused the expulsion to -private), and let people who aren't already
annoyed/frustrated consider whether it makes sense or not. Changing the
trigger for nm-ctte review to be K (ie, 5) DD's rather than the expelled
person would probably work, I think -- that's the same number who could
do a GR anyway, after all.

Cheers,
aj

Reply via email to