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

Re: [all candidates] Removing or limiting DD rights?

On Tuesday, March 25, 2013 16:22:23, Steve McIntyre wrote:
> Hi guys,
> First of all, thanks to all three of you standing in the DPL election
> this year. I know it's a daunting task! :-)
> I've already seen some debate about how we could/should attract more
> contributors, which is a perennial question in Debian. I personally
> don't think we're ever likely to "solve" that issue permanently, but
> it's clearly something that's always going to be very important for
> us. I have a related question, but more on the opposite end of the
> spectrum I suppose:
> Are we strict enough with our existing contributors? When we're trying
> to work together as best we can to make the Universal Operating System
> happen, what could/should we do with contributors who hinder our work?
> Sometimes that hindrance is inadvertent, sometimes it seems
> deliberate. At other times it looks like we have developers who are
> just not paying attention to what they're doing or who just don't care
> about the goals of the project. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most blatant
> of cases. By the time that happens, large amounts of damage may be
> done to the project: delayed releases, lost users, loss of motivation
> for other contributors.
> I'm wondering: is this something that you think is a real problem, and
> if so what do you think we could do about it?

From my contributor/non-DD point of view, the latter part of the above is 
something I'm repeatedly running into in Debian and is a problem.  There is 
also a distinct lack of information about how a bug reporter may try to handle 
the issue of when a maintainer is repeatedly communicating in an abusive 
manner; and what tools do exist are vague in helpfulness.

The video "How Open Source Projects Survive Poisonous People" below describes 
many of the common issues, and some solutions.


At 7:45 in the video:

   Community based on:

   "If a project is missing all of them, it doesn't last very long."

Right now Debian has no Code of Conduct concerning developer communications.  
There's been some discussion of a "5-year plan" for coming up with one to help 
this problem, but the same plan existed 5 years ago.  Some may point out that 
Ubuntu has a Code of Conduct, but Ubuntu wants packages to go through Debian.

Technically the DAM has the ability to act to remove a DD (per Debian 
Constitution 8.1 item 2), but the information I can gather so far seems to 
indicate that the DAM won't expell a DD for disciplanary problems.


Side note: the only DD I have heard of so far being expelled in 2006 for what 
seems to be vaguely disciplenary reasons -- Johnathan/Ted Walther -- has an 
interesting account as to the events that led up to him being expelled, which 
sounds like there was an array of wayward social disfunction all around.


As a result of there not being any significant way of handling mintainer 
misconduct, one of the common answers given to those that report misconduct is 
to /tolerate/ it.  But when this happens , the message that gets received is 
one of /dismissal/ -- and if that happens concerning bug reports, it means an 
increasing feeling that it's pointless to report bugs; i.e. "the chilling 
effect".  That might be one explanation for the steady drop in new bug 


And looking at the number of Debian Developers listed in the keyrings over 
time and comparing it with the number of binary packages listed in each 
release per Wikipedia, I see another interesting trend:

Year	DDs	DMs	Release	TotalDevs	# packages
1999	494		slink	494		2250
2000	638		potato	638		3900
2002	1164		woody	1164		8500
2005	1167		sarge	1167		15400
2007	1167		etch	1167		18200
2009	1060	75	lenny	1135		25000
2011	899	131	squeeze	1030		29000
2013	976	186	sid	1162		38000

The number of Debian Developers seems flat from 2002 to 2013, yet the number 
of packages from then to now has gone up by 375%.  One would thus expect the 
number of new bugs reported to go up, not steadily down.

As a bug reporter dealing with a misbehaving maintainer, this is what I would 

  1.  A clear place to report the misbehavior
  2.  A set of guidelines maintainers should follow
  3.  A public dialog about the misbehavior with some Debian authority
      along with the misbehaving maintainer.

Note on (3): In the cases I've dealt with, the misbehavior was in public bug 
reports, so the discussion of the misbehavior should likewise be public.

  -- Chris

Chris Knadle

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

Reply to: