[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Authority behind Banning Someone from the Project




TL;DR: I decided to ban someone from the project completely.  Members of
ftpmaster, DAM, and the community team all agree.  The person had
already been banned from our lists and expelled from the project as a
developer.  This is an explanation of how that decision fits with our
constitution.  If you don't care about the constitutional complexities
of Debian, stop reading a few sentences ago.
The specific statement I made is available at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953378;msg=12

We intentionally split up authority.  The account managers can decide
whether someone is a developer, and can remove someone from the
maintainer keyring.

Ftpmaster decides who gets to upload software.

Listmaster gets to decide who posts to lists.

The owner@bts decides who gets to interact with our bug system.

We have IRC operators, etc.

Salsa admins get to decide who  has access to Salsa.

DSA gets to decide who has accounts.

(Some of those positions are delegated; some are not.  I'm going to
pretend they are all delegated in this mail.)

However, there comes a point where someone's behavior is problematic
enough that we need to say as a community "goodbye; you are not welcome
here."
There are a lot of different Debian communications channels.
Waiting for the person to disrupt each individual channel and for the
people responsible for that channel to act is inconsistent with creating
a community where we want to work.


Under our constitution section 5.1 (4), the DPL gets to decide matters
where there is not someone else to make a decision.  But under the
constitution: "Once a particular decision has been delegated and made
the Project Leader may not withdraw that delegation."
In addition, there are certain decisions, like whether someone is a
developer that the Project Leader may delegate but not make themselves.

People often claim that there cannot be overlapping areas of
responsibility in delegations.  That's actually not what the
constitution says at all.  The constitution doesn't even say that the
DPL's powers cannot in some cases overlap with powers of a delegate
(although there is some complexity there.)
What the constitution does say is that the DPL cannot reconsider a
specific decision delegates have made.
In this instance, I believe the DPL and delegates are in accord.

So, since banning someone completely is not actually currently
delegated, one interpretation is that  the project leader could do that.
Clearly this could lead to conflicts.  As an example if the account
managers made someone a developer, but the leader tried to ban them from
the project entirely, we'd end up with the rediculous situation that
they were simeltaneously both a developer and not welcome in the
project.

Such conflicts could happen independent of the DPL.
As an example, if DSA refused to give someone an account but DAM
declared them to be a developer (and didn't review that decision after
DSA explained their reasoning), that would also be a conflict.

In practice, those conflicts are not likely to happen, and certainly are
not happening here.

Here's my take.
The DPL doesn't have to act in a vacuum.
When there are decisions that  do not fall within a delegation but that
are related to specific delegations, the DPL can facilitate a discussion
among related parties just as the DPL can facilitate a discussion with
the broader project.
That's what I did here.
There was a clear consensus  among members of the delegated teams in
question that I talked to.
I have every reason to believe that  those members were not outliers
among there teams.
I did not wait for the teams involved to each come to a decision using
their internal decision making process.
Multi-level consensuses don't work well.  It's better to build a
consensus among people than among teams of people where the individual
teams each need to come to internal decisions.

I think it would be problematic for the DPL to make a decision where
there was a conflict.  The conflict is particularly problematic if it is
a conflict between the DPL's decision and a decision that the DPL could
not make.
I cannot conceive of a situation where it would be correct for the DPL
to try and ban someone from the project that DAM considered to be a
developer.

However, as in this instance, when multiple different delegates have
chosen to exclude someone, I think it is entirely reasonable for the DPL
to wrap that up and make a project-wide decision.

Individual delegates could potentially   ignore the DPL.  As an example
I'm going to write to owner@bts and ask them to exclude the person in
question.
They could say "No, Sam we think you're being unreasonable."
And then we'd have a conflict and we'd have to resolve that conflict.
But especially if I am being reasonable, they are likely to go along
with it.
And actually having someone say "Enough is enough; we're done acting as
individual teams on this issue and we actually have a decision as a
project," is helpful.

As an aside, there are cases where the DPL can act because urgent action
is required; that didn't really apply here, and might be an entirely
different set of issues.

Attachment: signature.asc
Description: PGP signature


Reply to: