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

[Russ Allbery]

I'm going to move this fully onto -project, since we're into the voting
phase and I think this is more of a general project discussion at this
point.  Hope that doesn't lose anyone.

Chris Knadle  writes:

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

That's good perspective, thank you!  I don't interact with the bug
trackers of a lot of other projects and mostly end up looking at them when
someone points me at something controversial, which produces a skewed
impression.

I've had very positive interactions with Debian's bug tracker and don't
recall ever having a bug closed without an explanation, but I'm sure that
has something to do with the fact that I'm visibly part of the project and
people may recognize my name, so I don't necessarily see the same thing an
average user would.

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

The problem that we always have with any sort of social protocol is that
the project is huge and has a lot of people with, effectively, admin
rights to things, and not all of them are going to be on the same social
page or even listening to any of the discussions.  So it's hard to effect
change.  One can try to lead by example and set an overall tone, but there
are always going to be parts of the project that won't even see the
examples.

I do think that debian-mentors helps a great deal here, not just in
helping people with their problems but in modeling a social interaction
style for people who are new to the project.  It is, by and large, quite
polite and constructive (often much more so than debian-devel), and I
think that matters.  People take cues for expected social behavior from
their early interactions with a community.

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

It was quite some time ago.  Mail to -done would have been copied to you
as the submitter, so if you didn't see any mail, something else happened,
I assume.  However, given that you didn't even see any mail to control,
I'm not sure what happened.  Whatever mail message closed the bug is going
to be logged in the bug, whether a reply to it or a message to control.

> Lately I've sort of avoided [debian-devel] because some of the
> discussions there can be somewhat vitriolic.

Yeah, and it's possible that asking about a bug would break into a
vitriolic debate if people disagreed about the handling of it.  However, I
would be surprised if any of that vitriol were aimed at *you* as the
person to raise the issue; it's more likely that people would start
yelling at each other.  :)

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


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

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

At the moment I'm a bit surprised and somewhat dismayed at the

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-project-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 with a maintainer that closes my bug report with no
> explanation at all?

If you and your allies have enough time and knowledge to help with the
package, then yes, you can certainly help with this.

You could write to the maintainers:

  I notice you closed my bug without comment, so I went to take a look
  at t

Re: Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

On Tue, Apr 02, 2013 at 09:26:18PM +, Sune Vuorela wrote:
> > TL;DR: we've been invited to participate into GNOME Outreach Program
> > for Women and I'd like to accept the invitation.
> 
> I'm very much against spending debian money on paying for contributors
> time.  While I would love a more diverse group of debian developers, I
> really don't think that using our money is the right thing to do.  So
> please, pretty please, let us reconsider.

Hi Sune, thanks for your feedback. We can surely reconsider. In fact,
while I'd like to go ahead right now with the preliminary organization
for OPW participation (e.g. collecting the internship topics, which
might be useful anyhow), I'll be happy to leave plenty of way outs: OPW
application deadline is May 1st, so there will also be time for the next
DPL to object to this.

And of course I'll be happy to stop this right now, in presence of
substantial objections from the project.  So let's have this discussion
as I think it's a very important one to have, no matter what.



I think we really need to participate in outreach program, of any kind.
Quite some of those programs focus on positive discrimination to
increase diversity and offer some kind of monetary incentive. Let's see
if we have fundamental objections in Debian to that sort of programs.

Back in the days (say, dunc-tank, for those of us who remember it) the
main objection to "paying contributors time" was that it creates
differences in the community. That's a very sensible objection.

It seems to me that we have overcome that objection with GSoC, program
in which we have participated for many many years, and where
contributors are paid. We have done so 2 ways.  One is the focus on
attracting *new* contributors, which is the point of pretty much every
outreach program; we don't strictly enforce the "new" rule, but it is
evident to anyone that contributors won't be GSoC students for long, and
that reduces the disparity.  Another one is positive discrimination: we
realized we need to reach out to a specific class of contributors
(students) and we accept some differences in the hope that they will
remain around in Debian afterwards, when the incentives are over.

My feeling is that the origin of money in GSoC (Google) is not
particularly relevant in addressing the "create differences" objection,
but I might be wrong. I'll be happy to be convinced of that.

(Note, in passing, that we have in the past directed part of GSoC money
to individual GSoC mentors, de facto paying their contributors time. But
that's a detail, which we should probably reconsider in the future, as
there all the above good reasons to ignore the "create differences"
objection do not hold.)


For OPW, the money do not come from GNOME, they ask participating
organizations to provide them (after all, differently from Google, they
don't have anything to gain from the program). Therefore one way to
overcome your objection on the money origin is to seek specific
sponsoring for Debian participation into OPW. We can do that. In fact,
what Ana proposed in this thread (targeting GSoC per-project 500 USD to
our OPW participation) is a possible implementation. Do you consider
that solution acceptable?

If not, we can do mission-specific fund raising, I wouldn't mind that
either, as we do something similar for, say, DebConf already. It
wouldn't be possible, in my opinion, to raise all the needed money
before OPW application deadline. But I'm 100% sure that given few months
we can raise the needed money. Hence, I do not see this as a blocker to
go forward (as long as people believe in my prevision). Would you
consider this acceptable?


Honestly, it still seems to me that the origin of money is not relevant.
For instance, even if in GSoC the money is not Debian's, it is Debian
who decides who get them, and it is Debian who can take them away
(e.g. by failing students at mid-term), under the authority of DPL
delegates. All this seems well-established in our community, even if we
can obviously reconsider that too.

The main point is rather how do we make the disparities created by this
kind of outreach programs acceptable. For OPW I think the path is pretty
clear: do not accept people with significant prior Debian involvement
(e.g. DM or DD, but we might consider other kinds of activities), and do
not accept interns more than once over the years.  But we can *also* do
ad hoc fund-raising (possibly to top left-overt GSoC money) if people
prefer that.


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?

[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-project-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