Re: Dealing with ITS abuse (Re: [all candidates] Removing or limiting DD rights?)
On 2013-04-06, Filipus Klutiero chea...@gmail.com wrote: It's not a /good/ way in absolute terms, but it's pretty much the only way for now, so I guess it's currently the best way (see https://lists.debian.org/debian-project/2011/11/msg00030.html ). My experience with contacting owner@bugs, listmaster, wikiadmins and other people to get abusers banned or in getting them to voice in has been only good. But of course, since my interactions mostly have been to getting a certain french-canadian with a irc nick that might rhyme with 'healer', there is quite a chance that that you can have had different experiences. /Sune -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkmgoe8.fhs.nos...@sshway.ssh.pusling.com
Re: Dealing with ITS abuse (Re: [all candidates] Removing or limiting DD rights?)
On Saturday, April 06, 2013 19:55:08, Filipus Klutiero wrote: Hi Chris, thanks for being faithful to our project and bringing up this topic :-S Chris Knadle wrote: 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? It's not a /good/ way in absolute terms, but it's pretty much the only way for now, so I guess it's currently the best way (see https://lists.debian.org/debian-project/2011/11/msg00030.html ). Uh... I don't understand. The above suggestions avoiding private email aliases; I'm not sure I understand where this fits the rudeness issues I've had in the BTS -- the bug reports where it happened are public. Maybe you can give me a better idea what you're trying to refer to. ;-) -- 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 Ma, 02 apr 13, 17:34:28, Russ Allbery wrote: 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: debian-user would do IMHO. If the issue is too complicated the reporter can always be referred to higher authorities (-devel, TC, etc.). 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. Maybe some advice in this direction could be included in the BTS notification? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: [all candidates] Removing or limiting DD rights?
On Sunday, April 07, 2013 03:40:02, Andrei POPESCU wrote: On Ma, 02 apr 13, 17:34:28, Russ Allbery wrote: 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: debian-user would do IMHO. If the issue is too complicated the reporter can always be referred to higher authorities (-devel, TC, etc.). Depends on the problem. For the types of problems I tend to report, I'm not sure [debian-user] would be appropriate -- and that mailing list is noisy even compared to [debian-devel]. One of the packages where the bug was merged and closed without any maintainer discussion was an external kernel module, which built correctly on one vanilla stable Linux kernel version, but failed to build on a newer stable version unless a kernel feature was enabled that the hardware doesn't support. I've been tempted to email -devel about this since Russ's suggestion, but I've decided I'd rather put that off until after Wheezy is released because this bug is likely not RC. -- 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 Wed 03 Apr 2013 23:50:10 Russ Allbery escribió: [snip] I do think that debian-mentors helps a great deal here, not just in helping people with their problems but in modeling a social interaction style for people who are new to the project. It is, by and large, quite polite and constructive (often much more so than debian-devel), and I think that matters. People take cues for expected social behavior from their early interactions with a community. And allow me to add that not only debian-mentors but DDs that do mentoring (sometimes personal one) and are very picky about the social behaviour. Ana has always pointed me with this, and I try to do the same with the people I sponsor. And the results tend to be most sastisfying :-) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
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!
Dealing with ITS abuse (Re: [all candidates] Removing or limiting DD rights?)
Hi Chris, thanks for being faithful to our project and bringing up this topic :-S Chris Knadle wrote: 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? It's not a /good/ way in absolute terms, but it's pretty much the only way for now, so I guess it's currently the best way (see https://lists.debian.org/debian-project/2011/11/msg00030.html ).
Purpose of tickets (Re: [all candidates] Removing or limiting DD rights?)
Hi Ian, Ian Jackson wrote: [...] 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. Your opinion would be arguable if helping to improve Debian was the only use of bug reports, but that is not the case. That use is probably the main one, but I can see at least 2 more uses: 1. Informing potential users on the software's quality (*We will not hide problems*). Debian has no quality standards for its software besides being safe and minimally usable, nor even package ratings, making it particularly important to provide alternative means for Debian users to estimate whether their investment in a package new to them would be profitable. 2. Most importantly, to document problems for users of the package, allowing them to see whether a workaround exists, whether a possible workaround has already been tried, letting them estimate how long they'll have to wait for a fix or finding alternative ways to obtain a fix. Careful users may also try to make sure an upgrade is a good idea (perhaps using apt-listbugs).
Closing due to too many bugs (Re: [all candidates] Removing or limiting DD rights?)
Ian Jackson wrote: [...] 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. There is no need to close all tickets. Those which look too costly can be left for when you or another contributor has more time. Or left open forever. Ticket severities can already help developers prioritize the tickets to read, to some degree. #704874 requests a real solution for that. This could also be complemented with a per-user read ticket status in the web interface... although that would first require to teach the ITS about users :-/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5160d3e5.9080...@gmail.com
I rid you of some of your bugs; please fix mine? (Re: [all candidates] Removing or limiting DD rights?)
Ian Jackson wrote: 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 to have a bit of a bug overflow crisis. I asked Alice for help; we took a look at the list and you'll see we have followed up with triage or status changes to a few of the open bugs which had the most obvious next steps. Please let us know whether this was useful. Would you like us to carry on with some of the less obvious bugs ? For example: #739130 probably needs to be reassigned to splurge-piper #739312 looks like a mips toolchain bug, will RFH to the mips porters ... I have to agree with Chris - that approach wouldn't help the maintainer, but harm him. That being said, if some overoptimistic contributors choose that way, or - hopefully - rather triage as standard practice, please don't (directly) write a mail to the maintainers that way. Once you triaged the easy cases, just write to the harder tickets. That way your contribution won't be lost... especially if the maintainer is set to hindrance mode. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5160ded8.8020...@gmail.com
Re: [all candidates] Removing or limiting DD rights?
I'm likewise following Russ's advice and moving this to -project alone. I've had some time to reflect on this, and wanted to offer the following thought. On Wednesday, April 03, 2013 13:13:48, Chris Knadle wrote: 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: […] 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 to have a bit of a bug overflow crisis. I asked Alice for help; we took a look at the list and you'll see we have followed up with triage or status changes to a few of the open bugs which had the most obvious next steps. Please let us know whether this was useful. Would you like us to carry on with some of the less obvious bugs ? For example: #739130 probably needs to be reassigned to splurge-piper #739312 looks like a mips toolchain bug, will RFH to the mips porters ... I've reconsidered the above suggestion and I think it would give positive feedback for the maintainer doing the wrong thing. It's based on making /assumptions/ of why the maintainer closed the bug without discussion -- the entire problem is that we don't know the maintainer's reasoning, because it wasn't given. Unfortunately, being overloaded is /not/ the only reason maintainers do this -- based on behavior I've seen, another reason this is done is when the maintainer doesn't want to discuss the issue behind the bug at all, and is thus an act of dismissiveness. I'd like to /think/ that this is a special rare case, but there's no way to know without having more communication in each case. -- 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?
]] 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-project-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?
Tollef Fog Heen tfh...@err.no writes: ]] 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? It's useful in some specific situations when you're doing mass bug manipulation (I've used it for that purpose) that's really just book-keeping and doesn't need to notify anyone. But they're fairly limited, and mostly one wants the fixed command instead anyway. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li90cdl3@windlord.stanford.edu
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-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/93853dd7c74239d3941ce5762...@mail.adsl.funky-badger.org
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-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvz81bz0@vostro.rath.org
Re: [all candidates] Removing or limiting DD rights?
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?
I'm going to move this fully onto -project, since we're into the voting phase and I think this is more of a general project discussion at this point. Hope that doesn't lose anyone. Chris Knadle chris.kna...@coredump.us writes: Good question. I can say this: Debian's BTS is the only bug tracker in which I've ever gotten a bug quickly closed without any explanation. Bugs in Debian's BTS also tend to be a bit more argumentative than other bug trackers, IMHO. [This is not necessarily negative.] That's good perspective, thank you! I don't interact with the bug trackers of a lot of other projects and mostly end up looking at them when someone points me at something controversial, which produces a skewed impression. I've had very positive interactions with Debian's bug tracker and don't recall ever having a bug closed without an explanation, but I'm sure that has something to do with the fact that I'm visibly part of the project and people may recognize my name, so I don't necessarily see the same thing an average user would. However these exceptions aside, bugs in the Debian BTS that I deal with get solved far more often than external bug trackers I've dealt with, and a lot of the maintainers seem like really good people who are simultaneously quite knowledgable. So if there's discussion open at all, it usually works out one way or another. Thus the catch seems to be getting that far in the first place for the minority of bugs where that's an issue. [And I won't get into the exceptions to the exceptions.] The problem that we always have with any sort of social protocol is that the project is huge and has a lot of people with, effectively, admin rights to things, and not all of them are going to be on the same social page or even listening to any of the discussions. So it's hard to effect change. One can try to lead by example and set an overall tone, but there are always going to be parts of the project that won't even see the examples. I do think that debian-mentors helps a great deal here, not just in helping people with their problems but in modeling a social interaction style for people who are new to the project. It is, by and large, quite polite and constructive (often much more so than debian-devel), and I think that matters. People take cues for expected social behavior from their early interactions with a community. That's interesting. That sounds like an improvement in this area. If you happen to know when that was implemented, I'd be interested. June of last year I saw a bug closed (marked as done, without explanation) where I didn't see any email sent to the BTS control@ address in the bug, so I was confused as to how the bug was closed. Would emailing -done do that? It was quite some time ago. Mail to -done would have been copied to you as the submitter, so if you didn't see any mail, something else happened, I assume. However, given that you didn't even see any mail to control, I'm not sure what happened. Whatever mail message closed the bug is going to be logged in the bug, whether a reply to it or a message to control. Lately I've sort of avoided [debian-devel] because some of the discussions there can be somewhat vitriolic. Yeah, and it's possible that asking about a bug would break into a vitriolic debate if people disagreed about the handling of it. However, I would be surprised if any of that vitriol were aimed at *you* as the person to raise the issue; it's more likely that people would start yelling at each other. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nfnrov1@windlord.stanford.edu
Re: [all candidates] Removing or limiting DD rights?
Chris Knadle 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-project-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-project-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-project-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-project-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: Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)
On Fri, 29 Mar 2013, 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. I'd certainly prefer for people to communicate their concerns directly to the person who they feel is acting inappropriately, but it's always ok to ask for ow...@bugs.debian.org's assistance if they are concerned about their ability to do so directly or effectively. 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). Perhaps this is something that I should link to from the new bug submission response. Don Armstrong -- We want 6. 6 is the 1. -- The Prisoner (2009 Miniseries) _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401210204.gb4...@rzlab.ucr.edu
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
Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)
Stefano Zacchiroli wrote: 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 think it is likely a real factor, though I have no evidence for that. But I think any good solution that is likely to fix it would have to involve somehow finding more volunteers to work on bug report handling. In my experience, Debian package maintainers generally are friendly and have their heart in the right place but just get frustrated after a while at trends like this one: http://qa.debian.org/data/bts/graphs/l/linux.png and this one: http://qa.debian.org/data/bts/graphs/l/linux-2.6.png I don't have any good fixes in mind, except for sharing work with upstream and other distros. That means: * making sure there is always a version with upstream support packaged in experimental, and ideally in stable-backports as well * working with bug reporters to test a recent version and backport fixes when they are found that way * explaining to bug reporters how to report their problem appropriately to upstream channels (and using the forwarded field in the BTS to indicate when that's done) * helping out on the upstream bugtracker so upstream has no reason to resent the increased workload you are providing I've been following this strategy for packages I work on, and it seems to work well. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130330234106.GA5995@elie.Belkin
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-project-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-project-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-project-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
