Re: Proposal: mediators

[Thomas Lange]

> thanks for wrinting it down, but I still think the better option is
> to spend some Debian funds to let a professional mediator handle
> this, 
Great idea! IMO it should be very easy for the AH team or any DD to
ask the DPL for getting money for an external mediator if a situation
is escalating. If we would already had implemented this, some hundreds
of mails would have been saved.

Please, please spend money for this. It's worth it more than anything
else.

-- 
regards Thomas

Re: Appeal procedure for DAM actions

[Thomas Lange]

Thanks for this details analysis and for your suggestions for
improvements. I like especially the idea of changing the timeline and
to remove the update of the DAM statement (3. Appealer statement).
I also was wondering what "turning it into a warning" really means.
I think a warning should be done by DAM before someone gets expelled.

Again, this posting helps me as a non-native speaker to raise my
voice.
-- 
regards Thomas

Re: Appeal procedure for DAM actions

[Anthony Towns]

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

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

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

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

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

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

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

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

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

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

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

Doing things that way avoids this risk/caveat.

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

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

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

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

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

to something more like:

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

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

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

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

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

> 5. NM-Committee vote
> ---

Re: Proposal: mediators

[Bernd Zeimetz]

Hi,


I would like to propose a system for mediation that can be used before
or during expulsion processes, and for other purposes.
[...]


thanks for wrinting it down, but I still think the better option is
to spend some Debian funds to let a professional mediator handle
this, who is not involved in Debian politics at all.
A view that is not biased at all makes much more sense, especially
when people in the project do not like the outcome...

Thanks,

Bernd


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Appeal procedure for DAM actions

[Joerg Jaspert]

On 15276 March 1977, Karsten Merker wrote:


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.

I'm not sure whether I understand correctly what exactly is meant
by "[The members of the NMC] are expected not to solicit further
input" - does that mean that the members of the NMC are not
allowed to ask questions about facts outside/above those
explicitly presented by DAM and those contained in the written
appealer statement, i.e. the NMC members are forbidden to do any
sort of research about the situation on their own?  If yes, that
would seem like an inappropriate limitation to me.


As written, it is not an inquiry. But a check of the decision that DAMs have
made. NMC should not need to dig around for long. And should not be forced by
someone claiming "but if you only ask this one more, or this one, then you MAY
see the light". Nah. Its both sides giving their views, and the NMC deciding
on that. End. If one side can not present enough to support their case, then
their case fails, it shouldn't be up to the NMC to dig out the stuff for them.

Of course we can not forbid them to (say) use google or something, if they
want to. But thats their own personal fun, not required of the process.


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.



[Description of how the vote can turn out bad for the person]


Well. I see your point. But I do disagree with your solution:


Therefore the clause "If more than half of the NMC (excluding DAM) abstain
or do not vote, the decision is not overturned" would IMHO need to be
removed completely from the rules.


I don't think so. We don't want to end up with a system where, say, you "just"
put pressure on a dozen people to abstain, then have "your friend" vote
overturn, and boo, all is fine again.

So while I agree there might be possible improvements in how the vote goes, I
don't think just deleting that one sentence is it. But I'm not an expert in
voting systems, so am happy for any input. Could go with a quorum (and then
count abstains for it) and requiring a (3 quarter?) majority of voters?! Could
go with something else? Somebody come up with a nice thing, please. :)

--
bye, Joerg

Re: [OT] distributions without systemd

[Miles Fidelman]

On 1/8/19 1:34 PM, Martin Steigerwald wrote:


Miles Fidelman - 08.01.19, 18:16:

I would have been very surprised if you had told me 6 months ago
that
I would be writing this, but:

Please consider Devuan as an alternative.  You have probably seen
awful mails from one or two very toxic trolls pushing Devuan, but
the
actual Devuan developers I have dealt with have been lovely, and on
a
technical level they seem to be doing good work.

Thanks!  It's actually high on my list.  I've been waiting for it to
mature just a bit, and it seems to have.  Any observations on how it
stacks up for a production server?  Anything else that strikes you as
a particularly strong Debian alternative for servers?  (My short
list, right now is Gentoo, Funtoo, Devuan, and FreeBSD.  I'd been
hoping that one of the OpenSolaris derivatives would look solid, but
it's never really happened.  Hypervisors & failover, and replicated
storage are also high on my list).

I suggest you take Devuan related questions to the devuan mailing list
dng¹.


Topic change is definitely appropriate, my apologies. Comparisons of 
distributions, IMHO is within bounds.





One may argue whether Debian's systemd decision process was similar to
what happened now, but discussing distributions and other operating
systems without systemd is clearly off topic on this thread and also off-
topic on the mailing list. It does not add any value to this discussion
and clutters the thread with unrelated stuff.

That said, two of my server VMs run Devuan since a few months and I am
happy so far.

[1] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Thanks,


Thank you.

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

RE: Appeal procedure for DAM actions

[Joerg Jaspert]

On 15276 March 1977, Thomas Lange wrote:


Do you plan an official announcement of this new procedure?


It will end up on d-d-a in a few days, provided someone doesn't find a big
flaw in it.


JFTR: Thanks Enrico for pointing me how to see the list of members
that will vote. Keep in mind that this may change.


Thats a point already added.

--
bye, Joerg

Re: Appeal procedure for DAM actions

[Joerg Jaspert]

On 15276 March 1977, Kurt Roeckx wrote:


we waive the time limit defined in §1 for the cases
from the last 6 months.

Would it make sense to have them 1 week from publishing this
instead?


Thanks for that. Yeah, that offer is not valid forever, but as we normally say
30 days, lets make it 14 days here. That is, the offer is valid until
2019-01-21, that should be enough time to decide if one wants to do it or not.

--
bye, Joerg


signature.asc
Description: PGP signature

Re: Censorship in Debian

[Ian Jackson]

Miles Fidelman writes ("Re: Censorship in Debian"):
> Thanks!  It's actually high on my list.  I've been waiting for it to 
> mature just a bit, and it seems to have.  Any observations on how it 
> stacks up for a production server?  Anything else that strikes you as a 
> particularly strong Debian alternative for servers?

I'm not running it myself.  All I've done is had (positive)
interations with Devuan developers and looked and (and borrowed) some
of their source code.  So I'm afraid you'll have to evaluate that for
yourself.

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

[Russ Allbery]

Miles Fidelman  writes:

> I was watching the discussion on systemd fairly closely.  I could be
> wrong, but very little of the discussions over systemd seemed to reflect
> folks who managed production servers, or kernel developers, or developers
> of key backend software (Apache, MySQL, Postfix, Sympa, ...).

Well, for whatever it's worth, I was managing Debian production servers
during the entire period of that debate (and for about ten years previous
to that).  I was the primary advocate for Stanford running its central
infrastructure on Debian, so I'm familiar with the problems and arguments
for and against using Debian in that sort of environment.  Some of the
other major voices in that debate manage far large production deployments
than I did.

My current employer uses Ubuntu in production, not Debian, for many of the
typical reasons why people use Ubuntu over Debian, but from the
perspective of systemd that's basically the same thing.  Ubuntu went
through essentially the same transition that we did.

I do think distributions have some interesting challenges in the future,
and what our users are asking from us is shifting.  Containers and deep
dependency programming ecosystems are both becoming more common, Go and
Rust take a far different attitude towards how to assemble system
components than C and C++ projects have historically, and cloud
deployments are becoming far more common than hardware deployments for
many of our users.  One of the simultaneously fun and frustrating thing
about this field is that problems are constantly shifting, and new ideas
and new ways of doing things are constantly arising.  Debian certainly
will need to change and explore new and different corners of that, and
feedback from day-to-day users of Debian both inside and outside the
project will be very important to understand how to change.

But, if anything, I think being *more* agile, not less, is where we can
improve the most.  And, of course, always trying to find ways in which we
can have it all at once, where we can: provide a broad and inclusive
platform for making a lot of different choices, so that we don't have to
pick the best choices in advance and over-commit to one way of doing
things.  Which, among other things, calls for init system diversity, and
I'm very glad to see that work continuing (although I personally still
hope that someone will come up with a great init system that has the
highly decoupled properties that people want but that isn't sysvinit with
all of its well-known problems).

I'll stop talking about this here since several folks are saying that we
should keep init systems out of this conversation, and I'm not really
helping.  You just raised some points about the social impact of hard
disagreements, and about how decision-making works in general in Debian,
about which I have strong opinions and really wanted to reply.

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

[OT] distributions without systemd (was: Re: Censorship in Debian)

[Martin Steigerwald]

Miles Fidelman - 08.01.19, 18:16:
> > I would have been very surprised if you had told me 6 months ago
> > that
> > I would be writing this, but:
> > 
> > Please consider Devuan as an alternative.  You have probably seen
> > awful mails from one or two very toxic trolls pushing Devuan, but
> > the
> > actual Devuan developers I have dealt with have been lovely, and on
> > a
> > technical level they seem to be doing good work.
> 
> Thanks!  It's actually high on my list.  I've been waiting for it to
> mature just a bit, and it seems to have.  Any observations on how it
> stacks up for a production server?  Anything else that strikes you as
> a particularly strong Debian alternative for servers?  (My short
> list, right now is Gentoo, Funtoo, Devuan, and FreeBSD.  I'd been
> hoping that one of the OpenSolaris derivatives would look solid, but
> it's never really happened.  Hypervisors & failover, and replicated
> storage are also high on my list).

I suggest you take Devuan related questions to the devuan mailing list 
dng¹. 

One may argue whether Debian's systemd decision process was similar to 
what happened now, but discussing distributions and other operating 
systems without systemd is clearly off topic on this thread and also off-
topic on the mailing list. It does not add any value to this discussion 
and clutters the thread with unrelated stuff.

That said, two of my server VMs run Devuan since a few months and I am 
happy so far.

[1] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Thanks,
-- 
Martin

Re: Censorship in Debian

[Tollef Fog Heen]

]] Miles Fidelman 

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

JFTR (since this keeps being brought up, otherwise I'd much rather we
just let this lie): Ian was not chair of the TC at the time.  Bdale was
(and he did not resign, his term expired on December 31st 2015).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Censorship in Debian

[Miles Fidelman]

On 1/8/19 8:28 AM, Ian Jackson wrote:

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

I've basically been nursing a couple of aging systems.  When next I do a
major upgrade to our server farm, It will be to something other than
Debian.  Until then, the pressure hasn't been there, and I've been -
I've been waiting and watching to see how different alternatives mature
(along with what direction several key server-side applications, on
which we depend, go).

I would have been very surprised if you had told me 6 months ago that
I would be writing this, but:

Please consider Devuan as an alternative.  You have probably seen
awful mails from one or two very toxic trolls pushing Devuan, but the
actual Devuan developers I have dealt with have been lovely, and on a
technical level they seem to be doing good work.



Thanks!  It's actually high on my list.  I've been waiting for it to 
mature just a bit, and it seems to have.  Any observations on how it 
stacks up for a production server?  Anything else that strikes you as a 
particularly strong Debian alternative for servers?  (My short list, 
right now is Gentoo, Funtoo, Devuan, and FreeBSD.  I'd been hoping that 
one of the OpenSolaris derivatives would look solid, but it's never 
really happened.  Hypervisors & failover, and replicated storage are 
also high on my list).


Miles



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

Re: Proposal: mediators

[Sam Hartman]

I think that rather than writing down a procedure like this it would be
better to  get some success cases of trying something along these lines.
So, for example, I'd recommend that you and people who have similar
views volunteer to be available as mediators.
Once people use your services, and you have some practical experience
then worry about writing it up.

I am interested in mediation  but my approach is very different than
yours.

* I think the emotions and feelings are more important than the facts

* I am interested in working  in cases where there is a desire to reach
  settlement

* I think that your emphasis on facts and a statement of facts fails to
  account for some of the significant realities in dealing with conduct
  issues

So, while I'm interested in mediation-like things, I am not interested
in this project.  I'm trying to find ways I can olunteer to help that
are more aligned with my goals.


However,  I've seen others on discussions recently who may have goals
aligned with yours.
Debian is a community where we move forward by trying things out.
Make your services available, let people know.
Whether people are interested in using the services will be one gage of
success.

--Sam

Re: Censorship in Debian

[Sam Hartman]

> "Scott" == Scott Kitterman  writes:

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

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

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

Scott> Groups like the tech ctte have a different problem than an
Scott> IETF working group.  They have to make final decisions on
Scott> things that affect the project as a whole, many of which are
Scott> 
Scott> I'll also remind you that the IETF process as a whole is not
Scott> whoever shows up.  IETF working groups and IETF last call are
Scott> open processes.  IESG decision making is not.  You can have
Scott> all the working group consensus you want, if there are
Scott> uncleared discusses against your draft, it's not moving
Scott> forward.  If you want a comparison, the tech ctte is a lot
Scott> more like the IESG than an IETF working group.

I've served on the Debian TC, I've served as an IETF working group
chair, and I've served on the IESG.  I think I have a fairly good handle
on the differences between the IETF and Debian processes.

The IETF process is good for developing a consensus where you want to
focus on technical quality and where you have the right stakeholders as
motivated participants.
It requires a certain familiarity with consensus building to avoid a
number of pitfalls.
IT IS NOT TIME BOUNDED.  It's great for situations where you are more
concerned with the right decision than concerned with a decision within
a particular time line.
There are ways that you can try to control the time the IETF process
takes, and it's even possible to do that if you can get a consensus on
what the timeline is and on the technical tradeoffs that are in scope
to achieve that timeline.

Debian did not meet those conditions for the init system decision by the
time it came to the TC.
Debian had already done a lot of consensus building.  We understood the
scope of the problem, we understood some of the complexities surrounding
having multiple init systems.
TC members did do some additional excellent work curating and
summarizing that knowledge (I was not on the TC at the time but was
following the discussion).

A consensus process would not have achieved the goal shared by most of
the project of having a decision in time for the jessie release.

I am unlikely to contribute to this thread again; like Ian I think
init systems are off topic.

--Sam

Proposal: mediators

[Charles Plessy]

Dear all,

I would like to propose a system for mediation that can be used before
or during expulsion processes, and for other purposes.

Please note that while I use the word "mediation", there may be a better
one.  Thus, it is not needed to reply to me that what I propose is not a
real mediation if this is the case.  Please focus on  what I propose and
not on how I named it !

### Goal

The goal will be to help all parties or their proxies to prepare
fact-driven synthethic position statements that can be presented to
others, in particular to the decision makers, both to help them to take
their decision and to help announce it in a way that is the most
resilient to misunderstanding and the criticisms that it triggers.  It
is also hoped that the mediation process may also sometimes help both
parties to settle their disagreement, although it will not be considered
a failure when settlement is not reached.

### Who

I think that the mediator should not be doing this task on a regular
basis, to avoid burn-out, to avoid being in contact with too many
private information, and to avoid being perceived as partial.  In order
to ensure that the mediators are available and have demonstrated some
williness to communicate with others, I propose to select them randomly
among the Developers who have been the application maintainer of at
least one person.  A call would be valid one day; in case of no answer,
another mediator would be called, and so on (better strategies using
further filtering could be done if it does not look realistic that a
volunteer could be found after 10 calls).  The call would be initiated
by the decision makers, when they feel that this mediation process would
help them.

### How

The mediator will contact both sides separately and will never connect
them nor request or suggest direct communication between them.  The
mediator will minimise the volume of communication, aiming at addressing
each issue only once.  The mediator will ask each party to sort the
points they want to make in order of relevance (I hope that this process
will help to reduce the number of points), summarise them, and ask if
the summary is clear and accurate (I think that when somebody can
recognise one's views in the words of another person, it is a good
indication that there is mutual understanding).  The mediator will then
present the views of each side to the other side, and ask if there is
agreement, disagreement, and recommend to avoid lengthy rebuttals.  The
mediation is only part of the conflict resolution, and it is already a
great achievement to agree to disagree.  Lastly, even when clear action
points emerge from the discussion, the mediator will never propose an
implementation, leaving that choice to the decision makers.

### Privacy

Communication will be written, encrypted and kept confidential.  It may
be given to the decision makers if needed and must be destroyed after a
reasonable delay (advice welcome).  The mediator will never disclose the
contents of the messages and information exchanged.

### Limitations

To avoid any legal consequences and to avoid damage that could be caused
by improper consideration of a victim's suffering, this mediation system
should never be used when the facts being discussed are so grave that
they could be punished by a justice court.

### Summary

In light of the expulsion being discussed at the moment, my impression
is that such a process could, or even still can, be useful to underline
what are the points considered most important by each side, and which
action of the other side can solve them (I am not going to speculate
here).  I also hope that this proposal may be more broadly useful,
especially for the issues at the inteface between behaviour and
technique (typical examples are when an NMU are a commit revert trigger
a latent conflict).

### Next step

I personally would prefer to avoid long point-to-point discussions on
the weakest parts of what I wrote above.  How about reacting on what you
liked (if you liked some part), and just sending the rest to /dev/null ?

Thank you for reading so far, and have a nice day !

Charles

PS: please pardon my English, it might betray my thoughts.

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: Appeal procedure for DAM actions

[Kurt Roeckx]

On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote:
> 
> we waive the time limit defined in §1 for the cases
> from the last 6 months.

Would it make sense to have them 1 week from publishing this
instead?


Kurt

Re: Censorship in Debian

[Ian Jackson]

Miles Fidelman writes ("Re: Censorship in Debian"):
> I've basically been nursing a couple of aging systems.  When next I do a 
> major upgrade to our server farm, It will be to something other than 
> Debian.  Until then, the pressure hasn't been there, and I've been - 
> I've been waiting and watching to see how different alternatives mature 
> (along with what direction several key server-side applications, on 
> which we depend, go).

I would have been very surprised if you had told me 6 months ago that
I would be writing this, but:

Please consider Devuan as an alternative.  You have probably seen
awful mails from one or two very toxic trolls pushing Devuan, but the
actual Devuan developers I have dealt with have been lovely, and on a
technical level they seem to be doing good work.

Regards,
Ian.

RE: Appeal procedure for DAM actions

[Thomas Lange]

> On Tue, 08 Jan 2019 09:14:53 +0100, Joerg Jaspert  
> said:

> On 15276 March 1977, Thomas Lange wrote:
>> I think you should forward this mail to nm-commit...@nm.debian.org.

> Noted, but I think it makes more sense to point them at this whenever 
such an
> appeal starts, as the group is a dynamic one. If I send it now, there 
might be
> a pretty different set receiving an appeal in the future, so for now, I 
assume
> they either read it on -project or do not (yet) need to care.
Do you plan an official announcement of this new procedure? IMO
debian-project is not read by all (e.g. I'm not subscribed to it) and
because some people missed transparency in the past it would be good
to inform all.


JFTR: Thanks Enrico for pointing me how to see the list of members
that will vote. Keep in mind that this may change.

> The list is at: https://nm.debian.org/public/managers
> Look for the "Ctte" column. If you have javascript enabled, you can
> click on the column title to sort/group by it.

-- 
regards Thomas

Re: Censorship in Debian

[Martín Ferrari]

On 05/01/2019 21:24, Scott Kitterman wrote:

> I also have a lot of sympathy for people who feel they have been marginalized 
> and it being worth working on making them feel welcome/not marginalized, but 
> I 
> think it has limits (and maybe this is the core of my concern relative to the 
> CoC).  Not everyone can be accommodated.  There's broad agreement that 
> someone 
> who insists on an unfettered right to be an ass (for most any definition) 
> isn't going to be made to feel welcome, but there's also a limit to how far 
> the project can reasonably go in catering to people's concerns without it 
> getting ridiculous.

Replying in a purely personal fashion here.

For full disclosure, let me say that I belong to a couple of minorities,
while also enjoying the benefits of other important privileges. I
consider myself some kind of social justice advocate, and I profoundly
believe in fostering diversity and protecting the most vulnerable people
in society.

At the same time, I am full aware that being oppressed does not make you
immune from being an asshole. And I also believe that there are people
out there requesting ridiculous accommodations, or even using the goals
of social justice for personal benefit. Myself, I have been on the
receiving end of that kind of people, and so I can completely understand
what you are saying here.

> Military pilots of aircraft with ejection seats are limited both to a minimum 
> and maximum height.

Yup. And I would not even be able to be a commercial pilot because of my
eyesight, and many things like that. I think those are reasonable.

> All accommodations have practical limits.  In my reading of the Diversity 
> Statement and CoC, I don't see that recognized and I fear how far it will be 
> taken in the future.

Yes, but I am not sure this is something that can be codified in a
reasonable and useful way. The alternative is to trust the delegates to
be "reasonable", and elect a DPL that might change them if they are
going in a direction that you find too extreme.

If you think about it, this is how it works in many places in the real
world, with policies slowly shifting to the left or right and the window
of acceptable discourse and policies shift too.


-- 
Martín Ferrari (Tincho)

Re: Appeal procedure for DAM actions

[Jonathan Carter]

On 2019/01/08 13:38, Enrico Zini wrote:
>> If that's the case, are you talking about multiple appeals from people
>> who have had their membership revoked, or is it that I interpreted it
>> wrong and that anyone can appeal?
> 
> I'm clarifying the corner case in which two people have had their
> membership revoked, and are in a position to appeal in overlapping time
> frames.

Ah, thanks for clearing that up.

> Enrico who unfortunately cannot run this kind of procedure through
>valgrind --tool=helgrind

I'm not familiar with valgrind, so I'll take your word for it.

-Jonathan

Re: Appeal procedure for DAM actions

[Enrico Zini]

On Tue, Jan 08, 2019 at 01:21:20PM +0200, Jonathan Carter wrote:

> If I read the original text correctly in item 1 above, it seems that
> only the person who's rights got revoked can appeal?

Yes, correct.

> If that's the case, are you talking about multiple appeals from people
> who have had their membership revoked, or is it that I interpreted it
> wrong and that anyone can appeal?

I'm clarifying the corner case in which two people have had their
membership revoked, and are in a position to appeal in overlapping time
frames.

This should almost never happen, but given that we have waived the time
limit for the cases in the last 6 months, we have potentially
overlapping time frames now.


Enrico who unfortunately cannot run this kind of procedure through
   valgrind --tool=helgrind

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Appeal procedure for DAM actions

[Jonathan Carter]

On 2019/01/08 12:43, Enrico Zini 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.
> 
> In case two people appeal at the same time, the NMC should not have to
> discuss multiple issues in parallel.
> 
> if an appeal is requested while another appeal is already ongoing,
> starting the later appeal is delayed until after the committee has
> finished voting on the previous ones.

If I read the original text correctly in item 1 above, it seems that
only the person who's rights got revoked can appeal?

If that's the case, are you talking about multiple appeals from people
who have had their membership revoked, or is it that I interpreted it
wrong and that anyone can appeal?

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Censorship in Debian

[Christian Kastner]

On 2019-01-08 11:23, Miles Fidelman wrote:
> On 1/8/19 4:57 AM, Jonathan Dowland wrote:
>> On Tue, Jan 08, 2019 at 04:16:15AM -0500, Miles Fidelman wrote:
>>> What I am asserting is that the Debian Social Contract explicitly states 
>>> that:
>>>
>>> "4. Our priorities are our users and free software
>> …
>>> I DO assert that, as one user, I don't see this being honored in the 
>>> breach, with decisions around systemd, and init-system-neutrality being in 
>>> direct opposition to this principal.
>>
>> I don't agree that those decisions were in direct opposition. There
>> wasn't a single answer that was unanimously in the interests of all
>> users, because all users do not agree on the desired outcome. Not even
>> "init-system-neutrality" as you put it would be unambiguously in the
>> best interests of all users. Clearly you would have preferred a
>> different outcome. You aren't alone: but correspondingly, many users got
>> the answer they wanted, and many others didn't have a dog in the race.
> 
> Differing opinions here.  Somehow, major changes in direction, that go
> against "the Unix way," and have direct impact on both systems
> administration & upstream development, seem not to be in the interests
> of many users.

There are no differing opinions here. Jonathan clearly acknowledged your
position. He then pointed out that other positions existed, and that no
answer unanimously in the interest of all users existed.

You keep arguing as if only your position mattered. All positions were
considered, a decision was made which of these served this interest of
the users best. That's complying with the mandate to prioritize users.

> The systemd rollout just broke too many things.

I doubt that the systemd switch was even noticed by 95% of users and
if, then I'd wager that it was a net positive effect.

-- 
Christian Kastner

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

[shirish शिरीष]

Reply in-line :-

On 08/01/2019, Rhonda D'Vine  wrote:
>Hey.
>

Dear Rhonda,

>  Even while I write at some spots in "we" term (where I am mostly
> referring to with my diversity team hat on) this is still primarily my
> own reply.  Especially in the cases where I use the "I" term explicitly.
>
> * shirish शिरीष  [2019-01-07 21:09:22 CET]:
>> 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.
>
>  Can you please not speak of "both the genders" when you seemingly
> acknowledge (thanks for mentioning that explicitly :)) the existence of
> non-binary people?  That's quite confusing.
>

Ah... I had to read the line twice and the context above to see what you mean.
To be clearer,  we didn't have any trans people at all in debutsav but
just men and women.
Hence the conversations were with both of them in a casual manner just to know
how much they read what was on the site.

>> 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 ?
>
>  While this image doesn't has the CoC written over it, it has a QR code
> with the link to http://deb.li/dcoc on it:
>  https://photos.app.goo.gl/nvtbqDiTUi8eCqwd7

That would work I guess but I at least don't see an issue in displaying
the CoC either at FrontDesk/registration so it serves as a gentle reminder.

The banner or standee doesn't need to be event-specific but is a general
standee which could be used multiple times in multiple events.

>  We (as in the diversity team) plan to use that graphic and put it into
> the webpage too.  This is work in progress, as is the proper announce
> about the team through the debian-devel-announce mailing list.
>

Nice.

>> 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]
>
>  You are right, there is definitely a lot of room for improvement here.
> We are aware of that and are welcoming people who would like to get
> involved. :)
>

I don't know whether I would be the right person because I probably would
get things wrong more than right (foot in mouth comes in mind). See
below for more -

>  But: The diversity statement was discussed at length a few years ago,
> and it was considered that it makes more sense to have it rather shorter
> than longer to not cause issues with trying to list minorities, focusing
> on the minority terms, singling them out and on the other hand missing
> some that might then feel excluded.  So the brevity of the diversity
> statement is intentional.
>

That I remember.

>> 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 Sage Sharp's pronouns [7] .)
>
>  Even I consider you mean it well, please don't refer to me using
> someone elses pronouns.  That feels wrong.  My pronouns are
> she/her/hers.
>

I see and understand, sorry for presuming and assuming.

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

Re: Appeal procedure for DAM actions

[Enrico Zini]

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.

In case two people appeal at the same time, the NMC should not have to
discuss multiple issues in parallel.

if an appeal is requested while another appeal is already ongoing,
starting the later appeal is delayed until after the committee has
finished voting on the previous ones.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Censorship in Debian

[Miles Fidelman]

On 1/8/19 4:57 AM, Jonathan Dowland wrote:


On Tue, Jan 08, 2019 at 04:16:15AM -0500, Miles Fidelman wrote:
What I am asserting is that the Debian Social Contract explicitly 
states that:


"4. Our priorities are our users and free software

…
I DO assert that, as one user, I don't see this being honored in the 
breach, with decisions around systemd, and init-system-neutrality 
being in direct opposition to this principal.


I don't agree that those decisions were in direct opposition. There
wasn't a single answer that was unanimously in the interests of all
users, because all users do not agree on the desired outcome. Not even
"init-system-neutrality" as you put it would be unambiguously in the
best interests of all users. Clearly you would have preferred a
different outcome. You aren't alone: but correspondingly, many users got
the answer they wanted, and many others didn't have a dog in the race.


Differing opinions here.  Somehow, major changes in direction, that go 
against "the Unix way," and have direct impact on both systems 
administration & upstream development, seem not to be in the interests 
of many users.  The systemd rollout just broke too many things.


But I brought this up primarily in context of discussing Debian decision 
processes, and as a rebuttal to a previous statement that effectively 
said only contributor's opinions count - whereas the social contract 
explicitly says that users are a highest priority.





Pretty soon, I expect I'll be migrating.


Honestly I think you're very overdue to go. You've been in the Debian
community for a long time. Long enough that you could have become a
member (non-packaging, voting rights) if you had wanted to. I think
you've made valuable contributions to our project, particularly in some
of your posts to debian-user. But from what I've read from you recently,
I think it would be in your own best interests to move on and establish
yourself in a community more aligned with your beliefs and tastes. You
wouldn't be alone, other long-time valued Debian contributors have done
that in the wake of the init system decision. And in my opinion, your
more recent mailing lists contributions to Debian have not been as
valuable as ones from the past: case in point, this thread. We're raking
over old coals here, and it's not helping you, or Debian.



Well, thanks, I think.

I've basically been nursing a couple of aging systems.  When next I do a 
major upgrade to our server farm, It will be to something other than 
Debian.  Until then, the pressure hasn't been there, and I've been - 
I've been waiting and watching to see how different alternatives mature 
(along with what direction several key server-side applications, on 
which we depend, go).


Meanwhile, there's no reason not to continue responding to questions, 
where I can add value.


The discussion about the censorship issues, and toxic processes, is one 
that's near and dear to my heart - having been involved in governance of 
various organizations and projects, and working professional on projects 
that involve online decision & deliberation support.


Best,

Miles



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

Re: Censorship in Debian

[Jonathan Dowland]

On Tue, Jan 08, 2019 at 04:16:15AM -0500, Miles Fidelman wrote:
What I am asserting is that the Debian Social Contract explicitly 
states that:


"4. Our priorities are our users and free software

…
I DO assert that, as one user, I don't see this being honored in the 
breach, with decisions around systemd, and init-system-neutrality 
being in direct opposition to this principal.


I don't agree that those decisions were in direct opposition. There
wasn't a single answer that was unanimously in the interests of all
users, because all users do not agree on the desired outcome. Not even
"init-system-neutrality" as you put it would be unambiguously in the
best interests of all users. Clearly you would have preferred a
different outcome. You aren't alone: but correspondingly, many users got
the answer they wanted, and many others didn't have a dog in the race.


Pretty soon, I expect I'll be migrating.


Honestly I think you're very overdue to go. You've been in the Debian
community for a long time. Long enough that you could have become a
member (non-packaging, voting rights) if you had wanted to. I think
you've made valuable contributions to our project, particularly in some
of your posts to debian-user. But from what I've read from you recently,
I think it would be in your own best interests to move on and establish
yourself in a community more aligned with your beliefs and tastes. You
wouldn't be alone, other long-time valued Debian contributors have done
that in the wake of the init system decision. And in my opinion, your
more recent mailing lists contributions to Debian have not been as
valuable as ones from the past: case in point, this thread. We're raking
over old coals here, and it's not helping you, or Debian.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

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

[Rhonda D'Vine]

   Hey.

 Even while I write at some spots in "we" term (where I am mostly
referring to with my diversity team hat on) this is still primarily my
own reply.  Especially in the cases where I use the "I" term explicitly.

* shirish शिरीष  [2019-01-07 21:09:22 CET]:
> 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.

 Can you please not speak of "both the genders" when you seemingly
acknowledge (thanks for mentioning that explicitly :)) the existence of
non-binary people?  That's quite confusing.


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

 While this image doesn't has the CoC written over it, it has a QR code
with the link to http://deb.li/dcoc on it:
 https://photos.app.goo.gl/nvtbqDiTUi8eCqwd7

 We (as in the diversity team) plan to use that graphic and put it into
the webpage too.  This is work in progress, as is the proper announce
about the team through the debian-devel-announce mailing list.

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

 You are right, there is definitely a lot of room for improvement here.
We are aware of that and are welcoming people who would like to get
involved. :)

 But: The diversity statement was discussed at length a few years ago,
and it was considered that it makes more sense to have it rather shorter
than longer to not cause issues with trying to list minorities, focusing
on the minority terms, singling them out and on the other hand missing
some that might then feel excluded.  So the brevity of the diversity
statement is intentional.

> 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 Sage Sharp's pronouns [7] .)

 Even I consider you mean it well, please don't refer to me using
someone elses pronouns.  That feels wrong.  My pronouns are
she/her/hers.

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

 The best approach to that would be ask the person directly instead of
sending a mail to a public mailing list about the confusion, without a
Cc to the person.  That usually would feel much more welcoming and being
taken serious.  Thanks for understanding. :)

> 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.
 
 That's quite some pity.  Why didn't it cross your mind to simply ask me
instead?  That would have felt like you are interested in resolving your
confusion, and actually would have moved it forward. :)

> 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

Re: Censorship in Debian

[Miles Fidelman]

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


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 really depends on what you're measuring.  Somehow, "new release of 
Debian" doesn't seem anywhere on the scale of "keeping global 
infrastructure working properly."  Of course, that involves a lot more 
than just IETF.






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.


Well, yes, IETF is becoming more of an industry consortium - but I sure 
recognize a lot of the WG directors as names from the old days, who most 
assuredly are motivated by a lot more than a paycheck.  (Though yes, 
most folks in academia, industry, and government do like to get paid.  
And to attend meetings in interesting places on the company dime.)




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.


Pay, yes.  Create something outside of IETF - well, probably true, as 
well - but that something is "The Internet" - which is still, very much 
a work in progress.


Re. Debian - I used to think that the project founders, leaders, and 
core developers saw Debian as something more than a hobby or pet 
project.  These days, I'm not so sure.  Linux (and Linus) certainly went 
from academic project to key piece of software driving much of the 
world's computers – and the kernel development community has organized 
itself with that in mind.  Stallman, and the FSF, always, and still, see 
what they're doing as serving a broader purpose and community.  Debian 
used to present as the serious distribution for serious people (and 
perhaps, as the alternative to Red Hat) - and as a platform on which 
people could, and did depend.  These days, it sure doesn't act that way.


Miles Fidelman

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

Re: Censorship in Debian

[Miles Fidelman]

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


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.


I am not asserting any right to decide what you do with your volunteer time.

What I am asserting is that the Debian Social Contract explicitly states 
that:


"4. Our priorities are our users and free software

We will be guided by the needs of our users and the free software 
community. We will place their interests first in our priorities. We 
will support the needs of our users for operation in many different 
kinds of computing environments ... "


I DO assert that, as one user, I don't see this being honored in the 
breach, with decisions around systemd, and init-system-neutrality being 
in direct opposition to this principal.


I also suggest that users, and the "free software community" do not have 
a voice in the matter.


As to "Of *course* the people who are members of the Debian project have 
the primary say it what it does."  That does not necessarily follow.  
There are plenty of cases, in purely voluntary organizations, where 
Trustees (elected or otherwise) are expected to represent the interests 
of the broader community, and/or the broader mission of an 
organization.  An awful lot of organizations fail when current office 
holders become to insular and unresponsive.





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.


Sure.  But in an environment as convoluted as the FOSS ecosystem, where 
and how one contributes can become pretty indirect.  For example, Debian 
depends rather heavily on the Linux kernel, the gnu tools, hosting by 
the OSU OSL - do they have a seat at the table?  What about people who 
contribute to the MoinMoin wiki, used by the Debian project?



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.


I was watching the discussion on systemd fairly closely.  I could be 
wrong, but very little of the discussions over systemd seemed to reflect 
folks who managed production servers, or kernel developers, or 
developers of key backend software (Apache, MySQL, Postfix, Sympa, ...).





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?


Yes.  Yes I do.  I also know that that ISOC was created, nominally as a 
membership organization, but no more, to create a home for the IETF 
outside of the US Government.  It's the IETF secretariat, or whatever 
it's called these days, that mostly has paid staff.  And... so?




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 mat