Re: Expulsions Policy
On Saturday, January 05, 2019 06:48:31 PM Russell Stuart wrote:
> On Fri, 2019-01-04 at 23:56 -0500, Scott Kitterman wrote:
> > No. That's not how Debian works. This is a volunteer effort, not a
> > bureaucracy. Delegates are delegated certain authorities and it's up
> > to them to decide how to exercise them. If the larger DD community
> > sufficiently disagrees, they can raise a GR on the matter (but please
> > wait until we hear from them as a team and only if you are really,
> > really certain - overriding a DPL delegate is a major thing).
>
> I was waiting for someone to say "but ... Debian's different". No,
> it's not.
Sure it is. Every organization has it's own culture and approach to how it
organized and managed. Debian's is very different than others I am/have been
involved in. That doesn't make it better or worse, just it is what it is.
Some of the Debian approaches to organization are unusual. They aren't the
weirdest I've seen. IETF working group hums to measure the strength of
consensus on an issue probably rate that assessment from me.
I've only been involved with the project for a little over a decade, so I'm
new and still learning.
> For a start I am genuinely puzzled by you saying Debian doesn't have a
> bureaucracy. To me it seems Debian has a much larger bureaucracy than
> most 1000 people organisations I've deal with. We have lots of cogs
> like the DAM grinding away in the background (so many in fact I'm sure
> I don't know them all), court like entities like the TC, more written
> rules than I've seen in most large organisations.
It's less a bureaucracy than a distribution of power in my opinion. The DPL
has huge authority to determine how responsibilities and authorities are
distributed within Debian (delegations), but almost no direct authority to do
any of those things.
> That aside, "That's not how Debian works" sounds like the height of
> hubris to me. Getting groups of unfamiliar people with different
> backgrounds and values together to work towards a common interest is
> something we have been working for centuries. In fact finding better
> ways to do that is probably what has propelled Western society to its
> current pre-eminent position - governments, democracies, corporations,
> trusts, charities, churches, the number of ways we do it is mind
> boggling. Underneath all of them lies some common elements, which you
> can pick up for free where I live from most government offices by
> asking for "model rules" or "model constitution". I gather Debian did
> not do that, because if they did they would have got their first
> expulsion process and we would all know what it is.
Don't confuse me describing how Debian works today with claiming that how it
works today is ideal. You may not like how it works, but it is what it is.
In any case, I'm pretty sure no local government office I can go visit has
detailed instructions on how to run a distributed world-wide technical
development project of 1,000 people.
I have written such documents. I have cajoled people into doing things in
better ways (fun fact, in my experience people have a really hard time
understanding how rough consensus based decision making works and an even
harder time understanding why they might ever want to be involved with it).
> Yet here you come along claiming Debian has found a better way, which
> apparently is appoint people while providing no written guidance on
> what they are expected to do, but we fix that having a GR if they
> displease us. No, just no, it is not a better way.
I claimed no such thing. I placed no value judgment on it at all. Once
again, like it or not, Debian has certain ways of doing things that are well
established. They can probably all be improved. Can they be improved enough
to be worth a few hundred messages on -project? I don't know, it's an open
question.
> Besides your wrong. In most things Debian does we have do have
> policies, reams of them in fact. Policies saying how people join, how
> they retire, how they resolve technical differences. This expulsion
> thing is not the norm - it's an aberration. Most GR's are about
> changing our policies as we learn, not telling teams they have done
> something bad.
I think we have a lot more process than we have policy. For example, for FTP
Team package reviews for licensing the only real policy is the DFSG (technical
parts of the reviews are driven by Debian Policy). It's pretty short and
compact. There's a FAQ and some other information that documents helpful
things, but the DFSG, Debian Policy, and the DPL delegation are what drive how
the team operates. It's not a lot, really.
> > I think you don't have much experience with these kinds of things if
> > you believe that.
>
> I don't know what "things" you are referring to, but if it is working
> in large community groups like "Debian" you are again wrong.
I was referring to trying to get several people who are remote from each
other, in different time zones, with multiple responsibilities (let's not even
get started about the timing of questions relative to various holidays popular
around the world) to focus and agree that text is agreed to by everyone and
correctly states the team's position. In my judgment, if you did, you
wouldn't claim it's not hard.
> > On the FTP Team (of which I'm a non-delegated Assistant) it can take
> > weeks to get agreement on text to send out on an issue. The email I
> > sent relatively recently to d-d-a regarding the team's view on
> > listing individual copyright holders in debian/copyright was
> > literally months in the making.
>
> You are comparing the workload of the FTP team which has to deal with
> many issues a year to workload of imposed by an expulsion process when
> has been used only a few times in Debian's history. I trust you see
> the obvious problem.
I trust you realize that being DAM is not a full-time paid position.
> Obvious problem aside, we apparently think it is necessary to insist
> the Technical Committee provide similar a justification on the cases
> they decide upon each year, yet you are apparently are think asking the
> people who expel members to do the same thing is imposing an
> unreasonable workload. Is how we deal with each other so unimportant?
I never said the workload was unreasonable. I said I understood why these
things take time and I think you should be more patient.
> It probably isn't, because that effort you say is so unreasonable - the
> the DAM actually do it. Did see read the their private email to the
> person concerned - that would be it. This thing you are focusing on,
> the written justification wasn't the change I was asking for as they
> mostly do it now. I was asking for something entirely different -
> transparency.
I think it's fine to ask, but if asking for additional information for
increased transparency, I think it's odd to insist they must have it ready to
give out.
> > Taking care to make sure an email speaks for the team as a whole and
> > is correct is hard and takes time.
>
> Indeed, damned hard. Can you imagine then how hard it must be for the
> DAM to speak and act for the whole project? Yet we ask three people
> to do just that. They had not formal training for it (unless they come
> from a HR background - I don't know), we give them little guidance,
> almost no feedback until incidents like this occur because you can't
> provide feedback without a little transparency, and then you pop up and
> say don't worry - we don't have clear standards we expect you to uphold
> - Debian doesn't work like that. We will just GR you if you get it
> wrong.
Where did I say don't worry about it? I think you are reading far too much
into the mail I wrote. Honestly, I don't think there's much chance of any
such GR succeeding, completely separate from the question of if the decision
was correct or not. I think many DDs will vote to support the DAM because
they don't want to undermine such a key group in the project.
I also don't think "We will just GR you if you get it wrong." is really
correct. You've been a DD long enough to know that when these things happen
there is generally a fair amount of discussion within the project about it. I
believe that the DAMs pay attention to that and might change their mind. GR
is for "I couldn't talk you out of a wrong thing that I feel very, very
strongly about it, so we'll see who the rest of the project agrees with".
When people have done that in the past, it has not always ended well.
Scott K
Reply to: