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

Re: Removing or limiting DD rights?

On Wednesday, April 03, 2013 22:50:10, Russ Allbery wrote:
> 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.

Makes sense.

> Chris Knadle <Chris.Knadle@coredump.us> 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.

My most extensive BTS use is in Debian's BTS as well.

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

I have the same guess, and that's another reason I'm explaining what I see as 
a non-DD.  My concern in this area is that I see the number of bugs closed 
without explanation slowly increasing rather than decreasing.  (I don't keep 
statistics, so this is my long-term gut feeling.)

> > 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 know.  However, I don't think we're yet at the point of working on a fix; 
right now I think we're still here:

   -> 1. Admit the problem
      2. Consider possible solutions
      3. Implement a solution
      4. Check results, possibly go back to (2)

... and that's okay -- it takes time to understand this.  For instance, maybe 
we can find a way to get statistics on how often bugs are closed by the 
maintainer without discussion, to see where we are.  [Probably after the 
Wheezy release and election of the next DPL.]  Might not be easy to script, 
but should be possible.

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

Yes, exactly.  Most of what I know about dealing with bug reports were learned 
while dealing with bug reports.  ;-)  From what I gather, bug reports are the 
/entry point/ into Debian for most users.

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

The bug in question [one one and only that I referred to the TC] where this 
happened was opened by someone else, and I found it makred as Done without any 
log from a mail to control or any log of it being closed.  Baffling.  The bug 
log therefore looks strange now, because the first hint that it had been 
closed is the log entry in which I re-opened it.

I currently consider this "the stealth close" -- because I don't understand 
how the bug was closed, or if the submitter was notified of the close.

Is this possible via emailing close-quiet@bugs.d.o ?

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

I've learned not to many any assumptions about reactions on -devel.  ;)

  -- Chris

Chris Knadle

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

Reply to: