Re: On demotions to DM status.

[Andrey Rahmatullin]

On Mon, Jan 07, 2019 at 10:03:06PM +, Ben Hutchings wrote:
> > > Does the project want to say that a DM is less trustworthy than a DD? 
> > Yes, obviously. Just like a DM is more trustworthy than a non-DM.
> 
> It would be more accurate to say that a DD is more *trusted* than a DM,
> and a DM is more *trusted* than a contributor who has neither status.
Right.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Censorship in Debian

[Russ Allbery]

Miles Fidelman  writes:
> On 1/7/19 10:06 PM, Russ Allbery wrote:

>> Speaking as someone who is a listed author on three published RFCs and
>> chaired one IETF working group, I will take Debian process over IETF
>> process any day, and find your description of the IETF pretty
>> entertaining.  :)

> Well yeah, but which "works" better in terms of results? Particularly,
> as viewed by those who are impacted by the process?

Oh, Debian, by far.  Debian is massively more productive than the IETF per
unit of effort put in the front end.  Now, some of that is the nature of
standards development, which is inherently hard and much more contentious
than nearly all packaging problems.  But Debian puts far more work out in
the world, faster, than the IETF does relative to the resources invested.

That's part of why I'd rather work on Debian Policy than on IETF
standards.  IETF standards are very valuable, but the process redefines
the concept of slow and tedious.  And frequently, if there's no consensus,
nothing happens at all in the IETF for literally years.  (Not that this
nevery happens in Debian *cough*, but it's less common and it's usually
only relatively less important things.)

That's fine, to be clear.  I don't think that's a flaw in the IETF.  The
IETF is trying to do one thing (create general standards for the Internet)
and Debian is trying to do something far, far different and more immediate
(create and maintain a usable operating system that runs on real-world
computers).  Obviously they will be organized differently along the lines
required to achieve those goals.  But the IETF, particularly in recent
years, has increasingly become an industry consortium in which
representatives of companies negotiate with each other over how to
implement interoperable standards for their products.  Not a community of
hobbyists who are building something in large part for the joy of it.

The IETF is an excellent example of an organization where you largely have
to pay people to get them to participate in it.  There are certainly some
people who participate in IETF working groups for fun, but compared to
Debian I'm fairly sure it's limited.  People largely participate in the
IETF because they're trying to accomplish something specific *outside* the
IETF for which an IETF standard would be useful, or because they're being
paid to do so.  Not, at least to the degree that is the case in Debian,
because participating is *itself* fun and exciting and meaningful.

-- 
Russ Allbery (r...@debian.org)   

Re: Censorship in Debian

[Russ Allbery]

Miles Fidelman  writes:

> I think you're minimizing the level of investment & commitment it takes
> to either use Debian, particularly in production, and even more,
> minimizing the efforts of upstream, and kernel, developers upon whom
> Debian ultimately depends.

I really don't think I am, particularly since I've also done many of those
things, but I'm also a bit baffled as to why you think that you should get
to decide what I do with my volunteer time when you're not paying me.  I
mean, that's really what this comes down to.  Of *course* the people who
are members of the Debian project have the primary say it what it does.

> There are also those who contribute by providing support - e.g.,
> answering user questions on Debian lists.

And those people can join the project as voting members so that they can
have a say.  (I would love to see more of that, in fact; it's important to
include people in our community who do other things than package.)

> As far as I can tell, the only people who count, in Debian decision
> making, are packagers - which strikes me as a rather bizarre case of the
> tail wagging the dog.

Seriously, if you want control over something that you use, you have to
put resources into it, whether that is time or money.  You can purchase
something and have the influence of a customer and whatever contract you
can get, or you can put in sweat equity and get a voice that way.  Those
are pretty much your choices, apart from government-controlled projects.
This isn't a very radical concept.

> I remain amazed how much the impacts on users, systems administrators,
> and upstream developers were dismissed as irrelevant.

You list those things as if they're somehow distinct, when many (most,
probably) Debian Developers are all of those things.

> On a larger note, I point to the IETF as an example of a much larger
> community, running huge infrastructure, where pretty much anyone who
> shows up has a voice.

Do you know how the IETF funding model works, and how the Debian funding
model works?  You do know that the parent organization of the IETF has
paid employees, right?

The IETF is a lot more like the Linux Foundation than it is like Debian.
And that model has its place in the world, but I wouldn't be a Debian
Developer if Debian were funded and run that way.

> I'm sorry to say this, but the only value that Debian provides to the
> world, is packaging.  And, personally, over time, I've found it more and
> more necessary to download, build, and compile from source - reducing
> the value of Debian.

> Pretty soon, I expect I'll be migrating.

Okay?  I mean, you say that like you expect me to be upset, but I'm
totally okay with that, and I wish you the best of luck with whatever
operating system you migrate to.

I've said this before, but I think it's an important reality check: it
doesn't matter nearly as much who uses Debian, or how many people use
Debian, because we are not a company or a product, we don't sell
something, we're not trying to make a profit or maintain some growth
curve, and we're not part of this capitalist system.  We are building a
Linux distribution, to a very large extent, for each other, and
delightfully other people also find it useful.  Sometimes those people
even join us!  Which is great!

But we are delightfully not beholden to anyone outside the project, apart
from the much-appreciated donations of funding and equipment of course,
for our goals or even our survival.  Which means that we can have a much
more collaborative, communal decision-making process that doesn't obsess
over market share or retaining or monetizing every individual user.

> And, next time I do any serious developing, I expect the only init
> scripts I'll provide are sysvinit based.  That suggests that my platform
> will be something other than Debian.

I hope you have fun and enjoy that platform!  I'm very glad that you will
be able to find a platform that is a better fit for you.

-- 
Russ Allbery (r...@debian.org)   

Re: Censorship in Debian

[Miles Fidelman]

On 1/7/19 10:06 PM, Russ Allbery wrote:


Miles Fidelman  writes:


On the other hand, the IETF seems to do just fine - with a much larger
base of participants, and a lot more room for discussion and debate on
contentious issues.  Global infrastructure, with distributed ownership,
lots of stakeholders, all held together by agreements, with the decision
processes open to pretty much anybody who shows up.  The process puts
pretty much everyone else to shame - with lots to be learned from it.

Speaking as someone who is a listed author on three published RFCs and
chaired one IETF working group, I will take Debian process over IETF
process any day, and find your description of the IETF pretty
entertaining.  :)


Well yeah, but which "works" better in terms of results? Particularly, 
as viewed by those who are impacted by the process?


In the case of IETF, it sure seems like the needs of users, network 
operators, and equipment makers are well represented.  As compared to 
Debian, where I see little regard for either users, or upstream developers.


The WG & IETF lists tend to have less bull twaddle - though the ICANN 
transition was an interesting period, and a far more open process, if 
somewhat a foregone conclusion.



Also, please note that many IETF participants are paid as part of their
job to participate in the IETF.  (We keep coming back to that.)  That's
true of some Debian contributors as well, of course, but I strongly
suspect the percentage is lower.


Now that's definitely true.  Back in my BBN days, I was only 
peripherally involved (I tended to work on projects that contributed to 
standards work, but generally didn't go to the meetings) - I definitely 
envied some of the travel opportunities afforded to the folks who went 
to the meetings, on the company dime.  Me, I got to go to DoD meetings 
(though some of those were also in "interesting" places).


Miles



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Censorship in Debian

[Scott Kitterman]

On Monday, January 07, 2019 07:06:28 PM Russ Allbery wrote:
> Miles Fidelman  writes:
> > On the other hand, the IETF seems to do just fine - with a much larger
> > base of participants, and a lot more room for discussion and debate on
> > contentious issues.  Global infrastructure, with distributed ownership,
> > lots of stakeholders, all held together by agreements, with the decision
> > processes open to pretty much anybody who shows up.  The process puts
> > pretty much everyone else to shame - with lots to be learned from it.
> 
> Speaking as someone who is a listed author on three published RFCs and
> chaired one IETF working group, I will take Debian process over IETF
> process any day, and find your description of the IETF pretty
> entertaining.  :)
> 
> Also, please note that many IETF participants are paid as part of their
> job to participate in the IETF.  (We keep coming back to that.)  That's
> true of some Debian contributors as well, of course, but I strongly
> suspect the percentage is lower.

Similarly here (also three RFCs, but never chaired a working group).

The IETF rough consensus model is very useful in many circumstances.  I've 
used it successfully in multiple settings outside the IETF to great success in 
both moving technical work forward or driving decision making in a closed 
group to closure.  It's not relevant to the problem a group like the Debian 
tech ctte has, however.

Groups like the tech ctte have a different problem than an IETF working group.  
They have to make final decisions on things that affect the project as a 
whole, many of which are not amenable to consensus building (as an example, 
the init system decision was going to be sysv init or not sysv init - there 
was no middle ground).

I'll also remind you that the IETF process as a whole is not whoever shows up.  
IETF working groups and IETF last call are open processes.  IESG decision 
making is not.  You can have all the working group consensus you want, if 
there are uncleared discusses against your draft, it's not moving forward.  If 
you want a comparison, the tech ctte is a lot more like the IESG than an IETF 
working group.

Scott K

Re: Censorship in Debian

[Miles Fidelman]

On 1/7/19 9:12 PM, Russ Allbery wrote:

Miles Fidelman  writes:


Well, first off, the process led to the resignation of the chair of the
Technical Committee - out of a feeling that the process had become too
"personalized."

Some decisions are just hard.  I think nearly all of us involved in making
that decision burned out in various ways.  I'm not saying we couldn't have
done a better job... well, hm.  Actually, I am kind of saying that, if by
"couldn't" I include the people that we were at the time with the
emotional reserves that we had and the understanding that we had.

I could certainly do a better job *now* if I could rewind time, but that's
cheating, and humans don't get to do that.


We do get to learn from things, however.



I'm with Steve in that I'm pretty dubious that the process was the core of
why that decision was so hard.  I think it was so hard because it spanned
the gamut from technical to social issues, involved some issues that were
relatively concrete and others that were quite nebulous (such as the
interactions between the goals of the systemd developers and the broader
community), and also involved deep social divisions in the project between
folks who want Debian to be a platform for all things and folks who want
Debian to be more tightly integrated and more technically excellent along
a single axis.



Well, I'd argue that part of it had to do with who had a voice, and who 
didn't.  (More below.)





This stuff is inherently very hard, particularly when friends end up on
opposite sides and believe passionately in how important their concerns
are.

I think we sometimes analyze process to death and refight the last
fourteen wars and dig up problems to argue about them some more.  We're
human, this stuff is hard, some things are going to be brutal to get
through when we disagree, and it's okay to forgive ourselves for not being
perfect.  Or even being pretty shitty at it.

That's not to say that we shouldn't look for opportunities to fix things
that we can.  For example, we certainly uncovered some nasty edge cases in
the voting mechanism for the TC, which are now fixed.  And many of us felt
that people serving for extended periods of time on the TC wasn't socially
healthy for either us or the project, so we fixed that too.

But I think there's a idealistic, utopian tendency among a lot of
technical people, myself included, to believe that any serious conflict or
(from our perspective) incorrect decision is a bug in a process somewhere,
and if we can just find the right process, we can fix the bugs.  And it's
just not true.  Humans are messy and humans disagree, and sometimes stuff
is just really hard, and is going to be really hard no matter how you do
it.


Beyond that, there are a rather large number of folks, impacted by the
decision, who did not have a seat at the table.  Those of us who rely on
Debian in production, for example.  Upstream developers for another.
Some of us knew about the issues & debates, without having a
"franchise," others found out after the fact.  Seems to me that lack of
representation is, in itself, a rather big failure of governance.

Debian is *more* willing to try to take into account the needs of its
users than most free software projects, but Debian is still a volunteer
free software project, and the rule of just about every volunteer,
unfunded free software project is that the people who are doing the work
are the ones who are going to make the decisions.

Think of it this way: the people who are sufficiently invested in the
project to spend our time and energy on it over a long enough period of
time to become members are deeply invested in it and want to control where
it goes.  Plus, we're all volunteers and don't have to work on anything we
don't want to work on, which means maintaining our engagement is
absolutely necessary for the project to survive.



I think you're minimizing the level of investment & commitment it takes 
to either use Debian, particularly in production, and even more, 
minimizing the efforts of upstream, and kernel, developers upon whom 
Debian ultimately depends.  There are also those who contribute by 
providing support - e.g., answering user questions on Debian lists.


As far as I can tell, the only people who count, in Debian decision 
making, are packagers - which strikes me as a rather bizarre case of the 
tail wagging the dog.  I remain amazed how much the impacts on users, 
systems administrators, and upstream developers were dismissed as 
irrelevant.


On a larger note, I point to the IETF as an example of a much larger 
community, running huge infrastructure, where pretty much anyone who 
shows up has a voice.


I understand your desire to have a say in something that's important to
you, but, well, if it's that important to you, the New Maintainer process
is right over there?  We always need more help.  Absent that, the people
who have put their blood, sweat, and tears into the project are the people
who 

Re: Censorship in Debian

[Russ Allbery]

Miles Fidelman  writes:

> On the other hand, the IETF seems to do just fine - with a much larger
> base of participants, and a lot more room for discussion and debate on
> contentious issues.  Global infrastructure, with distributed ownership,
> lots of stakeholders, all held together by agreements, with the decision
> processes open to pretty much anybody who shows up.  The process puts
> pretty much everyone else to shame - with lots to be learned from it.

Speaking as someone who is a listed author on three published RFCs and
chaired one IETF working group, I will take Debian process over IETF
process any day, and find your description of the IETF pretty
entertaining.  :)

Also, please note that many IETF participants are paid as part of their
job to participate in the IETF.  (We keep coming back to that.)  That's
true of some Debian contributors as well, of course, but I strongly
suspect the percentage is lower.

-- 
Russ Allbery (r...@debian.org)   

Re: Censorship in Debian

[Miles Fidelman]

On 1/7/19 8:48 PM, Eldon Koyle wrote:


On Mon, Jan 7, 2019 at 6:18 PM Miles Fidelman
 wrote:

On 1/7/19 7:57 PM, Steve Langasek wrote:


On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:

On 1/7/19 10:57 AM, Ian Jackson wrote:

Miles Fidelman writes ("Re: Censorship in Debian"):

On 1/6/19 1:38 AM, Steve Langasek wrote:

[systemd stuff]

[systemd stuff]



The process that was followed was:

   - the Technical Committee was called on to make a decision about the
 default init system in Debian (a technical matter).
   - the TC decided.
   - the Debian developers as a whole declined to overrule this decision via
 GR.

I have no sympathy for people who have so little actual investment in the
Debian Project that they haven't even read the constitution to understand
that they don't have a franchise in such decisions, but then come onto the
project's mailing lists after the fact to express outrage at a technical
decision that they disagree with.


Well, first off, the process led to the resignation of the chair of the
Technical Committee - out of a feeling that the process had become too
"personalized."

Beyond that, there are a rather large number of folks, impacted by the
decision, who did not have a seat at the table.  Those of us who rely on
Debian in production, for example.  Upstream developers for another.
Some of us knew about the issues & debates, without having a
"franchise," others found out after the fact.  Seems to me that lack of
representation is, in itself, a rather big failure of governance.


I think one of the reasons Debian is able to function as well as it has is
because they aren't required to put stuff out to a vote from the entire
planet.  Having technical people (developers) make technical decisions
seems appropriate, even if you disagree with the decision as a user.


On the other hand, the IETF seems to do just fine - with a much larger 
base of participants, and a lot more room for discussion and debate on 
contentious issues.  Global infrastructure, with distributed ownership, 
lots of stakeholders, all held together by agreements, with the decision 
processes open to pretty much anybody who shows up.  The process puts 
pretty much everyone else to shame - with lots to be learned from it.





There are just as many people who would be griping about sysvinit at this
juncture.  Yes, it was nice to know what your init system was doing, but
there are a lot of features that are not provided by sysvinit but are provided
by systemd.



I'm hesitant to re-litigate the issue, but it's not about "know(ing) 
what your init system is doing," it's about impacts on both those of us 
who must administer systems, and on upstream developers.  To an awful 
lot of us, the added features of systemd add nothing, but the impacts 
are major, and damaging.


It continues to amaze me how much the interests of packagers dominate 
Debian, pushing aside the interests of those who actually develop code, 
and those who use it.  Yes, APT is great, and perhaps the primary 
selling point of Debian - but only up to a point.






To suggest that a different process would have resulted in a different
outcome is to demand the Debian constitution be rewritten to let someone
else get their way.

To suggest that a different process would have made the same outcome more
palatable to those on the losing side of the decision is naive.

Maybe you personally would have felt better about the outcome, if you
personally had been consulted.  But that doesn't scale, and provides no
basis for an amendment to the Debian decision-making processes.

Personally, as someone who's been involved in other organizations, and
governance processes, I disagree, on all points.  I also suggest that
your categorical rejection of the possibility that things could be done
better, is illustrative of the toxicity of the current process.

I think part of the toxicity is inherent in communicating via a mailing list.

It is very easy to feel attacked when someone points out a problem with
your argument (especially if you disagree with their counterpoints) -- even
more so when you have spent hours trying to make a logical argument that
hopefully won't offend anyone.


Maybe - but we've kind of grown up in this world.  A lot of us in the 
networking world like to quote Postel's law:  "be conservative in what 
you do, be liberal in what you accept from others."  I've always found 
that it applies very well to email communication.  Unfortunately, it 
strikes me that people have become awfully touchy, and quick to take 
offense, these days.  Personally, I find it more uncivil when people 
take offense, than when people give it.


(It's worth noting that while "fighting words" are recognized, under 
some circumstances, as an exception to the 1st Amendment, it's pretty 
hard to avoid legal liability for violently responding to fighting 
words.  "Them's fighting words," and "them's fighting words, asshole," 
are legitimate responses.  

Re: Censorship in Debian

[Eldon Koyle]

On Mon, Jan 7, 2019 at 6:18 PM Miles Fidelman
 wrote:
>
> On 1/7/19 7:57 PM, Steve Langasek wrote:
>
> > On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
> >> On 1/7/19 10:57 AM, Ian Jackson wrote:
> >>> Miles Fidelman writes ("Re: Censorship in Debian"):
>  On 1/6/19 1:38 AM, Steve Langasek wrote:
> > [systemd stuff]
>  [systemd stuff]

> > The process that was followed was:
> >
> >   - the Technical Committee was called on to make a decision about the
> > default init system in Debian (a technical matter).
> >   - the TC decided.
> >   - the Debian developers as a whole declined to overrule this decision via
> > GR.
> >
> > I have no sympathy for people who have so little actual investment in the
> > Debian Project that they haven't even read the constitution to understand
> > that they don't have a franchise in such decisions, but then come onto the
> > project's mailing lists after the fact to express outrage at a technical
> > decision that they disagree with.
>
>
> Well, first off, the process led to the resignation of the chair of the
> Technical Committee - out of a feeling that the process had become too
> "personalized."
>
> Beyond that, there are a rather large number of folks, impacted by the
> decision, who did not have a seat at the table.  Those of us who rely on
> Debian in production, for example.  Upstream developers for another.
> Some of us knew about the issues & debates, without having a
> "franchise," others found out after the fact.  Seems to me that lack of
> representation is, in itself, a rather big failure of governance.
>

I think one of the reasons Debian is able to function as well as it has is
because they aren't required to put stuff out to a vote from the entire
planet.  Having technical people (developers) make technical decisions
seems appropriate, even if you disagree with the decision as a user.

There are just as many people who would be griping about sysvinit at this
juncture.  Yes, it was nice to know what your init system was doing, but
there are a lot of features that are not provided by sysvinit but are provided
by systemd.


> >
> > To suggest that a different process would have resulted in a different
> > outcome is to demand the Debian constitution be rewritten to let someone
> > else get their way.
> >
> > To suggest that a different process would have made the same outcome more
> > palatable to those on the losing side of the decision is naive.
> >
> > Maybe you personally would have felt better about the outcome, if you
> > personally had been consulted.  But that doesn't scale, and provides no
> > basis for an amendment to the Debian decision-making processes.
>
> Personally, as someone who's been involved in other organizations, and
> governance processes, I disagree, on all points.  I also suggest that
> your categorical rejection of the possibility that things could be done
> better, is illustrative of the toxicity of the current process.

I think part of the toxicity is inherent in communicating via a mailing list.

It is very easy to feel attacked when someone points out a problem with
your argument (especially if you disagree with their counterpoints) -- even
more so when you have spent hours trying to make a logical argument that
hopefully won't offend anyone.

-- 
Eldon Koyle

Interested in Collaborating

[Jess Holmes]

 Hi there,

I'm reaching out to you to see if you would be open to working together. I
would like to sponsor a post on your site via link insertion or submit a
guest post.

For a link insertion, I'd be happy to send more details over if you are
interested. As for a post, I could do a write-up and provide quality
content for you in exchange for a link within the article. Let me know what
you think and I hope to hear from you soon.

Thank you!

[image: Crediful]

Jess Holmes

Outreach Director
*E* j...@crediful.com
*W* crediful.com

*Disclaimer:* The contents of this email are confidential and are intended
solely for the addressee. If this email was not intended for you, please
discard it immediately.

Re: Censorship in Debian

[Miles Fidelman]

On 1/7/19 7:57 PM, Steve Langasek wrote:


On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:

On 1/7/19 10:57 AM, Ian Jackson wrote:

Miles Fidelman writes ("Re: Censorship in Debian"):

On 1/6/19 1:38 AM, Steve Langasek wrote:

[systemd stuff]

[systemd stuff]

I appreciate that the fights over systemd have been a defining
experience for many of us.  Many of us are still bitter, me included.
I also appreciate that in some respects these fights are still,
unfortunately, being fought and harm is still being done (although
things are much less bad than they were).
But I really don't think it is helpful to link the recent arguments
over behaviour in the project, with init system diversity problems.
The issues are very different.  And the toxic emotional and political
baggage from the init system stuff is really bad.  So bringing init
system stuff into this conversation about acceptable conduct just
increases the hurt and argument, but does not lead to any better
conclusions.

With all due respect - and recognizing your central involvement in the
init-system-neutrality issue – I have to disagree with you here.
IMHO, the issues are VERY similar - having to do with groupthink, diversion
from groupthink, and really, really poor processes (and perhaps attitudes).

The process that was followed was:

  - the Technical Committee was called on to make a decision about the
default init system in Debian (a technical matter).
  - the TC decided.
  - the Debian developers as a whole declined to overrule this decision via
GR.

I have no sympathy for people who have so little actual investment in the
Debian Project that they haven't even read the constitution to understand
that they don't have a franchise in such decisions, but then come onto the
project's mailing lists after the fact to express outrage at a technical
decision that they disagree with.



Well, first off, the process led to the resignation of the chair of the 
Technical Committee - out of a feeling that the process had become too 
"personalized."


Beyond that, there are a rather large number of folks, impacted by the 
decision, who did not have a seat at the table.  Those of us who rely on 
Debian in production, for example.  Upstream developers for another.  
Some of us knew about the issues & debates, without having a 
"franchise," others found out after the fact.  Seems to me that lack of 
representation is, in itself, a rather big failure of governance.




(I have a great deal of sympathy for users who were frustrated with the
actual decision, and worried about the impact of such a major change on
their future use of Debian.  I just don't have any sympathy for those who
channeled that frustration into toxic posts on the mailing lists that sought
to browbeat Debian into changing course.)

I categorically reject the notion that a different process should have been
followed.  Giving a formal voice to a wider range of stakeholders in Debian
(i.e.: Debian users as opposed to Debian Developers) would not have made the
discussion less acrimonious; it would not have eliminated the feelings of
upset at the conclusion.  This was a decision about a default, which there
could only be one of.  There were always going to be winners and losers.


It might, however, have led to the Technical Committee giving more 
weight to the impacts of the decisions.




The Debian Technical Committee voted unanimously to move away from sysvinit
as the default.


And to making systemd the default, rather than init-neutral.  And Ian 
resigned over the issue.





To suggest that a different process would have resulted in a different
outcome is to demand the Debian constitution be rewritten to let someone
else get their way.

To suggest that a different process would have made the same outcome more
palatable to those on the losing side of the decision is naive.

Maybe you personally would have felt better about the outcome, if you
personally had been consulted.  But that doesn't scale, and provides no
basis for an amendment to the Debian decision-making processes.


Personally, as someone who's been involved in other organizations, and 
governance processes, I disagree, on all points.  I also suggest that 
your categorical rejection of the possibility that things could be done 
better, is illustrative of the toxicity of the current process.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Censorship in Debian

[Steve Langasek]

On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
> On 1/7/19 10:57 AM, Ian Jackson wrote:

> > Miles Fidelman writes ("Re: Censorship in Debian"):
> > > On 1/6/19 1:38 AM, Steve Langasek wrote:
> > > > [systemd stuff]
> > > [systemd stuff]
> > I appreciate that the fights over systemd have been a defining
> > experience for many of us.  Many of us are still bitter, me included.
> > I also appreciate that in some respects these fights are still,
> > unfortunately, being fought and harm is still being done (although
> > things are much less bad than they were).

> > But I really don't think it is helpful to link the recent arguments
> > over behaviour in the project, with init system diversity problems.

> > The issues are very different.  And the toxic emotional and political
> > baggage from the init system stuff is really bad.  So bringing init
> > system stuff into this conversation about acceptable conduct just
> > increases the hurt and argument, but does not lead to any better
> > conclusions.

> With all due respect - and recognizing your central involvement in the
> init-system-neutrality issue – I have to disagree with you here.

> IMHO, the issues are VERY similar - having to do with groupthink, diversion
> from groupthink, and really, really poor processes (and perhaps attitudes).

The process that was followed was:

 - the Technical Committee was called on to make a decision about the
   default init system in Debian (a technical matter).
 - the TC decided.
 - the Debian developers as a whole declined to overrule this decision via
   GR.

I have no sympathy for people who have so little actual investment in the
Debian Project that they haven't even read the constitution to understand
that they don't have a franchise in such decisions, but then come onto the
project's mailing lists after the fact to express outrage at a technical
decision that they disagree with.

(I have a great deal of sympathy for users who were frustrated with the
actual decision, and worried about the impact of such a major change on
their future use of Debian.  I just don't have any sympathy for those who
channeled that frustration into toxic posts on the mailing lists that sought
to browbeat Debian into changing course.)

I categorically reject the notion that a different process should have been
followed.  Giving a formal voice to a wider range of stakeholders in Debian
(i.e.: Debian users as opposed to Debian Developers) would not have made the
discussion less acrimonious; it would not have eliminated the feelings of
upset at the conclusion.  This was a decision about a default, which there
could only be one of.  There were always going to be winners and losers.

The Debian Technical Committee voted unanimously to move away from sysvinit
as the default.

To suggest that a different process would have resulted in a different
outcome is to demand the Debian constitution be rewritten to let someone
else get their way.

To suggest that a different process would have made the same outcome more
palatable to those on the losing side of the decision is naive.

Maybe you personally would have felt better about the outcome, if you
personally had been consulted.  But that doesn't scale, and provides no
basis for an amendment to the Debian decision-making processes.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Appeal procedure for DAM actions

[Jonathan Wiltshire]

On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote:
> 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.

To clarify following a query in private: the notification to the committee
includes the rationale given by the Developer. DAM handling the
various notifications is purely to reduce the admin burden on the appealer,
not to keep secrets from the committee.


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

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

Re: Debian, debutsav, CoC and Debconf 2016 and different meanings to gender-diversity.

[shirish शिरीष]

Correction :-

On 07/01/2019, shirish शिरीष  wrote:
> Dear all,
>
> I would request people to read it in full, maybe take some time and
> then respond.
>
> Also please CC me if somebody responds as I'm not subscribed to the
> list but did read the archives of this month and the last :)
>
> Recently, Debutsav was organized in Kerala. You can read about the
> event at debutsav.in and whatever I could recollect and share at [1]
>
> Obviously I had to keep it short as it was supposed to be mostly about
> the technical aspects of the 2-day mini-conf/meetup rather than also
> the social side.
>
> Having been 'singed' on couple of previous occasions by A-H,  as part
> of the team I advised the organisers to have both a CoC and have a
> team with women to fully staff it and have some sort of button, badge
> or something which people could call upon to sort out in either
> situations of hostilities or any sort of abusive behavior happens.
> While the latter could not be prepared due to shortness of time ( it
> was hardly 2 weeks where everything was organized) but I do feel we
> could have done better.
>
> I along with others also opined that we should have two women on the
> panel instead of just one just to keep the panel sort of
> gender-neutral but only Shruti was on the panel. I simply do not know
> the reasons to presume or assume why it happened but do care enough to
> point it out and to ask what we could and should have been better. It
> wasn't as if talent wasn't around.  As far as people from LGBTQIA+ or
> non-binary people are concerned, I am afraid though, the road is long
> ahead as it wasn't even part of the discussions anywhere.  Although I
> do hope after de-criminalization of Sec 377 we would see these
> conversations happen [2] [3]
>
> One of the intersting conversations I had with quite a few
> participants is how much they had looked at the website and the CoC.
> Sadly, it seems many didn't, at least not in any detail.
> Interestingly, it was both the genders who didn't take or have the
> time.
>
> I do remember some blog posts in the pasts, maybe in Pycon 2018 or in
> some other international conference, they had a banner which had the
> CoC written on it. Maybe that could be something that both Debconf and
> the various miniconferences could emulate aside from agreeing to the
> CoC ?
>
> Coming to the debian side of things, there doesn't seem to much
> documentation about gender diversity as far as documentation is
> concerned. In fact, the wiki doesn't seem to have an article on gender
> diversity and even the diversity statement is all to brief for
> somebody new to the term 'gender diversity' . It doesn't tell the
> person anything.  Please put yourself in the shoes of 22 year old
> person who may come across this page for the first time and see the
> term for the first-time. It is a touch point so it would be nice if we
> could either elaborate it either there or link it to some page which
> better defines the terminology and the context.  [4] [5]
>
> Even in debconf the term diversity is only a single page which doesn't
> explain what diversity is apart from sharing few examples . Could it
> be defined more better, more coherently, I hope so  From what little I
> understand of the meaning and the terminology, it is a broad inclusive
> term rather than an exclusive term but then I'm no expert. I hope we
> can come up with some better wording or at least a somewhat better
> structure than the current wiki page we have. [6]
>
> Coming to Debconf 2016, few of the blog posts I wanted to write and
> had partially written about were about Rhonda and my interaction with
> them (using Sarah Sharp's pronouns [7] .)  I wanted to share both
> their celebrations, the interactions and questions raised and answered
> about gender, my own uneasiness in how should I address them when
> writing as a third-person in a blog post as both the terms he/she felt
> wrong. I shared one of my blog posts with few DD's whom I respect and
> hold in high-esteem so they may help me in this delicate situation but
> none of them answered.


Oops, seems the correct name is now Sage Sharp. Apology -

>
> Eventually I junked the blog posts  because I felt even excluding them
> from few presentations where they made an interesting point or an
> insight, wouldn't that be an erasure of identity?
>
> I could have used 'somebody asked x or y question' which many a times
> I do use simply because I don't remember a person's name but in this
> situation it was different and I couldn't publish the blog posts with
> that knowledge in good conscience. With no way out, I simply junked
> the posts. In light of recent happenings it does seem that that the
> DD's did me a favor. It is very much possible that they were pretty
> much confused or indeterminate as I was. What would be a good way to
> address this ?
>
> Could there be a possibility of having of having a debian-diversity
> mailing list on lists.debian.org where some of these 

Appeal procedure for DAM actions

[Joerg Jaspert]

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.


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.


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]



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



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.



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.


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]


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


--
bye, Joerg


signature.asc
Description: PGP signature

Re: On demotions to DM status.

[Ben Hutchings]

On Mon, 2019-01-07 at 12:02 +0500, Andrey Rahmatullin wrote:
> On Mon, Jan 07, 2019 at 12:47:34AM +, Richard Hecker wrote:
> > Does the project want to say that a DM is less trustworthy than a DD? 
> Yes, obviously. Just like a DM is more trustworthy than a non-DM.

It would be more accurate to say that a DD is more *trusted* than a DM,
and a DM is more *trusted* than a contributor who has neither status.
We hope that our application processes exclude most of those who are
not trustworthy, but we can't be sure.

Ben.

> > Should a DM becoming a DD be viewed as a promotion?
> But it is, isn't it? Or, at least, as a next step.
> 
-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




signature.asc
Description: This is a digitally signed message part

Debian, debutsav, CoC and Debconf 2016 and different meanings to gender-diversity.

[shirish शिरीष]

Dear all,

I would request people to read it in full, maybe take some time and
then respond.

Also please CC me if somebody responds as I'm not subscribed to the
list but did read the archives of this month and the last :)

Recently, Debutsav was organized in Kerala. You can read about the
event at debutsav.in and whatever I could recollect and share at [1]

Obviously I had to keep it short as it was supposed to be mostly about
the technical aspects of the 2-day mini-conf/meetup rather than also
the social side.

Having been 'singed' on couple of previous occasions by A-H,  as part
of the team I advised the organisers to have both a CoC and have a
team with women to fully staff it and have some sort of button, badge
or something which people could call upon to sort out in either
situations of hostilities or any sort of abusive behavior happens.
While the latter could not be prepared due to shortness of time ( it
was hardly 2 weeks where everything was organized) but I do feel we
could have done better.

I along with others also opined that we should have two women on the
panel instead of just one just to keep the panel sort of
gender-neutral but only Shruti was on the panel. I simply do not know
the reasons to presume or assume why it happened but do care enough to
point it out and to ask what we could and should have been better. It
wasn't as if talent wasn't around.  As far as people from LGBTQIA+ or
non-binary people are concerned, I am afraid though, the road is long
ahead as it wasn't even part of the discussions anywhere.  Although I
do hope after de-criminalization of Sec 377 we would see these
conversations happen [2] [3]

One of the intersting conversations I had with quite a few
participants is how much they had looked at the website and the CoC.
Sadly, it seems many didn't, at least not in any detail.
Interestingly, it was both the genders who didn't take or have the
time.

I do remember some blog posts in the pasts, maybe in Pycon 2018 or in
some other international conference, they had a banner which had the
CoC written on it. Maybe that could be something that both Debconf and
the various miniconferences could emulate aside from agreeing to the
CoC ?

Coming to the debian side of things, there doesn't seem to much
documentation about gender diversity as far as documentation is
concerned. In fact, the wiki doesn't seem to have an article on gender
diversity and even the diversity statement is all to brief for
somebody new to the term 'gender diversity' . It doesn't tell the
person anything.  Please put yourself in the shoes of 22 year old
person who may come across this page for the first time and see the
term for the first-time. It is a touch point so it would be nice if we
could either elaborate it either there or link it to some page which
better defines the terminology and the context.  [4] [5]

Even in debconf the term diversity is only a single page which doesn't
explain what diversity is apart from sharing few examples . Could it
be defined more better, more coherently, I hope so  From what little I
understand of the meaning and the terminology, it is a broad inclusive
term rather than an exclusive term but then I'm no expert. I hope we
can come up with some better wording or at least a somewhat better
structure than the current wiki page we have. [6]

Coming to Debconf 2016, few of the blog posts I wanted to write and
had partially written about were about Rhonda and my interaction with
them (using Sarah Sharp's pronouns [7] .)  I wanted to share both
their celebrations, the interactions and questions raised and answered
about gender, my own uneasiness in how should I address them when
writing as a third-person in a blog post as both the terms he/she felt
wrong. I shared one of my blog posts with few DD's whom I respect and
hold in high-esteem so they may help me in this delicate situation but
none of them answered.

Eventually I junked the blog posts  because I felt even excluding them
from few presentations where they made an interesting point or an
insight, wouldn't that be an erasure of identity?

I could have used 'somebody asked x or y question' which many a times
I do use simply because I don't remember a person's name but in this
situation it was different and I couldn't publish the blog posts with
that knowledge in good conscience. With no way out, I simply junked
the posts. In light of recent happenings it does seem that that the
DD's did me a favor. It is very much possible that they were pretty
much confused or indeterminate as I was. What would be a good way to
address this ?

Could there be a possibility of having of having a debian-diversity
mailing list on lists.debian.org where some of these touchy topics
could be untied or unknotted in a civil manner ?

Sorry for being too long and there is a strong possibility that I
shared or coupled too many things together but I do feel strongly that
they are all related to one another.

I would point out that I scanned the mail 

Re: Censorship in Debian

[Miles Fidelman]

Ian,

On 1/7/19 10:57 AM, Ian Jackson wrote:


Miles Fidelman writes ("Re: Censorship in Debian"):

On 1/6/19 1:38 AM, Steve Langasek wrote:

[systemd stuff]

[systemd stuff]

I appreciate that the fights over systemd have been a defining
experience for many of us.  Many of us are still bitter, me included.
I also appreciate that in some respects these fights are still,
unfortunately, being fought and harm is still being done (although
things are much less bad than they were).

But I really don't think it is helpful to link the recent arguments
over behaviour in the project, with init system diversity problems.

The issues are very different.  And the toxic emotional and political
baggage from the init system stuff is really bad.  So bringing init
system stuff into this conversation about acceptable conduct just
increases the hurt and argument, but does not lead to any better
conclusions.

With all due respect - and recognizing your central involvement in the 
init-system-neutrality issue – I have to disagree with you here.


IMHO, the issues are VERY similar - having to do with groupthink, 
diversion from groupthink, and really, really poor processes (and 
perhaps attitudes).


It's not unlike a current issue in the church I belong to.  On the one 
hand, it's an issue over a change to one of the church's external signs 
- but it has blown up into an issue over who gets to make decisions 
(volunteer committee vs. a community-wide vote), hurt feelings among 
volunteers when someone deigns to protest a unilateral action (which 
seem to trump dissent), a rather authoritarian board that is currently 
asserting far more power than granted by our bylaws (IMHO), a seeming 
general acceptance of these authoritarian tendencies ("we don't care 
about that particular issue, so we're staying out of it"), and a general 
unwillingness to discuss issues via email list (leaving no other venue, 
other than stage managed meetings, called by our board, at their 
leisure, and at inconvenient times).  People have left over this kind of 
bull, and I'm thinking seriously about it myself (after 30 or so years).


Where Debian is concerned, the same set of issues are playing out - this 
time over the Code of Conduct, but they also played, with (IMHO) far 
more serious consequences over the systemd issues - including your own 
resignation as chair of the Technical Committee.  As you put it then, 
"While it is important that the views of the 30-40% of the project who 
agree with me should continue to be represented on the TC, I myself am 
clearly too controversial a figure at this point to do so. I should step 
aside to try to reduce the extent to which conversations about the 
project's governance are personalized."  HOW IS THIS NOT THE SAME 
SCENARIO PLAYING OUT AGAIN?"


The current discussion makes it clear that we obviously didn't learn 
anything from the systemd issue – to the severe detriment of the project 
as a whole. It strikes me as particularly relevant to point this out – 
as evidence of significant underlying pathologies that go well beyond 
the narrow issue of "acceptable conduct."  As you put it "the toxic 
emotional and political baggage from the init system stuff is really 
bad" - IMHO, the root causes are the same, and we're going through it again.


Respectfully,

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Censorship in Debian

[Martin Steigerwald]

Ian Jackson - 07.01.19, 19:00:
> > For me, any code of conduct and its enforcement needs to be based on
> > actual behavior, never on assuming intentions or assuming about how
> > people are.
> 
> Once again, there is a difference between *assuming* and *inferring*.
> 
> I doubt this will really convince you.  But I couldn't let stand the
> claim that I am *assuming* bad intentions.  I most certainly am not.

I am sorry, that was the conclusion I arrived at as I read your initial 
mail. Thank you for clarifying.

I am still with just looking at behavior for any enforcement, but I 
agree that on repetition of harmful behavior after have been warning, a 
stronger enforcement might be needed.

I am not positive whether that has been the case here, but unless I 
missed I did not yet hear any official statement of anti-harassment or dam 
team. I do not have a complete picture, I wonder whether anyone has. So 
I just let it be as that for now.

Thanks,
-- 
Martin

Re: Censorship in Debian

[flackjacket5]

Jan 7, 2019, 3:57 PM by ijack...@chiark.greenend.org.uk:

>
> The issues are very different.  And the toxic emotional and political
> baggage from the init system stuff is really bad.  So bringing init
> system stuff into this conversation about acceptable conduct just
> increases the hurt and argument, but does not lead to any better
> conclusions.
>
>

Looks like DAM and DPL brought the toxic baggage when they decide to impose 
demotions on volunteers

DAM change Debian from being a community to THe Apprentice.  Sad.





--
Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
https://tutanota.com 

Re: Censorship in Debian

[Ian Jackson]

Martin Steigerwald writes ("Re: Censorship in Debian"):
> Ian Jackson - 05.01.19, 18:17:
> > Very competently toxic people will calculate precisely what they can
> > get away with: they will ride roughshod over weak victims or in
> > situations with less visibility; when challenged by an authority who
> > can impose consequences, they will lie and obfuscate and distract as
> > much as they can get away with.  They will turn the dispute about
> > their personal bad behaviour into a big poltical fight so as to
> > increase the cost of enforcing the rules against them.  And if that
> > fails they will do precisely as much as is needed to avoid further
> > punishment.
> 
> Have you actually really seen such kind of behavior?

Yes.

> I disagree with calling people toxic.

Well, I don't want to name names, of course.  But it hardly seems
controversial that toxic people exist ?  We have maybe 1000-10,000
active contributors.

So, making for a moment the assumption that there is no correlation
either way with someone's toxicity and being a Debian contributor, we
should expect our community to have between 1 and 10 people who are
more toxic/abrasive/dishonest/whatever than 99.9% of the population.

We can make a much nicer community by applying a gatekeeping
function...

> Also I am not sure how you'd come to know about about any agenda behind 
> the behavior. How do you know about the intentions?

It is not actually necessary to infer intention.  Since it is not
necessary, in order to take action, to prove that bad behaviour is
malicious.

Rather, it is sufficient to observe that continuation of the behaviour
is harmful, and that lesser efforts to stop it have failed.


But, it is useful to understand intentions because they can be
predictive.  This is true even for intentions inferred from past
behaviour (which is the only way you will ever discover the real
intention of someone dishonest, obviously):

> One part of the code of conduct as I got it is to assume good 
> intentions, here, if I got you correctly you assume bad, harmful 
> intentions for at least some people, people that you call toxic.

No, I am not assuming bad behaviour.  My first assumption if I see an
abrasive message is that the person is having a bad day.  My first
assumption if I see someone stating a falsehood is that they are
mistaken.

These assumptions can, however, be overcome by evidence.

In particular, things like: refusal to acknowledge error or apologise;
use of sophistry of various kinds; escalation in response to every
criticism; making mutually inconsistent statements or repeating
falsehoods already debunked; significantly worse behaviour to weaker
victims or in less auditable scenarios.  Recurrence of the above.

> For me, any code of conduct and its enforcement needs to be based on 
> actual behavior, never on assuming intentions or assuming about how 
> people are.

Once again, there is a difference between *assuming* and *inferring*.

I doubt this will really convince you.  But I couldn't let stand the
claim that I am *assuming* bad intentions.  I most certainly am not.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Censorship in Debian

[Martin Steigerwald]

Hello,

Ian Jackson - 07.01.19, 16:57:
> Miles Fidelman writes ("Re: Censorship in Debian"):
> > On 1/6/19 1:38 AM, Steve Langasek wrote:
> > > [systemd stuff]
> > 
> > [systemd stuff]
> 
> I appreciate that the fights over systemd have been a defining
> experience for many of us.  Many of us are still bitter, me included.
> I also appreciate that in some respects these fights are still,
> unfortunately, being fought and harm is still being done (although
> things are much less bad than they were).
> 
> But I really don't think it is helpful to link the recent arguments
> over behaviour in the project, with init system diversity problems.
> 
> The issues are very different.  And the toxic emotional and political
> baggage from the init system stuff is really bad.  So bringing init
> system stuff into this conversation about acceptable conduct just
> increases the hurt and argument, but does not lead to any better
> conclusions.

As much IMO its important to let go, forgive and clean up anything still 
left over from that debate… I agree with you.

I got the impression that from reading in various threads that the 
current issues seem to be used as a dumping ground for other stuff that 
is not directly related to it.

I wonder whether it would be a good idea to have something about non-
violent, i.e. peaceful communication in one of the next major community 
events like Debconf and maybe also one about mediation.

I have read the the KDE project had something about non-violent 
communication in their last KDE Academy event.

It appears challenging to me to sort out the issues about the recent 
Code of Conduct enforcement actions without communicating face to face 
or at least via voice.

Thanks,
-- 
Martin