Re: GR proposal: code of conduct
On Wednesday, February 12, 2014 21:39:47 Russ Allbery wrote: > Chris Knadle writes: > > On Wednesday, February 12, 2014 16:27:52 Russ Allbery wrote: > >> Ean Schuessler writes: > >>> I am actually for the CoC. My complaint is that the GR does not > >>> require a record keeping process. I actually agree with Steve that we > >>> should not be concerned about publicly advertising the bans. A ban > >>> should have been proceeded by a warning and should be reasonable and > >>> clear-cut given the circumstances. By the time a ban is issued it > >>> should have been fairly obvious that the recipient effectively "signed > >>> on the dotted line" for it. > >> > >> Personally, I would much rather just let the listmasters decide how to > >> handle it. I certainly don't think a blanket requirement for a warning > >> is necessary, and would much rather let someone make a judgement call. > >> The person who started posting physical threats in response to the > >> recent TC decision, and who had never participated in the project > >> previously, didn't need a warning. > > > > The CoC takes into account "having a bad day", and instead specifically > > focuses on "serious or persistent offenders". (i.e. one-time verbiage > > that isn't to be taken seriously is not what the CoC is about.) > > Ack, sorry, I see that you took my reply as being about the CoC. I was > intending to specifically address Ean's request that we have a more formal > process with required warnings and record-keeping and so forth. > > I have no problems with the CoC as proposed. Oh. ;-) Okay cool. Sorry for the confusion. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: GR proposal: code of conduct
On Wednesday, February 12, 2014 16:27:52 Russ Allbery wrote: > Ean Schuessler writes: > > I am actually for the CoC. My complaint is that the GR does not require > > a record keeping process. I actually agree with Steve that we should not > > be concerned about publicly advertising the bans. A ban should have been > > proceeded by a warning and should be reasonable and clear-cut given the > > circumstances. By the time a ban is issued it should have been fairly > > obvious that the recipient effectively "signed on the dotted line" for > > it. > > Personally, I would much rather just let the listmasters decide how to > handle it. I certainly don't think a blanket requirement for a warning is > necessary, and would much rather let someone make a judgement call. The > person who started posting physical threats in response to the recent TC > decision, and who had never participated in the project previously, didn't > need a warning. The CoC takes into account "having a bad day", and instead specifically focuses on "serious or persistent offenders". (i.e. one-time verbiage that isn't to be taken seriously is not what the CoC is about.) > The level of process should be proportional to the level of injury that > could be caused by the action. We're talking about an action (temporary > bans) that is considerably milder than a traffic ticket. We should pick a > corresponding level of process. To keep from repeating it, everything below is "IMHO": The CoC isn't about process, but rather meant to encourage keeping communications civil and discouraging uncivil communication, along with stating some reasoning. It's intentionally short and simple. The specific process to use concerning consequences as well as the specific consequences are a related but separate matter. For the CoC it's enough to simply say that there are consequences and a hint about what could realistically be done. -- 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?
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?
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 en
Re: [all candidates] Removing or limiting DD rights?
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?
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 > >
Re: [all candidates] Removing or limiting DD rights?
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
Re: [all candidates] Removing or limiting DD rights?
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?
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?
ers should follow 3. A public dialog about the misbehavior with some Debian authority along with the misbehaving maintainer. Note on (3): In the cases I've dealt with, the misbehavior was in public bug reports, so the discussion of the misbehavior should likewise be public. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
