Impact of ITS communication on issue reporting rate (Re: [all candidates] Removing or limiting DD rights?)
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
Secrecy of member expulsions (Re: [all candidates] Removing or limiting DD rights?)
[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!
Re: [all candidates] Removing or limiting DD rights?
]] 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?
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?
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 the rest of the bugs for gnomovision. You do indeed seem
Re: [all candidates] Removing or limiting DD rights?
Ian Jackson ijack...@chiark.greenend.org.uk 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?
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 perspective above, because this clashes with what I thought I knew about how to deal with bugs in the BTS. I
Re: [all candidates] Removing or limiting DD rights?
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?
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?
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?
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/ better -- yes. Some text with an explantion and some kind of human connection is best; preferably just enough so that there's no need to play the game of 20 questions. 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 This sounds like the start of an interesting thought... ;) If we could come up with a reasonable way of handling
Re: [all candidates] Removing or limiting DD rights?
Chris Knadle chris.kna...@coredump.us 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) http://www.eyrie.org/~eagle/ -- 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?
On Tuesday, April 02, 2013 20:34:28, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us 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/ have? One possible option to consider when this happens is to
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 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
Re: [all candidates] Removing or limiting DD rights?
gregor herrmann gre...@debian.org 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, with the possibility of the DPL granting the body the power
Re: [all candidates] Removing or limiting DD rights?
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?
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?
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?
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?
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 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?
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
Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)
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 -- 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 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=1310cpage=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 bug reports, so the discussion of
Re: [all candidates] Removing or limiting DD rights?
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?
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 ombudsman team could
Re: [all candidates] Removing or limiting DD rights?
Steve McIntyre st...@einval.com 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?
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
[all candidates] Removing or limiting DD rights?
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? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/20130325162223.ga11...@einval.com
