Secrecy of member expulsions (Re: [all candidates] Removing or limiting DD rights?)

[Filipus Klutiero]

[Moving this to -project]

Stefano Zacchiroli wrote:

On Thu, Mar 28, 2013 at 05:37:18PM -0400, Chris Knadle wrote:
>  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.

FWIW, that is not correct. There have been other cases of member
expulsions for, as you put it, "disciplinary" reasons, but for various
good reasons not all of them are discussed publicly --- one thing is
expelling a developer, another is putting that up to ever lasting public
shaming on the web.


I don't disagree with you and the follow-up from Chris on this. However, 
I see a false dichotomy between keeping [some] expulsions secret and 
"publicly advertising" expulsions, or "public shaming". The missing 
option is very simple - for example, I don't advertise that I finished 
high school, but I won't hide that to anyone who asks me. We can 
publicly discuss expulsions without maintaining a members expulsion list.


Let's assume all expulsions were rightful to simplify this discussion. 
If a member is expelled and we publicly confirm that, there are 
definitely costs for that member. But there are also benefits; not only 
will any mistreated contributor have his faith in the project partially 
restored, but:


1. Other organizations (free software or not) will be warned to
   consider granting power to the problematic individual more carefully.
2. In the long term, if members realize that we stop covering up their
   errors, they should start behaving more cautiously.

Unless the project wants to consider only the interest of its members, 
I'm unconvinced that the cost outweighs the benefits.


The question here is far from Debian-specific. Ongoing technological 
advances have great impacts on reputation. Society as a whole has to evolve:


1. Individuals need to become more responsible.
2. At the same time, organizations need to appreciate the limits of
   reputation:
1. Everyone does errors sometimes.
2. The majority of us evolve - I am certainly not the same activist
   than I the one I was 10 years ago.


That being said, I think there's a potentially very problematic edge 
case: mental illness. Some of our members don't hide they are or have 
been mentally ill. Perhaps surprisingly, these aren't part of the 
contributors I consider most problematic. But I can remember very well 
one case of a contributor going from a respected member (who I assume  - 
without much actual knowledge - was once very productive) to... a pure 
jerk. I'm certainly not the only one remembering this case, and while I 
never personally knew the contributor and I am not God, the contributor 
becoming mentally ill seems like the most probable explanation.


I am far from knowledgeable on psychology and mental illness, but I hope 
this member has recovered today, and the impact of an organization 
finding out about his behavior may be much more severe for him than an 
organization finding out about a softer case of expulsion, say one 
mostly caused by immaturity. If that individual was to approach Debian 
admitting having suffered from mental illness and requesting evidence of 
his actions to be removed, I'd be sensible to his request. On the other 
hand, it may be that the best solution is for the expelled individual to 
disclose his health status as much as possible. I suppose people more 
knowledgeable in social sciences could have a more informed answer than 
mine.


Thanks to Steve for bringing up this topic and all candidates for their 
answers - and their candidacy!

Impact of ITS communication on issue reporting rate (Re: [all candidates] Removing or limiting DD rights?)

[Filipus Klutiero]

Hi Stefano,

Stefano Zacchiroli wrote:

On Fri, Mar 29, 2013 at 01:59:11PM -0400, Daniel Kahn Gillmor wrote:
>  Do we need to scientifically prove causation here?

Oh, you're totally right, we certainly do not need that to *work* on
improving bug report handling by maintainers.

It just takes that evidence to convince *me* that such aspect is a
relevant factor in the decrease of bug reporting rate :-). I digressed
on that point simply because Chris was wondering why *I* dismissed that
argument quickly.


I suppose Daniel's question was in context, i.e. the statement that poor 
ITS communications *might* explain a drop in the issue reporting rate. I 
fail to see any absurdity in Chris's statement, which I rather consider 
as self-evident. I find the implication that the decline would have a 
single cause infinitely more preposterous. In particular when that 
single cause would be the popularity of derivative distributions; 
although the issue reporting rate is certainly not directly proportional 
to Debian usage, they must be proportional, so increased usage of 
derivatives should result in increased (indirect) Debian usage and 
therefore an increase in our issue reporting rate, unless there are 
strong opposite effects.


Of course, if anyone is skeptical to the point of doubting that poor ITS 
communications causes a reduction in the issue reporting rate, before 
proving causation, it would be a good start to prove correlation, which 
hasn't even been done so far, as Chris has shown data on the issue 
reporting rate, but no quantification of ITS communications quality, 
which may well be increasing, indicating anticorrelation (although my 
personal feeling doesn't make it too hard for me to accept Chris's 
assumption).



--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51609e50.50...@gmail.com

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

[Chris Knadle]

On Wednesday, April 03, 2013 09:40:50, Ian Jackson wrote:
> Chris Knadle writes ("Re: [all candidates] Removing or limiting DD 
rights?"):
> > On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
> > > The purpose of a bug report is not to help solve the submitter's
> > > problem.
> > 
> > ... No, I don't agree with this.  I understand that this reteoric
> > helps "explain away" the problem, but it "throws out the baby with
> > the bath water".  If this is in fact the case, why would I bother
> > writing a bug report in the first place?
> 
> Well, speaking personally, I write bug reports because:
> 
> 1. I regard bug reports as contributions to helping improve the
> software;
> 
> 2. Debian being improved, even if only eventually and even if only
>perhaps, is directly in my interests as a user;
> 
> 3. It is often the case that the work necessary to identify and fix
>the bug provides, as a side effect, a faster fix for my own
>problem - and if I'm lucky someone other than me may have the
>skills and ability to to this much more easily and quickly than
>I could do so myself (and as a consequence perhaps I get the fix
>much sooner or with much less effort than if I work by myself;
> 
> 4. When I'm one of the people responsible for the package, reporting
>the bug keeps it on my todo list.
> 
> My point 3 above shows that the _submitter's_ motivation for reporting
> a bug may be different from the project's purpose in providing a bug
> reporting facility.  But as the project we must not subsume our
> primary goal - improving the software for all users - in favour of
> serving the specific user's goal.

I agree with this.  I couldn't understand the your original statement, because 
it sounded completely dismissive of the submitter's problem -- whereas what 
you really meant was that the submitter's problem wasn't the /main focus/ for 
a particular package.  ;-)  Okay... just miscommunication.

> Of course we do need bug reports to be able to tell what's wrong so
> that we know what to fix.  But many packages have so many bug reports
> that there is already not enough time to deal with them all
> thoroughly.  In that case it is better to cherry-pick the ones which
> seem to be likely to lead to bugfixes, and close the rest.

This may be fact, but I will not accept this anyway, because closing bugs with 
zero explanation of any kind is of /negative/ help.  Even a statement such as 
"please look into this yourself, I'm overloaded" would be something.  But now 
we've excused everything, /and/ we're saying that it's abusive for the 
submitter to reopen the bug.  That seems twisted.

I like Russ's suggestion of emailing -devel for an explanation, so that some 
maintainer that isn't overloaded might be able to explain what's going on.  
That's an answer that seems to fit both of our perspectives.

> > Seriously, what I'm trying to do is lower the number of cases which
> > cause frustration and which don't get any traction.  Between the "
> > *close* " problem, the maintainers that are MIA without the package
> > being orphaned, maintainers dropping working on a particular
> > package, and maintainers leaving certain bugs open forever with no
> > response, a fair number of the bugs I've dealt with go nowhere.
> > When I go to open a bug, I know there's a fair change that I'm just
> > wasting my time.  :-/
> 
> I take a rather longer view.  My experience is that many bugs I report
> stay open for many years, but most of them do eventually get fixed.

Wow... that's interesting.  Ouch/good/weird.

> But then there are also many bugs I don't bother reporting, precisely
> because when I imagine what the maintainer will feel about my report I
> decide I would be hindering rather than helping.

With the perspective I'm now gaining on the packaging side, I'm starting to 
understand what you mean by this.

> > That's debatable.  It's certainly dismissive, and dismissiveness is
> > one method that's used for abuse.  All that has to happen to make
> > this *close* thing clearly abuse is for ping-ponging of open-close
> > of the bug,
> 
> If the maintainer closes a bug, and the submitter reopens it, and the
> maintainer closes it, then IMO the submitter has probably committed
> abuse, whereas the maintainer has committed no abuse and is merely
> asserting their authority.
> 
> If the submitter keeps reopening the bug, the maintainer is entitled
> to close it again as many times as they like until either the
> submitter gets bored 

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

[Nikolaus Rath]

Ian Jackson  writes:
>> From the point of view of the bug reporter, the message the DD has
>> sent (whether intended or not) is "I'm not even going to dignify
>> this with a response.  *click* " It's not /only/ this rudeness
>> that's the problem, though; the bug reporter has now been handed a
>> puzzle of "convice the expert", where the expert needed to be
>> convicned seemingly isn't willing to spend any effort in
>> communicating, but the bug reporter does.  This kind of thing
>> therefore promotes either conflict or the bug reporter walking away
>> in disgust, /either/ result of which is detrimental.
>
> The purpose of a bug report is not to help solve the submitter's
> problem.

Especially under this premise the maintainer owes the submitter at least
a thank you. As you put it, the submitter just spend a lot of effort in
an attempt to help the maintainer.

(I know you wrote something along these lines further down, but I wanted
to emphasize this point).


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvz81bz0@vostro.rath.org

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

[Ian Jackson]

Chris Knadle writes ("Re: [all candidates] Removing or limiting DD rights?"):
> On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
> > The purpose of a bug report is not to help solve the submitter's
> > problem.
> 
> ... No, I don't agree with this.  I understand that this reteoric
> helps "explain away" the problem, but it "throws out the baby with
> the bath water".  If this is in fact the case, why would I bother
> writing a bug report in the first place?

Well, speaking personally, I write bug reports because:

1. I regard bug reports as contributions to helping improve the
software;

2. Debian being improved, even if only eventually and even if only
   perhaps, is directly in my interests as a user;

3. It is often the case that the work necessary to identify and fix
   the bug provides, as a side effect, a faster fix for my own
   problem - and if I'm lucky someone other than me may have the
   skills and ability to to this much more easily and quickly than
   I could do so myself (and as a consequence perhaps I get the fix
   much sooner or with much less effort than if I work by myself;

4. When I'm one of the people responsible for the package, reporting
   the bug keeps it on my todo list.

My point 3 above shows that the _submitter's_ motivation for reporting
a bug may be different from the project's purpose in providing a bug
reporting facility.  But as the project we must not subsume our
primary goal - improving the software for all users - in favour of
serving the specific user's goal.

It is not a service to our users as a whole to get distracted from
improving the software into the task of helping a particular user.
Improving the software will help the thousands or millions of people
who use it - and although we can't see those thousands or millions
directly, they are much more important than the one user in front of
us.

Of course we do need bug reports to be able to tell what's wrong so
that we know what to fix.  But many packages have so many bug reports
that there is already not enough time to deal with them all
thoroughly.  In that case it is better to cherry-pick the ones which
seem to be likely to lead to bugfixes, and close the rest.

> Seriously, what I'm trying to do is lower the number of cases which
> cause frustration and which don't get any traction.  Between the "
> *close* " problem, the maintainers that are MIA without the package
> being orphaned, maintainers dropping working on a particular
> package, and maintainers leaving certain bugs open forever with no
> response, a fair number of the bugs I've dealt with go nowhere.
> When I go to open a bug, I know there's a fair change that I'm just
> wasting my time.  :-/

I take a rather longer view.  My experience is that many bugs I report
stay open for many years, but most of them do eventually get fixed.

But then there are also many bugs I don't bother reporting, precisely
because when I imagine what the maintainer will feel about my report I
decide I would be hindering rather than helping.

> That's debatable.  It's certainly dismissive, and dismissiveness is
> one method that's used for abuse.  All that has to happen to make
> this *close* thing clearly abuse is for ping-ponging of open-close
> of the bug,

If the maintainer closes a bug, and the submitter reopens it, and the
maintainer closes it, then IMO the submitter has probably committed
abuse, whereas the maintainer has committed no abuse and is merely
asserting their authority.

If the submitter keeps reopening the bug, the maintainer is entitled
to close it again as many times as they like until either the
submitter gets bored and goes away.  The maintainer is also entitled
to complain to owner@bugs.

> or statements like "Are we having fun yet? *close* "
> from the maintainer.  The first close without explanation is almost
> invariably at the start of all that.

I think that "Are we having fun yet? *close*" is a suboptimal response
to abusive reopening by a submitter.  But it falls short of being
itself abusive.

> > Of course if a maintainer inappropriately adopts such an aggressive
> > approach to bug triage when it isn't necessary, you can appeal to the
> > Technical Committee.  I doubt the TC would want to set out a decision
> > overruling a maintainer's workflow (and in any case it's hard to see
> > how such an overruling resolution could be made practical).
> > 
> > So if you want to do this, you will need to assemble a team to take
> > over the package and ask the TC to depose the maintainer(s).  But
> > wouldn't it be better to volunteer to join the team for the package,
> > and help out the maintainer cooperatively ?
> 
> Starting off w

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

[Adam D. Barratt]

On 03.04.2013 06:09, Chris Knadle wrote:

On Tuesday, April 02, 2013 20:34:28, Russ Allbery wrote:
Note that we already did do something about it by deprecating close 
in the
BTS in favor of sending a real email message to -done that is copied 
to
the submitter.  The Debian BTS now nags the maintainer about telling 
the

submitter something if they use the close command.


That's interesting.  That sounds like an improvement in this area.  
If you
happen to know when that was implemented, I'd be interested.  June of 
last
year I saw a bug closed (marked as done, without explanation) where I 
didn't
see any email sent to the BTS control@ address in the bug, so I was 
confused

as to how the bug was closed.  Would emailing -done do that?


Closing the bug is exactly what -done is for. Using control@ to close 
bugs should be the exception, not the rule.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/93853dd7c74239d3941ce5762...@mail.adsl.funky-badger.org

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

[Tollef Fog Heen]

]] Russ Allbery 

(Cc to owner@bugs, M-F-T to -project.)

> Note that we already did do something about it by deprecating close in the
> BTS in favor of sending a real email message to -done that is copied to
> the submitter.  The Debian BTS now nags the maintainer about telling the
> submitter something if they use the close command.

We did this ages ago.  Perhaps it's time to retire the close command
entirely?

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj38p1tc@qurzaw.varnish-software.com

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

[Chris Knadle]

On Tuesday, April 02, 2013 20:34:28, Russ Allbery wrote:
> Chris Knadle  writes:
> > Seriously, what I'm trying to do is lower the number of cases which
> > cause frustration and which don't get any traction.  Between the "
> > *close* " problem, the maintainers that are MIA without the package
> > being orphaned, maintainers dropping working on a particular package,
> > and maintainers leaving certain bugs open forever with no response, a
> > fair number of the bugs I've dealt with go nowhere.  When I go to open a
> > bug, I know there's a fair change that I'm just wasting my time.  :-/
> 
> While I'm all in favor of doing better when we can, have you interacted
> with any large bug tracking system for which this isn't the case?

Good question.

I can say this: Debian's BTS is the only bug tracker in which I've ever gotten 
a bug quickly closed without any explanation.  Bugs in Debian's BTS also tend 
to be "a bit more argumentative" than other bug trackers, IMHO.  [This is not 
necessarily negative.]

However these exceptions aside, bugs in the Debian BTS that I deal with get 
solved far more often than external bug trackers I've dealt with, and a lot of 
the maintainers seem like really good people who are simultaneously quite 
knowledgable.  So if there's discussion open at all, it usually works out one 
way or another.  Thus "the catch" seems to be getting that far in the first 
place for the minority of bugs where that's an issue.  [And I won't get into 
the exceptions to the exceptions.]

[...]
> > But it's one thing if the maintainer is MIA, it's antother thing
> > entirely if the maintainer simply completely dismisses my bug with
> > *close* .  I'm not saying that figuring out an answer to this is easy
> > (or that it should be)...  but I am trying to figure out what can be
> > done about it.
> 
> Note that we already did do something about it by deprecating close in the
> BTS in favor of sending a real email message to -done that is copied to
> the submitter.  The Debian BTS now nags the maintainer about telling the
> submitter something if they use the close command.

That's interesting.  That sounds like an improvement in this area.  If you 
happen to know when that was implemented, I'd be interested.  June of last 
year I saw a bug closed (marked as done, without explanation) where I didn't 
see any email sent to the BTS control@ address in the bug, so I was confused 
as to how the bug was closed.  Would emailing -done do that?

> > That's debatable.  It's certainly dismissive, and dismissiveness is one
> > method that's used for abuse.  All that has to happen to make this
> > *close* thing clearly abuse is for ping-ponging of open-close of the
> > bug, or statements like "Are we having fun yet? *close* " from the
> > maintainer.  The first close without explanation is almost invariably at
> > the start of all that.
> 
> Submitters should really never reopen bugs unless something substantive
> has changed about the bug since the maintainer closed it or unless the
> submitter thinks they have information about the bug that the maintainer
> doesn't have.  (If the bug was closed in a new version of the package but
> the new version of the package still has that bug, for example.)  Just
> immediately reopening it is almost always the wrong approach unless the
> submitter is someone like the release team or the like who has some social
> expectation of being able to override the maintainer.
> 
> It accomplishes nothing to reopen a bug when a maintainer thinks it should
> be closed; they're obviously going to just close it again, and they're
> usually going to consider that to be confrontational and a violation of
> boundaries since they're the ones responsible for the bug state for their
> packages.
> 
> The right next step is to send a reply to the bug (the maintainer still
> gets it whether the bug is open or not) explaining why you disagree with
> it being closed, and if that gets no response, to appeal somewhere:
> debian-devel, the Technical Committee, a co-maintainer, whatever seems
> appropriate.
> 
> Yes, that means users whose bugs are closed by the maintainer and who
> can't persuade the maintainer to keep it open aren't going to be able to
> get the bug reopened because they don't know enough about the project
> structure to know who to ask, but I think that's reasonable, or at least
> better than the alternatives.

I get the feeling that most bug reporters aren't "armed" with this knowledge.  
/Assuming they were,/ the above seems reasonable.  I think I like this enough 
that I'd want to include this on one of the BTS front web pages, if possible. 
"To be forewarned is to be forearmed."

Hmm... how to title this in a nutral way...

> > Starting off with a maintainer that closes my bug report with no
> > explanation at all?  How do I join the team, when the team refuses to
> > communicate?  Why would I make another bigger offer my time, when the
> > team doesn't offer theirs even when /I

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

[Russ Allbery]

Chris Knadle  writes:

> Seriously, what I'm trying to do is lower the number of cases which
> cause frustration and which don't get any traction.  Between the "
> *close* " problem, the maintainers that are MIA without the package
> being orphaned, maintainers dropping working on a particular package,
> and maintainers leaving certain bugs open forever with no response, a
> fair number of the bugs I've dealt with go nowhere.  When I go to open a
> bug, I know there's a fair change that I'm just wasting my time.  :-/

While I'm all in favor of doing better when we can, have you interacted
with any large bug tracking system for which this isn't the case?

We should absolutely challenge ourselves to be the best that we can be,
and better than everyone else in the free software world when we can.  But
I think we should also be realistic: things that no other large project is
doing successfully are probably Hard.

I would love for it to be realistic to tell our users that every bug
report will get an informed response, but I don't think it is, and I don't
think we should set the expectation that it's reasonable to expect this.

> But it's one thing if the maintainer is MIA, it's antother thing
> entirely if the maintainer simply completely dismisses my bug with
> *close* .  I'm not saying that figuring out an answer to this is easy
> (or that it should be)...  but I am trying to figure out what can be
> done about it.

Note that we already did do something about it by deprecating close in the
BTS in favor of sending a real email message to -done that is copied to
the submitter.  The Debian BTS now nags the maintainer about telling the
submitter something if they use the close command.

> That's debatable.  It's certainly dismissive, and dismissiveness is one
> method that's used for abuse.  All that has to happen to make this
> *close* thing clearly abuse is for ping-ponging of open-close of the
> bug, or statements like "Are we having fun yet? *close* " from the
> maintainer.  The first close without explanation is almost invariably at
> the start of all that.

Submitters should really never reopen bugs unless something substantive
has changed about the bug since the maintainer closed it or unless the
submitter thinks they have information about the bug that the maintainer
doesn't have.  (If the bug was closed in a new version of the package but
the new version of the package still has that bug, for example.)  Just
immediately reopening it is almost always the wrong approach unless the
submitter is someone like the release team or the like who has some social
expectation of being able to override the maintainer.

It accomplishes nothing to reopen a bug when a maintainer thinks it should
be closed; they're obviously going to just close it again, and they're
usually going to consider that to be confrontational and a violation of
boundaries since they're the ones responsible for the bug state for their
packages.

The right next step is to send a reply to the bug (the maintainer still
gets it whether the bug is open or not) explaining why you disagree with
it being closed, and if that gets no response, to appeal somewhere:
debian-devel, the Technical Committee, a co-maintainer, whatever seems
appropriate.

Yes, that means users whose bugs are closed by the maintainer and who
can't persuade the maintainer to keep it open aren't going to be able to
get the bug reopened because they don't know enough about the project
structure to know who to ask, but I think that's reasonable, or at least
better than the alternatives.

> Starting off with a maintainer that closes my bug report with no
> explanation at all?  How do I join the team, when the team refuses to
> communicate?  Why would I make another bigger offer my time, when the
> team doesn't offer theirs even when /I/ have?

One possible option to consider when this happens is to write mail to
debian-devel (or debian-user, not sure which would be best) along the
lines of:

Hey, could folks have a look at bug #NN?  I think this is a valid
bug, but the maintainer obviously disagrees.  However, they've not
written me or the bug to explain why, and I don't understand the
disagreement.  What am I missing?

I think that would be well-received by just about everyone.

This is just standard interpersonal tactics, but basically the goal is to
de-escalate any confrontation and try to avoid telling other people
they're wrong, and instead ask for the explanation that you're missing.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvz8jvu3@windlord.stanford.edu

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

[Chris Knadle]

I'm on the -project list, so no need to CC me directly.  (Fine if you do, 
though.)

On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
> Chris Knadle writes ("Re: [all candidates] Removing or limiting DD 
rights?"):
> > The #1 kind of bug reports that become problems are ones that go like 
this:
> >   - bug reporter: writes polite and detailed bug report
> >   - maintainer  : *cloeses bug* without discussion
> >   
> >   (usually within the first hour of the bug's existence)
> 
> I agree that this is annoying for the submitter.  I also agree that
> this is not the best situation for us to be in.
> 
> But I think that the maintainer is entitled to do this. 

Perhaps, but we agree that there's a issue with this for the bug reporter.  
Communication problem.

> The maintainer is in charge of setting the package's bug management
> practices.  In some packages it is not possible to deal "properly"
> with every bug report, and it is the maintainer who has to decide how
> the incoming bug stream can best be used to improve the software.

I agree.

> To reiterate: the purpose of bug reports is to help improve the
> software. In Debian, the maintainer(s) are in charge of deciding (in
> the first instance) what counts as an improvement, and which
> improvements are most important.  But they are also in charge of
> deciding how this purpose of bug reports can best be fulfilled.
> 
> I do think that if the maintainers think it necessary to summarily
> close bugs in this way it would be better if they produced a standard
> text of some kind explaining this.
> 
> If the closure happens by merging with a closed report, I would hope
> that the other bug would help explain the situation.

Yes and no.  For situations where the bug cause is a duplicate (which is where 
this happens most often), merging the bug with the others that are still open 
and handling them all together seems fine, and seems to have a built-in 
"explanation" of sorts.

But sometimes I see bugs with explanations as to why they're different which 
get merged by the maintainer anyway, and done without explanation within an 
hour of the bug being entered.  In this case what the maintainer is saying is 
"looks like the same thing...  *click* " but doesn't respond in any way as to 
why the maintainer thinks the /cause/ is the same.  I've recently had this 
happen, emailed the maintainer a question of why the bug was merged and 
closed, and got no response.  It's hard to see how this is acceptable.

Similarly sometimes I see bugs being transferred to other packages, just to 
have them transferred back, and transferred away to another package again.  
i.e. repeated "deflection".  [Thankfully it's been a while since I've seen 
this now.]

> > From the point of view of the bug reporter, the message the DD has
> > sent (whether intended or not) is "I'm not even going to dignify
> > this with a response.  *click* " It's not /only/ this rudeness
> > that's the problem, though; the bug reporter has now been handed a
> > puzzle of "convice the expert", where the expert needed to be
> > convicned seemingly isn't willing to spend any effort in
> > communicating, but the bug reporter does.  This kind of thing
> > therefore promotes either conflict or the bug reporter walking away
> > in disgust, /either/ result of which is detrimental.
> 
> The purpose of a bug report is not to help solve the submitter's
> problem.

... No, I don't agree with this.  I understand that this reteoric helps 
"explain away" the problem, but it "throws out the baby with the bath water".  
If this is in fact the case, why would I bother writing a bug report in the 
first place?  Furthermore, what would be the purpose of the Debian Technical 
Commiteee?

Obviously, there are /many/ bugs that need to be fixed, and those bugs get 
opened by users (of various kinds).  Admittedly, there are others that don't.  
The maintainer makes most, /but not all,/ of this judgment call.  [You state 
this similarly in the last line of your email concerning the TC.]

> If the maintainers are already overloaded, then the bug
> reporter walking away may be the best available outcome.  It at least
> limits the amount of further effort put into investigating a problem
> when the maintainers feel that such effort would be wasted.
>
> The remaining problem is of course the bug reporter being annoyed.
> Obviously some annoyance is probably inevitable in this situation, but
> it could perhaps be minimised at very low cost if the maintainer
> closes the bug with a standard text explaining (and perhaps
> apologising).

That's a /lot/ be

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

[Wouter Verhelst]

On 02-04-13 19:53, Ian Jackson wrote:
> Chris Knadle writes ("Re: [all candidates] Removing or limiting DD rights?"):
>> The #1 kind of bug reports that become problems are ones that go like this:
>>
>>   - bug reporter: writes polite and detailed bug report
>>   - maintainer  : *cloeses bug* without discussion
>>   (usually within the first hour of the bug's existence)
> I agree that this is annoying for the submitter.  I also agree that
> this is not the best situation for us to be in.
>
> But I think that the maintainer is entitled to do this.

I disagree.

The maintainer is entitled to close the bug, yes. But not without
explanation. A minimum of courtesy requires that you explain why a bug
is invalid, or wrong, or whatever, before you close it.

Anything else is rude to the bug submitter.

[...]
> If the closure happens by merging with a closed report, I would hope
> that the other bug would help explain the situation.
True, but then the bug isn't closed without explanation.

-- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/515b356f.3090...@debian.org

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

[Ian Jackson]

Ian Jackson writes ("Re: [all candidates] Removing or limiting DD rights?"):
...
> If in this situation there is a possibility of the submitter's
> experience being turned into an improvement in the software, it could
> arise if the submitter 

... can investigate further themselves (perhaps with the help of other
people experiencing the bug, other programmers they know, or
whatever).

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20827.7028.157908.161...@chiark.greenend.org.uk

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

[Ian Jackson]

Chris Knadle writes ("Re: [all candidates] Removing or limiting DD rights?"):
> The #1 kind of bug reports that become problems are ones that go like this:
> 
>   - bug reporter: writes polite and detailed bug report
>   - maintainer  : *cloeses bug* without discussion
>   (usually within the first hour of the bug's existence)

I agree that this is annoying for the submitter.  I also agree that
this is not the best situation for us to be in.

But I think that the maintainer is entitled to do this.  The
maintainer is in charge of setting the package's bug management
practices.  In some packages it is not possible to deal "properly"
with every bug report, and it is the maintainer who has to decide how
the incoming bug stream can best be used to improve the software.

To reiterate: the purpose of bug reports is to help improve the
software.  In Debian, the maintainer(s) are in charge of deciding (in
the first instance) what counts as an improvement, and which
improvements are most important.  But they are also in charge of
deciding how this purpose of bug reports can best be fulfilled.

I do think that if the maintainers think it necessary to summarily
close bugs in this way it would be better if they produced a standard
text of some kind explaining this.

If the closure happens by merging with a closed report, I would hope
that the other bug would help explain the situation.

> From the point of view of the bug reporter, the message the DD has
> sent (whether intended or not) is "I'm not even going to dignify
> this with a response.  *click* " It's not /only/ this rudeness
> that's the problem, though; the bug reporter has now been handed a
> puzzle of "convice the expert", where the expert needed to be
> convicned seemingly isn't willing to spend any effort in
> communicating, but the bug reporter does.  This kind of thing
> therefore promotes either conflict or the bug reporter walking away
> in disgust, /either/ result of which is detrimental.

The purpose of a bug report is not to help solve the submitter's
problem.  If the maintainers are already overloaded, then the bug
reporter walking away may be the best available outcome.  It at least
limits the amount of further effort put into investigating a problem
when the maintainers feel that such effort would be wasted.

The remaining problem is of course the bug reporter being annoyed.
Obviously some annoyance is probably inevitable in this situation, but
it could perhaps be minimised at very low cost if the maintainer
closes the bug with a standard text explaining (and perhaps
apologising).

If in this situation there is a possibility of the submitter's
experience being turned into an improvement in the software, it could
arise if the submitter 

> If we could come up with a reasonable way of handling this
> particular problem, it would be greatly appreciated.

I guess you're volunteering to work to bring in the dozens or hundreds
of people into a "help desk team", that would be necessary to fully
and politely triage and investigate every bug report ?  Please do go
ahead.  I look forward to seeing the results!

>  Do you think emailing owner@bugs.d.o is a good way of dealing with
> this?

No.  I agree that owner@bugs should deal with abuse, but what you are
complaining about isn't abuse.

> In contrast, a first response from a maintainer with an email of "I
> don't see this as a problem", but the bug report still being open,
> is about 100% better.

Not from the point of view of the maintainers.  And the bug list is
primarily a resource for the maintainer.

And not from the point of view of many of the other people involved in
building Debian.  Most of them will want the maintainer's view of the
bug status of a package.


Of course if a maintainer inappropriately adopts such an aggressive
approach to bug triage when it isn't necessary, you can appeal to the
Technical Committee.  I doubt the TC would want to set out a decision
overruling a maintainer's workflow (and in any case it's hard to see
how such an overruling resolution could be made practical).

So if you want to do this, you will need to assemble a team to take
over the package and ask the TC to depose the maintainer(s).  But
wouldn't it be better to volunteer to join the team for the package,
and help out the maintainer cooperatively ?


And finally of course if you feel an individual bug is important
enough, and the maintainer's decision clearly wrong, you can refer the
individual bug to the TC.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20827.6932.150221.360...@chiark.greenend.org.uk

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

[Chris Knadle]

On Thursday, March 28, 2013 18:35:40, Don Armstrong wrote:
> On Thu, 28 Mar 2013, Chris Knadle wrote:
> > As a bug reporter dealing with a misbehaving maintainer, this is
> > 
> > what I would want:
> >   1.  A clear place to report the misbehavior
> 
> ow...@bugs.debian.org is an appropriate place to report abusive
> behavior by anyone (maintainers, users, etc) on the BTS. Likewise,
> listmas...@lists.debian.org is an appropriate place to report abusive
> behavior by anyone in messages to lists.

I've never heard of (nor considered) the idea of emailing the owner@bugs.d.o 
address concerning "written mistreatment" behavior I see in bugs on the BTS.  
What I like most about this idea follows the thought of "deal with the problem 
while it's small, before it gets big."  [More debail on this below.]

> This probably should be better documented somewhere on the website,
> but as I've never had to look for it, I don't know where that would
> be. Someone who has searched for it and failed may have some better
> suggestions.

The owner@bugs.d.o address is listed on certain pages linked to from 
www.debian.org/bugs, but there isn't any hint that it would be appropriate to 
email the "Debian BTS administrators" for the case that there is "written 
mistreatment" occurring.

Concerning where to document this, my personal choice (and this is just MHO) 
would be in a seperate paragraph near the bottom of

  http://www.debian.org/Bugs/Developer

and which would have a link to the paragraph at the top of the page like other 
paragraphs have.  [Emailing owner@bugs.d.o isn't an "advanced" topic per se, 
but I looked at the other pages linked to from the main /Bugs page and the 
other pages didn't seem as appropriate to put this suggested paragraph into.]


Now... Moray brought up a main issue but I want to clarify it:

---
On Friday, March 29, 2013 20:26:17, Moray Allan wrote:
> On 2013-03-28 16:35, Don Armstrong wrote:
> > ow...@bugs.debian.org is an appropriate place to report abusive
> > behavior by anyone (maintainers, users, etc) on the BTS.
> 
> But how broad a definition of abusive behaviour are you taking here?
> 
> I would have thought of contacting ow...@bugs.debian.org in respect of,
> say, two people battling about a bug's status in control messages, but I
> wouldn't have assumed that you would want to deal with, e.g.,
> unnecessarily dismissive responses to user feature requests, or
> maintainers who sound ruder than they intend to users who report a bug
> due to not having read the documentation.
---

The #1 kind of bug reports that become problems are ones that go like this:

  - bug reporter: writes polite and detailed bug report
  - maintainer  : *cloeses bug* without discussion
  (usually within the first hour of the bug's existence)

... where "closes bug" may be a simple closing that can be re-opened, or a 
more complicated closing such as merging the bug with others that are closed.

From the point of view of the bug reporter, the message the DD has sent 
(whether intended or not) is "I'm not even going to dignify this with a 
response.  *click* "  It's not /only/ this rudeness that's the problem, 
though; the bug reporter has now been handed a puzzle of "convice the expert", 
where the expert needed to be convicned seemingly isn't willing to spend any 
effort in communicating, but the bug reporter does.  This kind of thing 
therefore promotes either conflict or the bug reporter walking away in 
disgust, /either/ result of which is detrimental.  I thus personally consider 
this to be the first step into "the path of the Dark Side".

If we could come up with a reasonable way of handling this particular problem, 
it would be greatly appreciated.  Do you think emailing owner@bugs.d.o is a 
good way of dealing with this?




In contrast, a first response from a maintainer with an email of "I don't see 
this as a problem", but the bug report still being open, is about 100% better.  
It's still be overly dismissive and can possibly go the wrong way, but there's 
still an opportunity for communication and the maintainer has given at least 
/some/ response.  Usually another polite response back can open a dialog.  
(Not always, but usually.)

> >   2.  A set of guidelines maintainers should follow
> 
> I certainly wouldn't have a problem with adopting a set of guidelines
> for interactions on the BTS, but I'd prefer to have these guidelines
> discussed on -project first. [We already do have guidelines for the
> mailing list, too.]

Sounds good to me.

> >   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.
> 
> Discussion of misbehavior is usually not public. If someone reports
> bad behavior, owner@ or listma

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

[Gergely Nagy]

gregor herrmann  writes:

> On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote:
>
>> On 25/03/13 at 16:22 +, Steve McIntyre wrote:
>> > 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.
>
> Thanks for this question, which I would like to extend a bit.
> Im my understanding you are pointing to unconstructive behaviour
> related to technical work. What we also see (and discuss) every now
> and then is behaviour that is socially questionable or clearly
> unacceptable (from disrespect for peers to blatant abusive language).
>
> I guess we all remember such examples, which have led to
> demotivation, frustration, hurt feelings, and have driven
> contributors away.

Indeed, I do remember. But - like Moray - as far as I see, this happens
fewer times than it did in the past, at least on the most public lists
(it does happen nevertheless, especially in those long threads we all
know and "love"...). This being less of an issue than it was a decade
ago, is good. There's certainly room for improvement, nevertheless.

>> One small thing that we could improve on is earlier official
>> communication. For example, in case of seriously problematic behaviour
>> that could eventually lead to censure or expulsion, official warnings
>> could be issued to the DD, and Cced to -private@. In some cases, that
>> could help the DD realize that s/he needs a behaviour change, and also
>> limit the surprise effect if/when a final decision is taken.
>
> What other ideas do you (plural, for all candidates, in case you see
> the necessity to improve the handling of "social problems") see as
> viable?

I'll answer your specific answers first:

> Examples that have come up in the past and might or might not be
> helpful:
> - Encourage everyone to chime in when they see potentially
>   unacceptable behaviour? In public/private?

The problem with this is that multiple people independently chiming in
has the tendency to make things worse. A more coordinated effort would
help that, and if we had single coordinating contact point to help,
that'd be great. (These do exist, owner@bugs.d.o and listmaster@, as Don
mentioned earlier, but I am as of yet, unsure whether they're used this
way, and how often.)

I would encourage chiming in privately, and in a coordinated manner,
with a single statement publicly, to discourage others from public
flaming (and instead, point them towards the coordinated effort).

> - Should we try to establish a Code of Conduct for project members?
>   Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
>   examples.
>   If yes, how would we do this, and how could we make sure it gets
>   respected?
> - Could the CoC for mailing lists
>   (http://www.debian.org/MailingLists/#codeofconduct)
>   be used as a starting point / be extended?
> - Or Enrico's Debian Community Guidelines?
>   http://people.debian.org/~enrico/dcg/index.html

I'm not a terribly big fan of Codes of Conduct, because they're vague
and very, very general, and as such, subject to interpretation. What I
would consider a flame, or common sense may be much different than
someone else thinks. I've grown up on IRC, and frequented channels where
foul language and flames were a daily show (and I'm not ashamed to
admit, that I enjoyed these, one could learn a lot about how not to
behave, and what triggers a flame. I found it very educational at the
time.)

Enforcing the CoC is also quite a big task. However, there's one good
thing about them: they send a message, that we're serious about
caring about and nurturing our community. For that reason alone, a CoC
is worth it.

I do like Enrico's guidelines though. Something along those lines, and
the mailing list CoC would make sense, in my opinion. Perhaps both! A
CoC, a short, generic code, and the Guidelines, for more in-depth
suggestions. The Guidelines would be treated only as such, though -
guidelines, not enforcable, but a reasonable basis of peace talks.

> - Another recurring topic is the Social Committee, cf. e.g.
>   https://lwn.net/Articles/221077/ (or the ombudsman team mentioned
>   in the article:
>   https://lists.debian.org/debian-project/2007/01/msg00101.html )
>   Would such a body make sense? With which powers?

I would find such a body useful, but not in the way it is explained in
Gustavo's mail (there's quite a few things I disagree with, like a
public pseudo package in the BTS for the task).

As for powers - I would not wish to grant the body any particular power,
but rather, ask them to channel issues to the DPL, and they together
would decide how to proceed, wit

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

[Chris Knadle]

Don -- my apologies for not responding to this earlier; somehow I missed this 
message, and figured out I had missed it via reading Moray's resonse to it.

On Thursday, March 28, 2013 18:35:40, Don Armstrong wrote:
> This message appears to be more appropriate for -project,
> non-candidate responses, please follow up there.

Okay, I've just signed up for [debian-project].  I'm in a bit of a rush at the 
moment, but will respond tomorrow.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303292132.59426.chris.kna...@coredump.us

Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)

[Moray Allan]

On 2013-03-28 16:35, Don Armstrong wrote:

ow...@bugs.debian.org is an appropriate place to report abusive
behavior by anyone (maintainers, users, etc) on the BTS.


But how broad a definition of abusive behaviour are you taking here?

I would have thought of contacting ow...@bugs.debian.org in respect of, 
say, two people battling about a bug's status in control messages, but I 
wouldn't have assumed that you would want to deal with, e.g., 
unnecessarily dismissive responses to user feature requests, or 
maintainers who sound ruder than they intend to users who report a bug 
due to not having read the documentation.



This probably should be better documented somewhere on the website,
but as I've never had to look for it, I don't know where that would
be. Someone who has searched for it and failed may have some better
suggestions.


If new bug reporters have followed our instructions and used a tool to 
report the bug, they won't necessarily look at the website at all.   If 
we want to be sure of reaching them with this kind of advice, it 
probably has to come by email as well (at least as a clearly labelled 
URL).


--
Moray


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/59841be56f0e5b237e68d6b960d49...@www.morayallan.com

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

[Don Armstrong]

This message appears to be more appropriate for -project,
non-candidate responses, please follow up there.

On Thu, 28 Mar 2013, Chris Knadle wrote:
> As a bug reporter dealing with a misbehaving maintainer, this is
> what I would want:
> 
>   1.  A clear place to report the misbehavior

ow...@bugs.debian.org is an appropriate place to report abusive
behavior by anyone (maintainers, users, etc) on the BTS. Likewise,
listmas...@lists.debian.org is an appropriate place to report abusive
behavior by anyone in messages to lists.

This probably should be better documented somewhere on the website,
but as I've never had to look for it, I don't know where that would
be. Someone who has searched for it and failed may have some better
suggestions.

>   2.  A set of guidelines maintainers should follow

I certainly wouldn't have a problem with adopting a set of guidelines
for interactions on the BTS, but I'd prefer to have these guidelines
discussed on -project first. [We already do have guidelines for the
mailing list, too.]

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

Discussion of misbehavior is usually not public. If someone reports
bad behavior, owner@ or listmaster@ typically talks to the individual
concerned, and warns them about it specifically, and informs the
reporter that their concern has been addressed. In the case where
owner@ or listmaster@ have made a decision which can be overridden by
GR (IE, banning someone from using control@ or similar), -private is
notified so DDs are aware.


Don Armstrong

-- 
S: Make me a sandwich
B: What? Make it yourself.
S: sudo make me a sandwich
B: Okay.
 -- xkcd http://xkcd.com/c149.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130328223540.gq5...@teltox.donarmstrong.com

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

[Stefano Zacchiroli]

On Fri, Mar 29, 2013 at 01:59:11PM -0400, Daniel Kahn Gillmor wrote:
> Do we need to scientifically prove causation here?

Oh, you're totally right, we certainly do not need that to *work* on
improving bug report handling by maintainers.

It just takes that evidence to convince *me* that such aspect is a
relevant factor in the decrease of bug reporting rate :-). I digressed
on that point simply because Chris was wondering why *I* dismissed that
argument quickly. Again, "I certainly didn't mean to imply that bug
report handling is not something we should look into improving." Sorry
if that turn is now sidestepping the more important parts of this
conversation, it was not my intention to do so.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Chris Knadle]

On Friday, March 29, 2013 13:46:56, Stefano Zacchiroli wrote:
> On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote:
> > As such, there's an issue of "public perception" that may need
> > consideration.
> 
> […]
> 
> > I simultaneously acknowledge the problem of making a "DD expulsion
> > list" public; that's not exactly the kind of "trophy" anyone would
> > want to obtain.
> 
> I wholeheartedly agree with both your points here. Which, to me, is a
> good indication that this is, in general, a complex problem :)
> 
> I think the actual expulsion should, generally, not be publicly
> advertised; what I do want to be public is, in general, community
> backlash when deplorable social behavior is exhibited in public fora.
> Seeing that no one reacts to bad social behavior will give the distinct
> impression that the *community* accepts that behavior which is, imho,
> even worse than giving the impression that some authoritative "police"
> turns a blind eye on it.

I wholeheartedly agree.


[…]
On Friday, March 29, 2013 13:59:11, Daniel Kahn Gillmor wrote:
> On 03/29/2013 01:46 PM, Stefano Zacchiroli wrote:
> > On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote:
> >> I'm open to other theories as to the cause.  I am, however, a bit
> >> surprised that you'd completely dismiss the theory I've proposed so
> >> quickly. let you know that I regularly bump into users in Debian IRC
> >> channels saying things such as "I need to be involved in another bug
> >> report like I need a hole in the head."  I take that as a clear signal
> >> that there's a problem.
> > 
> > Well, I certainly didn't mean to imply that bug report handling is not
> > something we should look into improving. It's the causation relationship
> > between that and the decreasing number of bug reports which seems
> > unlikely to me. I'll be totally happy to reconsider that and I'm
> > generally very open to reconsider my positions. But I do think that we
> > need some concrete, scientific evidence, to prove causation in this
> > case, and I've yet to see some of it.
> 
> Do we need to scientifically prove causation here?  Chris is raising a
> good point, and a perception of hostile responses to a bug reports seems
> entirely plausible as a contributing factor to a decline in bug reports.

It's the best theory I've got so far.  I do /want/ a scientific causation if I 
could /get/ one, so I share Zack's desire for that.  Your question of "do we 
need to prove that" is likewise a good point; lack of respect or other abuses 
in bug reports is a problem /regardless./

> For that matter, I haven't seen any concrete, scientific evidence to
> support zack's suggestion that derivative distributions are siphoning
> off our bug reports.  While it seems potentially a plausible
> contributing factor to me, i could also see an argument that the more
> derivative distros we support, the *more* bug reports we should get.
> (e.g. because all the downstream devs are upstreaming their reports and
> fixes back to debian, like we want them to, right?

Ah.  Here's an interesting related thought; some of the derivatives (such as 
Ubuntu) have Codes of Conduct covering developer communications, where Debian 
doesn't, and thus there's an expectation of civility there that we may lack.  
Thus, assuming that bugs are reported for to a derivative distribution and not 
to Debian, the "chilling effect" could theoretically still be a possibility as 
to part of the cause.

> These are not mutually-exclusive explanations, either, and there is no
> single, simple cause for outcomes like a decline in the number of bug
> reports.  I don't think that demanding "concrete, scientific evidence"
> is a reasonable bar for just considering what "might be one explanation
> for the steady drop in new bug reports" (chris's original words).

I likewisie don't expect any of us to be able to come up with a way of 
figuring out the cause definitively.  If we could, we'd do so.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


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

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

[Daniel Kahn Gillmor]

On 03/29/2013 01:46 PM, Stefano Zacchiroli wrote:
> On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote:
>> I'm open to other theories as to the cause.  I am, however, a bit surprised 
>> that you'd completely dismiss the theory I've proposed so quickly.
>> let you know that I regularly bump into users in Debian IRC channels saying 
>> things such as "I need to be involved in another bug report like I need a 
>> hole 
>> in the head."  I take that as a clear signal that there's a problem.
> 
> Well, I certainly didn't mean to imply that bug report handling is not
> something we should look into improving. It's the causation relationship
> between that and the decreasing number of bug reports which seems
> unlikely to me. I'll be totally happy to reconsider that and I'm
> generally very open to reconsider my positions. But I do think that we
> need some concrete, scientific evidence, to prove causation in this
> case, and I've yet to see some of it.

Do we need to scientifically prove causation here?  Chris is raising a
good point, and a perception of hostile responses to a bug reports seems
entirely plausible as a contributing factor to a decline in bug reports.
 It certainly wouldn't account for an increase in bug reports (i suspect
the set of socially-masochistic users is a vanishingly small one :P )

For that matter, I haven't seen any concrete, scientific evidence to
support zack's suggestion that derivative distributions are siphoning
off our bug reports.  While it seems potentially a plausible
contributing factor to me, i could also see an argument that the more
derivative distros we support, the *more* bug reports we should get.
(e.g. because all the downstream devs are upstreaming their reports and
fixes back to debian, like we want them to, right?)

These are not mutually-exclusive explanations, either, and there is no
single, simple cause for outcomes like a decline in the number of bug
reports.  I don't think that demanding "concrete, scientific evidence"
is a reasonable bar for just considering what "might be one explanation
for the steady drop in new bug reports" (chris's original words).

--dkg



signature.asc
Description: OpenPGP digital signature

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

[Stefano Zacchiroli]

On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote:
> As such, there's an issue of "public perception" that may need
> consideration.
[…]
> I simultaneously acknowledge the problem of making a "DD expulsion
> list" public; that's not exactly the kind of "trophy" anyone would
> want to obtain.

I wholeheartedly agree with both your points here. Which, to me, is a
good indication that this is, in general, a complex problem :)

I think the actual expulsion should, generally, not be publicly
advertised; what I do want to be public is, in general, community
backlash when deplorable social behavior is exhibited in public fora.
Seeing that no one reacts to bad social behavior will give the distinct
impression that the *community* accepts that behavior which is, imho,
even worse than giving the impression that some authoritative "police"
turns a blind eye on it.

> I'm open to other theories as to the cause.  I am, however, a bit surprised 
> that you'd completely dismiss the theory I've proposed so quickly.
> let you know that I regularly bump into users in Debian IRC channels saying 
> things such as "I need to be involved in another bug report like I need a 
> hole 
> in the head."  I take that as a clear signal that there's a problem.

Well, I certainly didn't mean to imply that bug report handling is not
something we should look into improving. It's the causation relationship
between that and the decreasing number of bug reports which seems
unlikely to me. I'll be totally happy to reconsider that and I'm
generally very open to reconsider my positions. But I do think that we
need some concrete, scientific evidence, to prove causation in this
case, and I've yet to see some of it.

> As always, I thank you for your comments.  :)

Ditto :-)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Chris Knadle]

On Friday, March 29, 2013 09:41:23, Stefano Zacchiroli wrote:
> On Thu, Mar 28, 2013 at 05:37:18PM -0400, Chris Knadle wrote:
> > 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.
> 
> FWIW, that is not correct. There have been other cases of member
> expulsions for, as you put it, "disciplinary" reasons, but for various
> good reasons not all of them are discussed publicly --- one thing is
> expelling a developer, another is putting that up to ever lasting public
> shaming on the web.  DAM can and do expel for disciplinary reasons,
> either on their own initiative, or following up to initiatives by other
> project members.  Whether that is done "enough" or not, of course, is a
> separate matter.

That's fair enough, but it would likewise be incorrect to make /assumptions/ 
about things I know nothing about.  As such, there's an issue of "public 
perception" that may need consideration.  If publicly a DD consistently 
misbehaves and seems to get away with it for a long time, but is later quitely 
and privately expelled, the public perception that remains is "Debian seemed 
to do nothing about it".  Additionally this effectgively censors things such 
that the issue can only be discussed in the general sense; e.g. "more DDs have 
been expelled than you are aware of", which is not useful information -- it 
leaves out all of the reasoning behind what a DD could theoretically be 
expelled for and what constitutes "going too far".

I simultaneously acknowledge the problem of making a "DD expulsion list" 
public; that's not exactly the kind of "trophy" anyone would want to obtain.

> > That might be one explanation for the steady drop in new bug reports:
>
> That's a bit preposterous, imho, the huge popularity of some of our
> derivatives---which, in the general case, both benefits from our work
> and give back to us so that we benefit from theirs---is a much more
> simpler explanation of those numbers. Beware of simplistic explanation.

I'm open to other theories as to the cause.  I am, however, a bit surprised 
that you'd completely dismiss the theory I've proposed so quickly.  I'll just 
let you know that I regularly bump into users in Debian IRC channels saying 
things such as "I need to be involved in another bug report like I need a hole 
in the head."  I take that as a clear signal that there's a problem.
 


As always, I thank you for your comments.  :)

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


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

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

[Stefano Zacchiroli]

On Thu, Mar 28, 2013 at 05:37:18PM -0400, Chris Knadle wrote:
> 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.

FWIW, that is not correct. There have been other cases of member
expulsions for, as you put it, "disciplinary" reasons, but for various
good reasons not all of them are discussed publicly --- one thing is
expelling a developer, another is putting that up to ever lasting public
shaming on the web.  DAM can and do expel for disciplinary reasons,
either on their own initiative, or following up to initiatives by other
project members.  Whether that is done "enough" or not, of course, is a
separate matter.

> That might be one explanation for the steady drop in new bug reports:

That's a bit preposterous, imho, the huge popularity of some of our
derivatives---which, in the general case, both benefits from our work
and give back to us so that we benefit from theirs---is a much more
simpler explanation of those numbers. Beware of simplistic explanation.

> As a bug reporter dealing with a misbehaving maintainer, this is what I would 
> want:
> 
>   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.

On the other hand, the above are indeed reasonable community
expectations.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Moray Allan]

On 2013-03-26 14:58, gregor herrmann wrote:

Thanks for this question, which I would like to extend a bit.
Im my understanding you are pointing to unconstructive behaviour
related to technical work. What we also see (and discuss) every now
and then is behaviour that is socially questionable or clearly
unacceptable (from disrespect for peers to blatant abusive language).


While we rarely take formal action, I think that the "social" standards 
we apply to each other have increased over the years.  And my impression 
is that abrasive behaviour on the mailing lists or the main developer 
IRC channels has significantly reduced over the years.


The more negative social behaviour that I remembering seeing recently 
has tended to be in less visible places, for example in topic-specific 
development IRC and in replies to individual bug reports.  Those who I 
saw behaving negatively may not have intended to be rude or aggressive 
or dismissive, but people who are trying to help us and receive a 
negative response in this way may be discouraged from further 
involvement in Debian -- a single person with negative social behaviour 
can scare off many potential contributors.



What other ideas do you (plural, for all candidates, in case you see
the necessity to improve the handling of "social problems") see as
viable?


The most pleasant way to reduce such problems is to ensure that visible 
teams set extremely high standards that others wish to emulate, but I 
realise that this won't solve every problem.


Looking at your list of ideas:


Examples that have come up in the past and might or might not be
helpful:
- Encourage everyone to chime in when they see potentially
  unacceptable behaviour? In public/private?


Yes, as long as it is done in a spirit of being helpful and trying to 
help the person improve their behaviour, and not of trying to shame the 
person.  How public or private depends on the details of the situation 
and the relationship of the person "chiming in" with the topic and with 
the person they see as behaving unacceptably, and I don't think it's a 
simple binary question -- but as the goal isn't to shame people, the 
default should tend towards saying something in private.



- Should we try to establish a Code of Conduct for project members?
  Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
  examples.
  If yes, how would we do this, and how could we make sure it gets
  respected?
- Could the CoC for mailing lists
  (http://www.debian.org/MailingLists/#codeofconduct)
  be used as a starting point / be extended?
- Or Enrico's Debian Community Guidelines?
  http://people.debian.org/~enrico/dcg/index.html


Certainly the existing mailing list Code of conduct is not especially 
respected or enforced.  Perhaps people miss the final important points 
because they come after a long list of more technical ones.


I've previously done some research on companies' and professional 
organisations' written codes of behaviour.  In my view the best ones 
don't try to set out rules but offer a handful of concise and memorable 
aspirations.  A general "code of conduct" for Debian might be valuable, 
but then it should cover more than only "social" issues, and some more 
detailed guidelines would probably still be necessary in addition.


For an overall code of conduct, going through a formal process to adopt 
it might be part of the point of having one (both to make people think 
about it, and to increase the visibility of its adoption to people 
outside the project), but it's also useful to have more detailed 
guidelines that can be updated without formal agreement.


At the very minimum, more people should promote Enrico's Debian 
Community Guidelines -- they don't need any more official status for you 
to use and mention them, and thus influence other people to do the same.



- Another recurring topic is the Social Committee, cf. e.g.
  https://lwn.net/Articles/221077/ (or the ombudsman team mentioned
  in the article:
  https://lists.debian.org/debian-project/2007/01/msg00101.html )
  Would such a body make sense? With which powers?


I can see some positives from having this kind of Social Committee, but 
I'm unsure about the practicalities of creating one and keeping its 
membership updated.  If we were ever to move towards an elected board, 
it might make sense for that group to take on this role as well as its 
other duties.  In that case the problem of defining what "social" 
matters such a committee covered, and what powers it can use in 
response, would be avoided, and the question of membership would be 
reduced to a, by then, previously solved problem.  While a general board 
wouldn't be selected purely for "social expertise", it seems to me that 
the overall composition of such a board would necessarily reflect the 
project's "social" aspirations.


Even without us working out how to give special powers over social 
matters to an appropriate group, a group like the proposed "ombudsm

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

[Moray Allan]

On 2013-03-25 10:22, Steve McIntyre wrote:
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?


Yes, I think this is a real problem, and that we have a duty to deal 
with these issues with our users and free software as our priorities, 
not only the possible hurt feelings of our volunteers.  (It's clear that 
offending our volunteers can be very bad for our users, but the purpose 
of Debian is not merely to keep its members happy.)


There are two aspects of what you mention here that I would like us to 
avoid mixing up, though both could be described as "DD rights":


- technical permissions, including "ownership" of packages

- project membership.

In some (unfortunate) cases it may make sense for us to remove both 
together, but this should be as a result of thinking about two separate 
questions.  In other cases it could make sense to remove someone's 
project membership while leaving them with some limited specific 
technical permissions to participate in our work, or to remove specific 
technical rights while leaving someone a project member.


Although removing project membership is a much more serious step to 
take, we have in some ways been more cautious about the smaller step of 
restricting or removing specific technical permissions.  Just as we 
sometimes need to reconsider the benefit for the whole project of having 
someone as a member, not only the benefit for that individual, I think 
we sometimes we need to reconsider the benefit to the whole project of 
someone keeping specific technical permissions that they have previously 
acquired.  Discussions around package "salvaging" could be counted as an 
attempt to improve things in this respect -- not all the solutions need 
to be top-down from the centre.


Another reason for trying to separate the two aspects above is that we 
should avoid seeing them in the same light.  Removing someone's project 
membership against their wishes will remain a negative statement.  But 
removing some technical permissions can be done while we continue to 
value the person's work in other areas, don't intend any personal 
criticism, and are grateful for someone's previous work on an area.  For 
example, I would prefer that people always gave up specific jobs while 
they were still doing them well, but it is sadly natural to continue 
until available time and energy are lower, and then not to want to leave 
the job while doing it badly, and an external nudge may be needed.  
Where polite requests don't work, it may be better for the person if a 
third party takes a swift decision than if there is a protracted public 
discussion of the person's merits for the task, contributions made and 
harms caused, etc.


--
Moray


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/5a3fe700236016698d9d741c0171e...@www.morayallan.com

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

[Chris Knadle]

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.

   https://www.youtube.com/watch?v=ZSFDm3UYkeE

At 7:45 in the video:

   Community based on:
Politeness
Respect
Trust
Humility

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

   https://lwn.net/Articles/147969/


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.

   http://esr.ibiblio.org/?p=1310&cpage=1#comment-241442 


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 
reports:

   http://www.donarmstrong.com/posts/bug_reporting_rate/


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:

YearDDs DMs Release TotalDevs   # packages
-
1999494 slink   494 2250
2000638 potato  638 3900
20021164woody   11648500
20051167sarge   116715400
20071167etch116718200
2009106075  lenny   113525000
2011899 131 squeeze 103029000
2013976 186 sid 116238000


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 
want:

  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 

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

[gregor herrmann]

On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote:

> On 25/03/13 at 16:22 +, Steve McIntyre wrote:
> > 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.

Thanks for this question, which I would like to extend a bit.
Im my understanding you are pointing to unconstructive behaviour
related to technical work. What we also see (and discuss) every now
and then is behaviour that is socially questionable or clearly
unacceptable (from disrespect for peers to blatant abusive language).

I guess we all remember such examples, which have led to
demotivation, frustration, hurt feelings, and have driven
contributors away.

Lucas' reponse already shows an idea that might also be used for
these cases:
 
> One small thing that we could improve on is earlier official
> communication. For example, in case of seriously problematic behaviour
> that could eventually lead to censure or expulsion, official warnings
> could be issued to the DD, and Cced to -private@. In some cases, that
> could help the DD realize that s/he needs a behaviour change, and also
> limit the surprise effect if/when a final decision is taken.

What other ideas do you (plural, for all candidates, in case you see
the necessity to improve the handling of "social problems") see as
viable?

Examples that have come up in the past and might or might not be
helpful:
- Encourage everyone to chime in when they see potentially
  unacceptable behaviour? In public/private?
- Should we try to establish a Code of Conduct for project members?
  Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
  examples.
  If yes, how would we do this, and how could we make sure it gets
  respected?
- Could the CoC for mailing lists
  (http://www.debian.org/MailingLists/#codeofconduct)
  be used as a starting point / be extended?
- Or Enrico's Debian Community Guidelines?
  http://people.debian.org/~enrico/dcg/index.html
- Another recurring topic is the Social Committee, cf. e.g.
  https://lwn.net/Articles/221077/ (or the ombudsman team mentioned
  in the article:
  https://lists.debian.org/debian-project/2007/01/msg00101.html )
  Would such a body make sense? With which powers?

Short summary: Does Debian need procedures for intervening in cases of
dysfunctional social behaviour and which?


Thanks to all of you for standing/running in this vote, and for
taking the time to answer all these questions!


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rod Stewart: Smile


signature.asc
Description: Digital signature

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

[Gergely Nagy]

Steve McIntyre  writes:

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

I do not believe we're strict enough, not in general. On the other hand,
I'm not a big fan neither of overruling DDs, nor of limiting them. I'll
explain below.

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

The worst case (when it comes to expelling or severely limiting a DD) is
fairly rare, and I certainly hope it will stay that way (and we really
should not let things get that far). However, causing damage (due to
negligence and/or lack of attention) is far more common, and is a real
problem, one we should be dealing with much, much better.

The salvaging effort was/is something that gave me great hopes, because
it approached the problem from a less personal angle. The less personal
an effort is, the more successful it can be in this case, as far as I
see. Telling people they're harming the project is a lot different than
telling them that a particular package needs more love, and then going
ahead to aggressively hug said package to give it more love. I think the
salvaging idea is something that we should push forward with,
aggressively. While this is not a solution to every problem, it would
help in quite a lot of cases. How well this works, also depends on the
people involved, so great care must be taken to avoid as many bruises as
possible. (But not at the expense of dropping it alltogether and doing
nothing! Better some bruises and a handshake months or years later than
silently holding grudges forever.)

But alas, salvaging will not solve everything, and in some cases, it is
likely not an option either. In those cases, we should not be afraid of
overruling the maintainer, and if need be, forcibly transfer the package
to someone else. Yes, this would also have consequences we'd rather
avoid, there would be bruises, but if there's no better option, when all
other kinds of negotiations failed, then I see no better option.

Negotiation is something we should perhaps be practicing more, and
earlier.

In short, we have the procedures to completely revoke or severely limit
DD powers, but this is a power we should exercise rarely. Instead, we
should work towards discovering problems much earlier, and work more
aggressively towards resolving them, before more harm's done. Among our
tools to help with this quest, we have salvaging, and once a problem's
discovered, earlier negotiation attempts, possibly involving the DPL as
a mediator.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hajy8g4s@galadriel.madhouse-project.org

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

[Lucas Nussbaum]

On 25/03/13 at 16:22 +, 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?

I think that there's an unavoidable amount of such problems in a
large-scale volunteer-based project such as Debian. Solving those
problems is very hard, and I don't think that our current ways of
dealing with them can be improved much.

One small thing that we could improve on is earlier official
communication. For example, in case of seriously problematic behaviour
that could eventually lead to censure or expulsion, official warnings
could be issued to the DD, and Cced to -private@. In some cases, that
could help the DD realize that s/he needs a behaviour change, and also
limit the surprise effect if/when a final decision is taken.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130325170208.ga10...@xanadu.blop.info