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

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

Expulsions Policy

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

Contents

  Expulsions Policy Russell Stuart <russell-debian@stuart.id.au> - 2019-01-04 11:50 +0100
    Re: Expulsions Policy Ulrike Uhlig <ulrike@debian.org> - 2019-01-04 12:20 +0100
      Re: Expulsions Policy Russell Stuart <russell-debian@stuart.id.au> - 2019-01-05 05:40 +0100
        Re: Expulsions Policy Scott Kitterman <debian@kitterman.com> - 2019-01-05 06:00 +0100
          Re: Expulsions Policy Russell Stuart <russell-debian@stuart.id.au> - 2019-01-05 09:50 +0100
            Re: Expulsions Policy Scott Kitterman <debian@kitterman.com> - 2019-01-05 10:40 +0100
            Re: Expulsions Policy Steve Langasek <vorlon@debian.org> - 2019-01-06 01:10 +0100
              Re: Expulsions Policy "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com> - 2019-01-07 00:00 +0100

#10113 — Expulsions Policy

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

It's been made plain to me I've done a bad job of explaining myself on
debian-private, and besides it's really the wrong list.  The main
thrust of this post is Debian has done a very poor job of maintaining
it's policy on expelling members, followed by suggestion for
improvements to the policy.

As far as I can tell, the only place document that defining Debian
current policy on expelling members is published is here:

  http://lists.debian.org/debian-devel-announce/2005/08/msg00005.html

That would be a 13 year old post to a mailing list.  To be fair a link
to that post is in the DAM Wiki page, filed under the heading
"Interesting Links".

Compare that to how we treat our engineering policies. They are
available at several places on the web in several different formats,
are regularly updated and we get notified when that happens.  I refer
to them often not only because they easy to find and fast to look up
(packaged, no less), but also because I know people (and bots, the bots
are the worst) are verifying I follow them.  The "I forgot" excuse
isn't likely to fly.

Recent events have shown the expulsion policy is not nearly as well
respected.  That's not a complete surprise, I am somewhat amazed people
knew we have a policy until recently.

It's also not a surprise because for the most part we have no idea
whether it's being followed or not.  There is no way the project
members can verify the people appointed to execute this policy are
following the procedures we agreed on 13 years ago, because all that
policy says about disclosure to the members is "if the nominee decided
to make the discussion public, we will inform the debian-project
mailing list, otherwise the debian-private list will get the
information".  The "information" is the DAM's decision on whether to
expel them or not, only.  To put it bluntly: "the people we are acting
for have no right or need to understand the reasons for our decisions".
I presume we agree to do this because "trust us, we are the DAM".  I
don't know how well that went over at the time, but I'm pretty sure the
trust side of equation has changed so much the approach untenable now.

Still, I expect we could reach a consensus on "trust but monitor".  To
achieve that we need transparency.  For me that means at the very least
when the DAM expels someone our policy must require they justify their
actions in as much detail as the Technical Committee does, and it does
it in a post all members receive.  This is about expelling members,
after all.

Accordingly, I suggest we update our current expulsion policy to say:

    If the DAM decides to expel a Developer they will publish the
    evidence they relied on and their reasoning that lead to the
    expulsion.  The evidence must include:
    - Links to all public information,
    - The number of private representations they received,
    - How many dealt with each type of accusation (eg, abuse,
      deliberate obstruction, policy violations),
    - The DAM's opinion on quality of corroborating evidence in 
      those representations (eg, none, hearsay, beyond reasonable
      doubt).
    If the nominee decided to make the discussion public we will publish
    this one debian-project mailing list, otherwise to the debian-
    private list.

That is my first point.

My second point is about blunting the impact of discussions we have on
the reasons Developers are expelled.  These discussions will always be
divisive.   I think that is unavoidable.  However, having them after
concrete action has been taken, when the only way to change the outcome
is GR is good way of ensuring these discussions end up looking more
like debates to the death, because in some ways they are.

Public warnings have their own advantages - warnings give the Developer
the chance to modify their behaviour, and them being public lets
everyone verify they have been given that chance.  However in the
context of this discussion their main advantage is they give us more
gradual way to deal with discussions on why people are expelled by
providing an opportunity to discuss the reasons for the expulsion when
the stakes are far lower.  If there is GR on the subject, it can be
about policy, not about the actions of some poor DAM member who is just
trying to do his job to the best of their ability.  Once the policy is
decided, the DAM can go about their business without everybody having
to voice their opinion on their ability to do it.

Therefore I suggest we alter the expulsion process to give three
warnings, with no more than 5 years (pick a number) between the first
and the last, and no less than 1 month (pick a number) between
warnings.  The last "warning" will be the expulsion notice, meaning the
DAM will execute the expulsion before issuing it.  These warnings will
published in exactly the same manner as the expulsion above.

Finally, there are things requiring immediate action.  These things
have one common element: they put the projects core activity of
creating and distributing a trusted distribution at immediate risk. 
Examples are attacks on our infrastructure, leaking project
credentials, adding back doors to packages.  For these cases I suggest
we allow the DAM to suspend account and uploading privileges
immediately without notice, but in such cases they must publish their
reasons for doing so in the same manner as above within 2 weeks (pick a
number) of suspension.  After a maximum of 2 months (pick a number) for
comments and further investigation the DAM must either reverse their
decision, or publish a their reasons for proceeding to full expulsion.

[toc] | [next] | [standalone]

#10114

Hi!

Russell Stuart:

> As far as I can tell, the only place document that defining Debian
> current policy on expelling members is published is here:
> 
>   http://lists.debian.org/debian-devel-announce/2005/08/msg00005.html
> 
> That would be a 13 year old post to a mailing list.  To be fair a link
> to that post is in the DAM Wiki page, filed under the heading
> "Interesting Links".

You are misrepresenting this: it has been said outside of this list that
this does not represent an expulsion procedure but a procedure that
makes it possible for DDs to make DAM consider an removal of privileges,
because that's what it is.

I'm not going to reply to your proposals of procedure here, because:

- I'm not convinced that escalating this discussion *now* to -project is
helpful, on top of the avalanche of discussions that we've seen on
another list during the past two weeks.

- Another group of people wants to escalate this discussion to -vote and
seems to be equally working on yet another proposal, as far as I understood.

- DAM has not had the time to react and it has been asked explicitly and
several times to give them this time.

- Did you consider communicating with DAM before writing here?

Please: don't push more on yet another mailing list until the above
points are somewhat settled, i.e. DAM has had time to react and the
other group has started circulating their draft, if they still plan to
do so.

Thank you,
Ulrike

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

#10152

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

On Fri, 2019-01-04 at 10:57 +0000, Ulrike Uhlig wrote:
> You are misrepresenting this: it has been said outside of this list
> that this does not represent an expulsion procedure but a procedure
> that makes it possible for DDs to make DAM consider an removal of
> privileges, because that's what it is.

OK, could somebody clear something up for me please?  Does Debian have
a procedure / policy or something saying what triggers the DAM moving
down the road towards a Developers expulsion (so it's clear when they
must act), and what procedure they follow when expel someone.  I
thought that was it.  Apparently not.

A group having no formal procedures for the decision the DAM just made
is fine for 3 or 6, risky for a 20, and a sure recipe for what I just
witnessed for an organisation as large as Debian.

> - Another group of people wants to escalate this discussion to -vote
> and seems to be equally working on yet another proposal, as far as I
> understood.

They are being very quiet about it, as there were no posts to -vote
this month, and 3 last month all of which were spam.

If you are referring to the proposed GR, they have said repeatedly (to
the point I'm sure they getting tired of it) it's about reversing a
single decision.  It is not about policy, and they appear to be doing
everything to keep policy or any comment of how the DAM implemented out
of it.  We are discussing to different things.

> - DAM has not had the time to react and it has been asked explicitly
> and several times to give them this time.

I'll put it bluntly: they should not need time.  They've just made one
gravest of decisions a Developer one could make.  If they did that
without compiling a dossier of evidence, and then followed a clear line
of reasoning to the decision, then it has to be made clear to them they
haven't done their jobs well.

As it happens, we know they did most of these things.  Kudo's to them. 
Perhaps it is not quite up the standard they would like given it was a
private email, perhaps because they thought it would remain so.  But
even so we are talking minor polishing here - a few hours of work at
most.  Thinking up a post hoc justification of the decision would take
longer, of course.  But if they need to do that, it's an indicator they
are not confident their reasoning is good enough to convince the
community at large.  That means they didn't do thorough job before they
made the decision, and they are re-visiting it.  If they are indeed
doing that one the options on the table should be their reasoning was
wrong, and consequently they need reverse it.

To repeat: needing time to think up a justification for your actions
when to do your job needs very careful justification before you act is
not a good look.

> - Did you consider communicating with DAM before writing here?

Do you see the first sentence?  It said: "It's been made plain to me
I've done a bad job of explaining myself on debian-private".  Obviously
I didn't just consider it: I did it.

> Please: don't push more on yet another mailing list until the above
> points are somewhat settled, i.e. DAM has had time to react and the
> other group has started circulating their draft, if they still plan
> to do so.

Sorry, no.  To me that sounds like a very poor way of going about
things.  If I was the DAM I'd prefer to get a lay of the land before I
acted a second time given the first attempt had such an unpleasant
outcome.  I'd want others to throw up ideas and see how the community
reacts to them, letting the rest of the project do the advocacy work
and take the associated heat.  Once the possibilities have been
explored then I'd make my second announcement, hopefully using what
I've learnt to avoid a repeat performance.

I'll continue behave as I would want others behave towards me.

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

#10153

On Saturday, January 05, 2019 02:34:14 PM Russell Stuart wrote:

I have comments only a a couple of the points you raised:

> On Fri, 2019-01-04 at 10:57 +0000, Ulrike Uhlig wrote:
> > You are misrepresenting this: it has been said outside of this list
> > that this does not represent an expulsion procedure but a procedure
> > that makes it possible for DDs to make DAM consider an removal of
> > privileges, because that's what it is.
> 
> OK, could somebody clear something up for me please?  Does Debian have
> a procedure / policy or something saying what triggers the DAM moving
> down the road towards a Developers expulsion (so it's clear when they
> must act), and what procedure they follow when expel someone.  I
> thought that was it.  Apparently not.

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

We don't get to look inside DAM and have opinions on how they execute their 
delegated authority.

> I'll put it bluntly: they should not need time.

I think you don't have much experience with these kinds of things if you 
believe that.

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.

That was for a non-controversial topic for which there was not much internal 
disagreement written during a period when it wasn't the topic of I don't know 
how many messages on Debian mailing lists.

Taking care to make sure an email speaks for the team as a whole and is 
correct is hard and takes time.

Scott K

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

#10154

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

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.

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.

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.

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.

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

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

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?

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.

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

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

#10155

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

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

#10167

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

On Sat, Jan 05, 2019 at 06:48:31PM +1000, Russell Stuart wrote:
> > 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.

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

"We" "insist"?

The constitution only defines that the TC has the power to make technical
decisions, and the voting process by which those decisions happen.  It does
not dictate that the TC provide any particular level of detail in their
justifications for these decisions, and to the extent that the TC does
provide detailed justification, it is because they agree that this is the
correct thing to do - *not* because anyone outside the TC "insists" on it.

Now, there are some common-sense reasons why the members of the TC *would*
want to do this.  It's self-defense of their own future time to write
decisions in a way that they are less likely to be questioned, and it makes
a better precedent when the justification is given, as it allows individual
developers to reason more clearly about how the decision does or doesn't
apply to future related questions.  And I think the DAM will ultimately opt
to provide insight into their recent decisions for similar reasons.  But
that's not because the project per se is formally requiring it.

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

Should we also require a detailed opinion from the DAM for each person who
is admitted to the project, or only for those that were once admitted but
who the DAM has subsequently decided to expel?

-- 
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/
slangasek@ubuntu.com                                     vorlon@debian.org

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

#10175

2019-01-06 01:03 Steve Langasek:
>On Sat, Jan 05, 2019 at 06:48:31PM +1000, Russell Stuart wrote:
>>
>> 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.
>
>Should we also require a detailed opinion from the DAM for each person who
>is admitted to the project, or only for those that were once admitted but
>who the DAM has subsequently decided to expel?

We have public records of new DMs and DDs with quite verbose
justifications:

- Application Manager recommendations

- plus the supporting messages by people working with prospective
  DMs/DDs,

- plus people sponsoring work before they join (for people working on
  packaging), or similarly reviewing their actions on VCS or working on
  teams (e.g. organising Debconf)

- plus keyring changes notices

- plus announcements every now and then in monthly news or similar about
  "Welcome new contributors / DMs / DDs"


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>

[toc] | [prev] | [standalone]

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

csiph-web