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