Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #10187 > unrolled thread

Appeal procedure for DAM actions

Back to article view | Back to linux.debian.project

Contents

  Appeal procedure for DAM actions Joerg Jaspert <da-manager@debian.org> - 2019-01-07 23:40 +0100
    Re: Appeal procedure for DAM actions Jonathan Wiltshire <jmw@debian.org> - 2019-01-08 00:50 +0100
    Re: Appeal procedure for DAM actions Enrico Zini <enrico@enricozini.org> - 2019-01-08 11:50 +0100
      Re: Appeal procedure for DAM actions Jonathan Carter <jcc@debian.org> - 2019-01-08 12:30 +0100
        Re: Appeal procedure for DAM actions Enrico Zini <enrico@enricozini.org> - 2019-01-08 12:40 +0100
          Re: Appeal procedure for DAM actions Jonathan Carter <jcc@debian.org> - 2019-01-08 13:10 +0100
    Re: Appeal procedure for DAM actions Kurt Roeckx <kurt@roeckx.be> - 2019-01-08 16:20 +0100
      Re: Appeal procedure for DAM actions Joerg Jaspert <joerg@debian.org> - 2019-01-08 21:50 +0100
    Re: Appeal procedure for DAM actions Karsten Merker <merker@debian.org> - 2019-01-08 22:30 +0100
      Re: Appeal procedure for DAM actions Joerg Jaspert <da-manager@debian.org> - 2019-01-08 23:40 +0100
        Re: Appeal procedure for DAM actions Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-09 14:20 +0100
        Re: Appeal procedure for DAM actions Karsten Merker <merker@debian.org> - 2019-01-10 00:00 +0100
          Re: Appeal procedure for DAM actions Kurt Roeckx <kurt@roeckx.be> - 2019-01-10 09:50 +0100
            Re: Appeal procedure for DAM actions Kurt Roeckx <kurt@roeckx.be> - 2019-01-10 10:00 +0100
          Re: Appeal procedure for DAM actions Ulrike Uhlig <ulrike@debian.org> - 2019-01-10 15:50 +0100
            Re: Appeal procedure for DAM actions Jonathan Wiltshire <jmw@debian.org> - 2019-01-11 00:50 +0100
              Re: Appeal procedure for DAM actions Richard Hartmann <richih.mailinglist@gmail.com> - 2019-01-11 10:00 +0100
    Re: Appeal procedure for DAM actions Anthony Towns <aj@erisian.com.au> - 2019-01-09 02:10 +0100
      Re: Appeal procedure for DAM actions Ulrike Uhlig <ulrike@debian.org> - 2019-01-09 11:30 +0100
        Re: Appeal procedure for DAM actions Richard Hartmann <richih.mailinglist@gmail.com> - 2019-01-10 14:10 +0100
          Re: Appeal procedure for DAM actions Ulrike Uhlig <ulrike@debian.org> - 2019-01-10 15:50 +0100
      Re: Appeal procedure for DAM actions Wouter Verhelst <wouter@debian.org> - 2019-01-10 15:10 +0100
    Re: Appeal procedure for DAM actions Jonathan Wiltshire <jmw@debian.org> - 2019-01-09 16:40 +0100
    Re: Appeal procedure for DAM actions Kurt Roeckx <kurt@roeckx.be> - 2019-01-09 16:50 +0100
      Re: Appeal procedure for DAM actions Pierre-Elliott Bécue <becue@crans.org> - 2019-01-09 19:10 +0100
        Re: Appeal procedure for DAM actions Luke Faraone <lfaraone@debian.org> - 2019-01-09 19:30 +0100
          Re: Appeal procedure for DAM actions Kurt Roeckx <kurt@roeckx.be> - 2019-01-09 19:50 +0100
            Re: Appeal procedure for DAM actions Richard Hartmann <richih.mailinglist@gmail.com> - 2019-01-10 14:00 +0100
    Re: Appeal procedure for DAM actions Gunnar Wolf <gwolf@debian.org> - 2019-01-09 19:50 +0100
      Re: Appeal procedure for DAM actions Joerg Jaspert <joerg@debian.org> - 2019-01-09 21:20 +0100
    Re: Appeal procedure for DAM actions Daniel Pocock <daniel@pocock.pro> - 2019-01-26 10:40 +0100
      Re: Appeal procedure for DAM actions Sam Hartman <hartmans@debian.org> - 2019-01-26 17:20 +0100
        Re: Appeal procedure for DAM actions Daniel Pocock <daniel@pocock.pro> - 2019-01-28 10:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#10267

Hi!

Richard Hartmann:
> On Wed, Jan 9, 2019 at 11:27 AM Ulrike Uhlig <ulrike@debian.org> wrote:
> [...]
>> Anthony Towns:
> [...]
> 
>>> 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.
>>
>> I cannot see a problem here. The vote of NMC will be secret, so there is
>> no way that DAM could know about who voted what.
> 
> [...]
> 
>>> (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).
>> There could be a _non-mandatory_ reasoning written by the NMC to DAM if
>> a decision is overturned.
> 
> Those two are mutually exclusive.
> 
> Assuming best case and that the text is piped through Secretary to
> avoid sender addresses: It would be an undue burden for dissenting NMC
> members to find each other in a truly secret ballot, let alone have
> them write something in a way which ensures DAM can't deduct from the
> style of writing, points raised, and timing who's among the set of
> people. Add that everyone in that group would know how many dissenting
> votes there were so you even know how many dissenters you would need
> to find.

Correct! Thanks for making it clear :)

Cheers!
u.

[toc] | [prev] | [next] | [standalone]

#10264

On Wed, Jan 09, 2019 at 11:08:12AM +1000, Anthony Towns wrote:
> 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.

Actually, to the NM committee, "the boss" is frontdesk, not the DAM.
There is some overlap between the two (in fact, most DAMs get recruited
from the NM frontdesk AIUI), but they're still separate.

Having said that, "the boss" doesn't really exist in Debian, apart from
the DPL...

> > 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.

They might still want to provide a statement explaining some of the more
private arguments, though.

> > 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-committee@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.

On the other hand, having an NM committee which gets selected
semi-randomly like that means that the DAM can't really "play" the
system as easily.

[...no further disagreements...]

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

[toc] | [prev] | [next] | [standalone]

#10236

On Wed, Jan 09, 2019 at 04:28:41PM +0100, Thomas Goirand wrote:
> On 1/7/19 11:27 PM, Joerg Jaspert wrote:
> > 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:
> > 
[snip]
> Would this vote be secret?

Yes, as the proposal you quoted specifies.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

[toc] | [prev] | [next] | [standalone]

#10237

On Wed, Jan 09, 2019 at 04:28:41PM +0100, Thomas Goirand wrote:
> 
> Would this vote be secret? In some situation, I'd rather not vote than
> having my vote disclosed. I'm very much OK for the secretary to see what
> I voted for though.

The voting would be secret. I think the only output should be the
number of yes/no/abstain.

I would try to use software that can run a vote like that,
where it's possible to provide proof that your vote was recorded
properly. I think there is such open source software, I just can't
remember it.


Kurt

[toc] | [prev] | [next] | [standalone]

#10243

Le 9 janvier 2019 16:49:30 GMT+01:00, Kurt Roeckx <kurt@roeckx.be> a écrit :
>On Wed, Jan 09, 2019 at 04:28:41PM +0100, Thomas Goirand wrote:
>> 
>> Would this vote be secret? In some situation, I'd rather not vote
>than
>> having my vote disclosed. I'm very much OK for the secretary to see
>what
>> I voted for though.
>
>The voting would be secret. I think the only output should be the
>number of yes/no/abstain.
>
>I would try to use software that can run a vote like that,
>where it's possible to provide proof that your vote was recorded
>properly. I think there is such open source software, I just can't
>remember it.
>
>
>Kurt

French lab Loria has developped Belenios, an enhanced version of Helios.

HTH. 
-- 
PEB

[toc] | [prev] | [next] | [standalone]

#10245

On Wed, 9 Jan 2019 at 19:07, Pierre-Elliott Bécue <becue@crans.org> wrote:
> Le 9 janvier 2019 16:49:30 GMT+01:00, Kurt Roeckx <kurt@roeckx.be> a écrit :
> >I would try to use software that can run a vote like that,
> >where it's possible to provide proof that your vote was recorded
> >properly. I think there is such open source software, I just can't
> >remember it.
>
> French lab Loria has developped Belenios, an enhanced version of Helios.

It was an oblique reference to devotee[1], the Debian voting software.
We already have secret ballots for DPL elections.

[1]: https://www.debian.org/vote/

-- 
Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470

[toc] | [prev] | [next] | [standalone]

#10246

On Wed, Jan 09, 2019 at 07:28:34PM +0100, Luke Faraone wrote:
> On Wed, 9 Jan 2019 at 19:07, Pierre-Elliott Bécue <becue@crans.org> wrote:
> > Le 9 janvier 2019 16:49:30 GMT+01:00, Kurt Roeckx <kurt@roeckx.be> a écrit :
> > >I would try to use software that can run a vote like that,
> > >where it's possible to provide proof that your vote was recorded
> > >properly. I think there is such open source software, I just can't
> > >remember it.
> >
> > French lab Loria has developped Belenios, an enhanced version of Helios.
> 
> It was an oblique reference to devotee[1], the Debian voting software.
> We already have secret ballots for DPL elections.

I don't intend to use devotee for that. I don't think it can
currently handle such votes, nor do I want to spend time
implementing that.


Kurt

[toc] | [prev] | [next] | [standalone]

#10262

On Wed, Jan 9, 2019 at 7:46 PM Kurt Roeckx <kurt@roeckx.be> wrote:

> I don't intend to use devotee for that. I don't think it can
> currently handle such votes, nor do I want to spend time
> implementing that.

I have used CIVS[1] for various projects and for work. It's not very
polished, but usually works well. It's Condorcet and you can choose
the completion rules, amongst other options.


Richard

[1] https://civs.cs.cornell.edu/

[toc] | [prev] | [next] | [standalone]

#10247

[Multipart message — attachments visible in raw view] — view raw

Joerg Jaspert dijo [Mon, Jan 07, 2019 at 11:27:35PM +0100]:
> Hello everyone,
> 
> One of the things that emerged from the recent discussions around DAM
> actions is that we are missing a way to review or appeal DAM's decision.
> Currently the only way to do this is running a full-featured GR, with all
> the negative side effects such a process has.
> (...)

Thank you very much, Joerg (and DAM team) for coming up with this
proposal. I have just returned to work after a month off, and my brain
isn't yet 100% wired to be productive again (WAY off 100%, I'd say),
but this really looks like a good (although perfectible - but what
isn't?) answer to our current situation.

I hope this helps the current tensions (to name them mildly) to be
relaxed and lets us sort out of the issue without further harm to the
project.

[toc] | [prev] | [next] | [standalone]

#10250

On 15277 March 1977, Gunnar Wolf wrote:

> Thank you very much, Joerg (and DAM team) for coming up with this
> proposal. I have just returned to work after a month off, and my brain
> isn't yet 100% wired to be productive again (WAY off 100%, I'd say),
> but this really looks like a good (although perfectible - but what
> isn't?) answer to our current situation.

I've had about 4 months off just end of last year (well, not vacation, sick
leave), I know that thing.

> I hope this helps the current tensions (to name them mildly) to be
> relaxed and lets us sort out of the issue without further harm to the
> project.

I don't think it will steer anyone away from pathes of destruction they seem
hell bent on, but I do hope and assume it will make future cases less noisy.
Together with the other stuff posted elsewhere.

Now need to get some of the proposals for change included to make it better...

-- 
bye, Joerg

[toc] | [prev] | [next] | [standalone]

#10298

On 07/01/2019 23:27, Joerg Jaspert wrote:
> Hello everyone,
> 
> One of the things that emerged from the recent discussions around DAM
> actions is that we are missing a way to review or appeal DAM's
> decision.  Currently the only way to do this is running a full-featured
> GR, with all the negative side effects such a process has.
> 
> While a GR is a constitutional right, and the procedure we lay out here
> does NOT take that away, we feel there is a need for a less drastic
> procedure that would allow double-checking of DAM actions without
> escalating into a project-wide dispute.
> 
> With this message we define a way to appeal a DAM action, that balances
> between involving other members in the review, and ensuring that we have
> sufficient independent oversight.
> 
> Although this defines a pretty strict timeline for the procedure to
> avoid a long-running process, we waive the time limit defined in §1 for
> the cases from the last 6 months.
> 
> ------------------------------------------------------------------------
> 
> 1. Appealing DAM decisions
> --------------------------
> Any person who had their Debian membership suspended or revoked by DAM
> may appeal the decision. They must request the appeal within 30 days,
> stating why they disagree with the decision in a mail to DAM. DAM will
> notify the New Members Committee (NMC)[1][2] and Front Desk.
> 
> The original action taken by DAMs remains in force during the appeal.
> 

Happy Australia Day everybody.  Please take a moment to review the
Wikipedia definition[0] of a kangaroo court, many people have privately
commented on the irony of kangaroo courts in this situation.  Various
points stand out and care is needed to avoid the perception that this
type of thing happens in Debian:

"proceedings are often held to give the appearance of a fair and just
trial, even though the verdict was already decided before the trial
actually began"

"A kangaroo court could also develop when the structure and operation of
the forum result in an inferior brand of adjudication. A common example
of this is when institutional disputants ("repeat players") have
excessive and unfair structural advantages over individual disputants
("one-shot players")"


The way that DAM has been making decisions without consulting the
members in question is a "shoot first ask questions later" approach.
Making a decision and asking people to appeal suggests they are "guilty
until proven innocent"

In the case in 2016, the member concerned was given 48 hours to answer
questions.  Most DDs would struggle to respond in that period,
especially if they were on vacation or had other deadlines for their job.

Now DAM appears to have abandoned even that hint of due process and
decided that they don't even need to give that 48 hours.  It is as if
people are being unceremoniously dumped out the back door.

The process needs to be much more reasonable, perhaps 90 days at each
step and not even making a first decision without reasonable time.  The
process for accepting a member generally takes quite some time so it is
contradictory to have this lightning-strike expulsion process.

How can a decision that may unfairly impact somebody's work and
reputation be implemented before the member has exhausted all
opportunities for appeal?

If the reason is due to urgent questions about technical competence, DAM
have another option: they change somebody's status from Uploading to
non-Uploading developer.  The member remains a member in the sense that
they can vote and their reputation is less likely to be jeopardized by a
decision that hasn't been confirmed by a full process.


> 
> 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.
> 


Why the NMC?

Why not consider having an elected membership committee?

With the current proposal, DAM can watch the way that NMC evolves over
time and choose to make a decision at a time when they think the current
members of NMC are likely to support the decision.

This is one of those "structural advantages" of a kangaroo court.


> 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. The NMC members are expected to avoid
> disclosing this material to anyone else, including the appealer.[3]
> 

The presence of secret evidence is a showstopper here.

Another one of the "excessive and unfair structural advantages over
individual disputants" that typifies a kangaroo court.

If a member goes to a GR, they won't be contending with any secret
evidence because everybody (the member and the rest of the community)
will be working off the same public evidence and the member will be able
to challenge any of it as necessary.

In the current situation, "evidence" that is 100% defamatory has been
sent to antiharassment and DAM or circulated in other communities.  A
process that prevents a member from reviewing such material and
rebutting it is incredibly unfair and also unreliable.

In at least one recent case, it appears DAM did not send any evidence or
justification to the member, they only sent some condescending and
offensive personal insults to the member.

Strategically, for many reasons, it would appear that a member would be
better off going directly to a GR.  If the member makes an appeal, their
appeal is undermined by secret defamatory evidence that they weren't
allowed to see and they lose the appeal, the full community discovers
the appeal was declined, it may be harder to convince the full community
to support them in a subsequent GR.  So it would be strategically better
to just go directly from DAM to GR without first making an appeal to NMC.

This strategic consideration could potentially be mitigated if the fact
the member made an appeal to NMC is kept secret.  But given the way
"private" communications from DAM have been propagated outside the
organization recently, within minutes of a DAM decision, a member would
still be unlikely to trust the appeal process.


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


According to our constitution, we are all volunteers.

Short time scales like this are not reasonable.  Most organizations
would take weeks or months to work through such a serious process.

During the new membership process, there are sometimes long pauses in
the exchange, so this 72 hour opportunity for the member to respond to
evidence is contradictory.

Wikipedia suggests[0] "hastily carried-out proceedings" are a symptom of
a kangaroo court.

Members are not salaried so there is no urgency like in a small startup
company trying to fire one person and hire somebody else.  Somebody else
suggested a series of warnings, I'd also suggest having a significant
period, e.g. 2-3 years of review and active attempts at discussion
before any final decision is made.

If membership can just be extinguished in the blink of an eye a few days
before Christmas it trivializes the whole concept of membership and that
trivializes the organization as a whole.  It looks like a teenage rock
band having a fight and breaking up within 15 minutes, not an
organization of professionals.  The tone of that quote from DAM in my
recent blog[6] emphasizes that: "This is not involving anything from the
universal declaration of human rights. We are simply a project of
volunteers which is free to chose its members as it wishes."

In a small group that attitude might be acceptable but in a group of
1,000 people, there will be people who don't talk to each other or can't
stand each other.  That isn't grounds for expulsion or demotion.  It is
a sign that the project is growing, that is all.  If founders of the
project didn't want it to get so big, they never should have offered
membership in the first place.

DAM stated in their email about non-routine actions that the project's
reputation is a factor in their decisions.  This improvised attitude to
the rights of members doesn't live up the reputation of the project.

We have all helped the organization build that great reputation and so
it is particularly unfair that DAM or the DPL can use the project's
reputation against any one of us in the way that they have done in 2018.



> 
> 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.
> 


>From that Wikipedia article again: "proceedings are often held to give
the appearance of a fair and just trial, even though the verdict was
already decided before the trial actually began"

> 
> 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.
> 
> A simple majority decides the vote; in the event of a tie, the decision
> is not overturned.
> 


Why not raise this to 75% or 90% of eligible votes?  These are
extraordinarily serious decisions and if the evidence is only able to
convince barely half the people then the decision will have a toxic
legacy.  It will be perceived as a political decision.

In a jury trial, for example, it is usually necessary for 100% of jurors
to agree.  Many other organizations also require some sort of
super-majority for big decisions like expulsion and constitutional changes.


> 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.
> 
> An independent Developer, usually the project secretary, conducts the
> vote. In the event that the secretary is a partly involved in the case,
> DAMs will work with the DPL to identify a suitable developer.
> 
> 
> 6. Action
> ---------
> If the decision is overturned, the suspension or revocation of the
> account will be turned into a warning. The previous account status will
> be reactived and all changes to it undone at the earliest of the
> involved teams convenience.[5]
> 


Why does it need to be automatically turned into a warning?  It should
just stop there.  Anything that leaves a toxic legacy like this
should be avoided.




> If the decision is upheld, this process, like anything in Debian, does
> not prevent a GR.
> 
> 
> Footnotes:
> 
> [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-committee@nm.debian.org> which reaches all
>    members, it is regularly regenerated by FrontDesk.
> 
> 
> [2] At this point, frontdesk will ensure that the NM committee will not
>    be updated until after the case, to avoid a membership change in the
>    middle of an appeal process.
> 
> 
> [3] This hopefully minimizes the risk of disclosing information that was
>    given to DAM in confidence. The appealer is not included as in some
>    situations it may be used to further harass the reporters.
> 
> [5] It involves keyring-maint and DSA, none of which we can or should   
> dictate timelines to. It is expected to be measured in days, not weeks.
> 



0. https://en.wikipedia.org/wiki/Kangaroo_court
6. https://danielpocock.com/debian-human-rights-paradox

[toc] | [prev] | [next] | [standalone]

#10300

[Multipart message — attachments visible in raw view] — view raw

While we're throwing around random wikipedia pages, I'd like to submit
https://en.wikipedia.org/wiki/Sealioning

With respect, I don't think Daniel's comments are a constructive
addition to the discussion.  Whether or not daniel was treated
reasonably, I think that he's reached a level of
bitterness/upset/disappointment that is not going to lead to
constructive discussion.  I think that Daniel's post would take a long
time to respond to for a lot of us who have recently spent a lot of
energy trying to work through some really hard issues.

For myself, I'm not going to respond in substance, and I don't want
silence to be taken as agreement.

Here's why I don't think the post is constructive.  There are a lot of
reasons why you'd want to have rapid action for handling situations
other than questions of technical competence.  There are significant
cases where maintaining the safety of the community requires rapid
action.  There's a lot of thought put into antiharassment efforts that
argues for fairly rapid resolution of issues rather than the long
drawn-out processes that Daniel supports.

You can be constructive and disagree with all that.  There are really
big questions of fairness and no good answers.  However, constructively
participating in a discussion involves learning enough of the history
and enough of the positions (especially those of people you disagree
with) that you can  treat those positions with respect.  You should be
able to respond to their points and demonstrate empathy for the needs of
others in the conversation.

Daniel didn't do that, so I don't think he's being constructive here.
Wheter it is actually sealioning or simply ignorance of other positions,
the result is the same: he asks us to be drawn into a huge, painful,
drawn-out discussion where we take on the duty of educating him and any
trolls that are attracted by his impassioned language.  I personally
choose not to take on that burden here.

That said, Daniel brought up one point I would like to discuss with
anyone who would be interested in bringing about changes.  He points out
that we have events where we have face-to-face time and we could use
them more effectively for working through disputes.  I'm not interested
in debating with Daniel about whether the process should require that.
I am very eager to discuss how we can do more of that empathy building
and dispute resolution at events.

--Sam

[toc] | [prev] | [next] | [standalone]

#10302

On 26/01/19 16:12, Sam Hartman wrote:
> reasonably, I think that he's reached a level of

The post wasn't intended to start a discussion about anybody specific,
it is about the procedure.  Please don't shoot the messenger.  This
tendency to make discussions personal, especially when somebody has a
raised a challenging issue, contributes to a lot of the bad vibes that
people subsequently complain about.

If my view of this procedure is pretty dismal, that's just because I
value the people who contribute to Debian and I don't think any of us
are disposable.  People are not packages and applying a `dpkg --purge
person` attitude for arbitrary political purposes or differences in
personalities in such a large organization is abhorrent.

To put it bluntly, when a volunteer receives a threat email with a bunch
of official-looking CCs, it feels like intimidation from gangsters.  It
is a disgrace for Debian to make that impression on people.

Another blunt assessment of the situation, which can be deduced from the
private emails: the DPL thought he could skip over meeting with people
and talking to them and tried to simply sweep them under the carpet with
6 month "demotions" that would leave them for the next DPL to deal
with.  To save himself maybe a couple of hours investing in
relationships, which is a basic responsibility of any leader, the DPL
has cost many people a lot more time and hurt some long standing
contributors in a bad way.

If Debian wants credibility rather than a kangaroo court, it is
essential to get the principles right, not only for fixing the current
mistakes but also to avoid a repeat of anything remotely like that in
future.  If I didn't think this process could be improved I wouldn't
have written about its flaws in such detail, so please don't accuse me
of failing to be constructive.

There have been numerous cases of communications breaking down with
various people recently so please don't continue to make personal
accusations or single people out.


> constructive discussion.  I think that Daniel's post would take a long
> time to respond to for a lot of us who have recently spent a lot of
> energy trying to work through some really hard issues.


Not everybody has seen all those details but snippets of it, like this
thread, have been selectively released into debian-project

This is another example of why the procedure is morally bankrupt: if the
DAM can take this guilty-until-proven-innocent approach, remove somebody
from the debian-private mailing list and then use that forum to promote
a version of events that the member can't see and rebut before a GR vote
then the vote is biased against the member concerned.

DAM can prove me wrong of course by guaranteeing that members subjected
to this procedure will continue having access to debian-private right up
to the end of any GR ballot on their membership.




> Here's why I don't think the post is constructive.  There are a lot of
> reasons why you'd want to have rapid action for handling situations
> other than questions of technical competence.  There are significant
> cases where maintaining the safety of the community requires rapid
> action.  There's a lot of thought put into antiharassment efforts that
> argues for fairly rapid resolution of issues rather than the long
> drawn-out processes that Daniel supports.


For the record: you mention "safety of the community", but there was
never any safety issue on the part of any of the people threatened, it
was purely politics[1], scapegoating and some misunderstandings.  The
only safety issue is the sending of threats and defamation by Debian
leadership figures.

My post is not opposed to rapid action.  I fully believe in rapid action
to engage with people and improve relationships in the community, for
example, people have asked[2] questions about mediation.  Or simply
meeting with people to talk about issues.

Rapid action that may hurt people is to be avoided.

Rapidly skipping over the former to attempt the latter is even more
disturbing.

Rapid action to find the cause of a problem is good too.  Rapidly
searching for a scapegoat or somebody to blame is not.

In a number of cases this year, I've observed the DPL jumps into issues,
and I'm even counting at least one technical issue here, where he takes
a side without even asking for all sides of the story.  In the technical
issue that comes to mind, he had actually conflated two different pieces
of work and formed an opinion about the discussion way too early.  In a
technical debate it may be possible to overlook lapses like that, but
impartiality and neutrality are essential when dealing with grievances
and personal disputes.

This is a challenge for anybody in the DPL role.  Sometimes I thought it
was just a "clearing the inbox" mentality at work, a DPL rushing to tick
everything off before the end of the day, giving every email a fast
answer rather than the best answer.

The type of DAM actions discussed in this and some related threads
appear to be purely harmful to the people concerned, like giving
electric shocks.

Rapid action by the DPL to attack somebody's reputation, sending
disparaging emails to people in other communities within minutes of a
communication from DAM?  That is wrong.  Given the circumstances that
the DPL had been informed about in July, it is truly shocking.  That is
one reason why I strongly object to the "shoot first ask questions
later" approach.  Emails like that can't be sent in the first place if
there is a more neutral approach.

Seriously, if you want to train a dog, do you kick the dog each time it
does something bad or do you give it treats when it does something
good?  Multiple people have observed the former approach being attempted
in Debian.  It doesn't work[3] with dogs, spanking[3] children or with
developers.  Trying to do it more quickly or making up a process to
justify it won't make it more effective either.  Quoting that article:
"The odds of a child being more aggressive at age five increased by 50
percent if he had been spanked more than twice in the month before the
study began".  Does anybody want to repeat that study by demoting a
random selection of developers instead of spanking a random selection of
children?



> Daniel didn't do that, so I don't think he's being constructive here.
> Wheter it is actually sealioning or simply ignorance of other positions,
<snip>
> That said, Daniel brought up one point I would like to discuss with
> anyone who would be interested in bringing about changes.  He points out
> that we have events where we have face-to-face time and we could use
> them more effectively for working through disputes.  I'm not interested
> in debating with Daniel about whether the process should require that.
> I am very eager to discuss how we can do more of that empathy building
> and dispute resolution at events.

Those two points are contradictory - you suggest I'm being ignorant of
other positions, but you also refer to my post[1] in the thread about
mediation where I emphasized the benefit of face to face discussions and
the fact that those discussions were not only skipped, but actively
declined by DPL and DAM.  My overall intention is to be constructive.

In fact, from what can be deduced from private exchanges, it appears the
DPL sent orders to DAM giving a very selective and one-sided account of
a situation.  DAM did not know the most significant facts when they made
decisions in 2018.  Nobody should hold a grudge against DAM if they were
not properly informed or if they were pushed .  Although it wasn't the
most significant fact, did DAM know that the DPL had declined meetings,
for example?  If you were in the DAM team and that information was
hidden from you, how would you feel?

The view of the situation on debian-private and in some defamatory
emails circulating outside Debian is also very one-sided, missing the
most important facts and grievously misrepresenting others.  With or
without a bounty, I would encourage anybody who ever receives any
disturbing allegation about a developer to forward the email to the
developer in question and get their side of the story, straight from the
horse's mouth.  Some people already asked "is this true?" and were very
disturbed when they found out what really happened.

If the communications to DAM weren't being hidden, it would be easier to
troubleshoot, fill in gaps and find common ground where people can
rebuild.  I personally believe that is still possible if all sides are
willing to be open about those communications.  The games with secret
evidence, emphasized in this appeal process, are a barrier to that.

People appear to avoid meetings because they think they know the answers
or they think they can take shortcuts dealing with other people.

Therefore, I simply can't see how I'm the one who has failed to be
constructive or failed to attempt to find other opportunities for
discussion before this impacted more people.

There is another constructive aspect to my email: I am hoping it will
help people focus on the choice in the other thread.

Regards,

Daniel


1. https://fsfellowship.eu/2019/01/26/fsfe-behavior-standards.html
2. https://lists.debian.org/debian-project/2019/01/msg00232.html
3.
https://www.cuteness.com/13713210/how-does-punishment-affect-a-dogs-behavior

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.project

csiph-web