Re: Dealing with ITS abuse
Sune Vuorela wrote: On 2013-04-06, Filipus Klutierochea...@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. It's really too bad that this experience is private, then. Had it been public, its interest here wouldn't be nullified by a certain barely intelligible Danish's untrustworthiness. Oh well - just another example of transparency's relevance, I suppose. -- 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/519c3674.60...@gmail.com
Re: Dealing with ITS abuse
Hi Don, Don Armstrong wrote: On Sun, 14 Apr 2013, Chris Knadle wrote: On Saturday, April 13, 2013 13:34:23, Don Armstrong wrote: On Sat, 13 Apr 2013, Chris Knadle wrote: [...] Why should there be consequences that you can see? A man you work with is treating you badly [...] -- the behavior continues in the same way it did before. Now the question: why would you need to know what consequences there were? The only consequence I should be concerned about is whether the behavior stops or continues. No, if someone behaved abusively, you should in this case first be concerned about the abusive contributor justifying his actions, then about him recognizing his error(s) and apologizing (or in other words, promising to change his behavior). It's only at this point where respect is restored, cooperation can resume, and where you can simply watch out for new abusive behavior, indeed. Unless you're *aware* that the consequence to the contributor was a restriction. [...] People need feedback. That's why owner@ responds to the reporters to indicate that we have received their communication and addressed the issue. My own experience unfortunately infirms that. [And in cases where we do not respond, it's because we've missed or have not received the communication.] [Highly unlikely] If from the point of view of the reporter the feedback isn't working, then it begs the question of what the feedback was. If the behavior doesn't change or improve, reporting it again is the appropriate action. If the reporter isn't aware that ow...@bugs.debian.org reacted appropriately to the first report, I have to disagree, the reporter should escalate. You can also always escalate problems to leader@.
Re: Dealing with ITS abuse
Hi Russ, Russ Allbery wrote: Chris Knadlechris.kna...@coredump.us writes: On Thursday, April 11, 2013 23:49:18, Filipus Klutiero wrote: In absolute terms, contacting ow...@bugs.debian.org is not a good way of dealing with any problem, as ow...@bugs.debian.org is - as indicated inhttps://lists.debian.org/debian-project/2011/11/msg00030.html - a private email alias, with little chance of solving the issue. If that doesn't work, you can escalate the issue to project leadership as a last resort... but you'll also hit a private email alias there. Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. I think both of you have a very strange understanding of how human psychology works if you think public callouts are the best first step in dealing with inappropriate behavior. I also wonder what places you've worked in and what sorts of management interactions you've had if you don't believe private conversation can ever address public problems. Although Chris's reply could sound like that out of context, I for one have never stated that private conversation can never address public problems (which doesn't mean that private conversation is always the best way to address a public problem). Nobody suggested public callouts neither - in a hierarchical context, referring a controversial decision to a higher decision-making instance is natural and a pacific way to try to reach a better decision. [...] However, Debian doesn't have a habit (for all the psychological reasons I mention above) of creating a public wall of shame to record places where people have been given a penalty flag. If you weren't involved in the issue, you probably didn't hear about it, and IMO that's how it should be. Again, nobody's suggesting to create a public wall of shame, but that doesn't mean consequences should be secret. Sorry but to avoid rehashing, please see https://lists.debian.org/debian-project/2013/04/msg00042.html -- 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/519b0389.8090...@gmail.com
Re: Dealing with ITS abuse
On Monday, April 15, 2013 20:44:21, Don Armstrong wrote: On Sun, 14 Apr 2013, Chris Knadle wrote: On Saturday, April 13, 2013 13:34:23, Don Armstrong wrote: On Sat, 13 Apr 2013, Chris Knadle wrote: Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? The goal of any communication from owner@ regarding abuse isn't confrontation, but correction and resumption of communication. Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. I should note that owner@ still hasn't been contacted about this communication, so if it's still a problem, please do that. That's correct; these bugs are closed now, but this will be useful information if this happens again. Thanks. If from the point of view of the reporter the feedback isn't working, then it begs the question of what the feedback was. If the behavior doesn't change or improve, reporting it again is the appropriate action. You can also always escalate problems to leader@. ... yes. I appreciate that this exists. And if I thought this was a solution I wouldn't be discussing this here. But along these lines I'll just mention the following: The DPL changes every couple of years, and each DPL likely has their own style of dealing with this. Hopefully there are some historic guidelines (and records of actions) available in this area for the new DPL, or the incumbent DPL can pass down to the incoming DPL how they dealt with such things before. The DPL is also likely very busy; I'm wondering if the DPL helpers could help with this if needed. -- 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/201304161014.58795.chris.kna...@coredump.us
Re: Dealing with ITS abuse
On Saturday, April 13, 2013 14:42:57, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: On Friday, April 12, 2013 13:52:42, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. I think both of you have a very strange understanding of how human psychology works if you think public callouts are the best first step in dealing with inappropriate behavior. I also wonder what places you've worked in and what sorts of management interactions you've had if you don't believe private conversation can ever address public problems. Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? No, I'm saying that's often not a productive place to *start*, and hence I completely disagree with this critique of privatization. If private communication doesn't work, some sort of public confrontation may be a next step (in fact, it's possibly inevitable), but it's probably not a great place to start. Oh? But as I've seen, that's exactly what the tech-ctte does. When communication comes in that is disrespectful, the reponse (which is exactly what I'm promoting here) is this: This is disrespectful. Stop. This does three things: 1. Points out the part of the communication that was disrespectful. 2. Takes a public stance that it should stop. 3. Preserves the dignity who was the recipient of the disrespect. An remedy attempt using private communication does none of these three things. Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. Private communication was used to try to deal with that, and did not stop the abusive communication. That's clearly a problem, and hopefully further action was then taken, but I think it's a rather sweeping conclusion to draw that therefore private communication is useless because in two anecdotal cases for you it didn't help. The above approach I've outlined would have, and later did when it was used. It's also the general recommendation given for exactly the same issue elsewhere. At the moment I think the above is more relevant than my prior or current places of employment, but I'm willing discuss that if that's more relevant than what happens within Debian. No, no, my point there is just that we're not doing something novel and different here. Humanity has been dealing with social conflicts for quite a while, and there is a lot of established understanding of what tends to work and what tends not to work. If one is advocating an approach in Debian that one would never follow at a place of employment, I think that should at least call into question what we might be missing. Ah I see. Okay. Same thing above usually works with employers/management. Okay. Forgive my ignorance -- I'm not able to find definitive information about how this is dealt with in Debian. [Is there an Employee Handbook for Debian?] Up to now the only penalty discussed was expulsion AFAIK. Most of the sanctions Debian can take are various forms of temporary or permanent revocation of privileges. When it comes to abusive discussion in public places, suspending someone's ability to use that place of discussion is an obvious possibility. I don't think you could ban a maintainer from a bug report on a package he/she is maintaining. [I realize you likely meant this for outside the BTS, but this particular thread is about ITS communication.] If the problem is related to maintenance of a specific package, the Technical Committee can change the maintainership of the package (although I don't recall if that's been done). The Technical Committee deals with technical issues, and not social issues. Most of the first rounds of intervention involve varying amounts of social pressure, with people like the DPL or other team members of affected teams taking the person aside privately and saying look, no, this isn't okay. I know. If I thought that worked I wouldn't be discussing this here. -- 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/201304151625.49953.chris.kna...@coredump.us
Re: Dealing with ITS abuse
Don Armstrong d...@debian.org writes: I'm /not/ asking to know who got a penalty flag (I don't need to know) -- but I and others /do/ have a need to know if those exist and what they are. The only reason I've been looking at past events was to /infer/ what penalties exist due to a lack of information. They exist. They are modified as necessary to fit a particular situation, and range from warnings to technical restrictions on communication to expulsion. It's already been said, but I think it'd be great if that (and the proper address to contact) could be mentioned somewhere more prominently. This is actually the first time I've ever heard about it. Before this thread, I assumed that in case of problems like the ones mentioned before, there is simply no-one at all who can be contacted, and nothing at all that can be done about it. 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/87a9oz5b3a@vostro.rath.org
Re: Dealing with ITS abuse
On Saturday, April 13, 2013 13:34:23, Don Armstrong wrote: On Sat, 13 Apr 2013, Chris Knadle wrote: Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? The goal of any communication from owner@ regarding abuse isn't confrontation, but correction and resumption of communication. Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. Why should there be consequences that you can see? Let me answer you this way. A man you work with is treating you badly. He often makes disrespectful statements to you and others, and if you have any question for him he simply ignores you and doesn't acknowledge your question. TThis goes on long enough that there's clearly a problem, communication is clearly broken, so you report the problem. The person you report it to has a private conversation with the person being disrespectful towards you and others, but nothing seems to change -- the behavior continues in the same way it did before. Now the question: why would you need to know what consequences there were? People need feedback. If from the point of view of the reporter the feedback isn't working, then it begs the question of what the feedback was. Only in exceptional circumstances do we actually use the controls that we have, but when we do, only -private and the individual sanctioned are informed. Reporting individuals are informed that we have addressed their concerns, but not necessarily the manner in which it has been addressed. I see. I'm /not/ asking to know who got a penalty flag (I don't need to know) -- but I and others /do/ have a need to know if those exist and what they are. The only reason I've been looking at past events was to /infer/ what penalties exist due to a lack of information. They exist. They are modified as necessary to fit a particular situation, and range from warnings to technical restrictions on communication to expulsion. Hmm okay. -- 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/201304141608.56954.chris.kna...@coredump.us
Re: Dealing with ITS abuse
Russ Allbery writes (Re: Dealing with ITS abuse): Most of the sanctions Debian can take are various forms of temporary or permanent revocation of privileges. When it comes to abusive discussion in public places, suspending someone's ability to use that place of discussion is an obvious possibility. If the problem is related to maintenance of a specific package, the Technical Committee can change the maintainership of the package (although I don't recall if that's been done). I don't recall the TC ever changing the maintainership of a package because of abusive communications by the maintainer. Or indeed, ever, apart from in one exceptional case where the existing maintainer intended to remove the package and the TC gave the package to someone who wanted to become the maintainer so it could be kept. 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/20843.9145.558577.443...@chiark.greenend.org.uk
Re: Dealing with ITS abuse
On Friday, April 12, 2013 13:52:42, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: On Thursday, April 11, 2013 23:49:18, Filipus Klutiero wrote: In absolute terms, contacting ow...@bugs.debian.org is not a good way of dealing with any problem, as ow...@bugs.debian.org is - as indicated in https://lists.debian.org/debian-project/2011/11/msg00030.html - a private email alias, with little chance of solving the issue. If that doesn't work, you can escalate the issue to project leadership as a last resort... but you'll also hit a private email alias there. Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. I think both of you have a very strange understanding of how human psychology works if you think public callouts are the best first step in dealing with inappropriate behavior. I also wonder what places you've worked in and what sorts of management interactions you've had if you don't believe private conversation can ever address public problems. Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. Private communication was used to try to deal with that, and did not stop the abusive communication. This isn't about the past though, it's about the future -- what to do when this happens. I'm thankful that this is rare, but it's also clear (at least to me) this can and will happen again, so I'm trying to figure out how to handle this correctly. At the moment I think the above is more relevant than my prior or current places of employment, but I'm willing discuss that if that's more relevant than what happens within Debian. What I really want in this game is a penalty flag: unnecessary roughness called by the referee so that there can be a /measured response/ to the problem. Right now Debian doesn't seem to have penalty flags or even a referee, and instead the roughness has to be bad enough that the linesmen step in and eject the player for all time. This is not true. Okay. Forgive my ignorance -- I'm not able to find definitive information about how this is dealt with in Debian. [Is there an Employee Handbook for Debian?] Up to now the only penalty discussed was expulsion AFAIK. However, Debian doesn't have a habit (for all the psychological reasons I mention above) of creating a public wall of shame to record places where people have been given a penalty flag. If you weren't involved in the issue, you probably didn't hear about it, and IMO that's how it should be. I'm /not/ asking to know who got a penalty flag (I don't need to know) -- but I and others /do/ have a need to know if those exist and what they are. The only reason I've been looking at past events was to /infer/ what penalties exist due to a lack of information. This is a volunteer project, so there's some limit to what effective sanction the project has available to it, and it doesn't always work. But the same is true in every workplace I've been in, even though a manager in an employer-employee relationship has many more effective sanctions available. There are all kinds of limits. -- 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/201304131150.16364.chris.kna...@coredump.us
Re: Dealing with ITS abuse
On Sat, 13 Apr 2013, Chris Knadle wrote: Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? The goal of any communication from owner@ regarding abuse isn't confrontation, but correction and resumption of communication. Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. Why should there be consequences that you can see? Only in exceptional circumstances do we actually use the controls that we have, but when we do, only -private and the individual sanctioned are informed. Reporting individuals are informed that we have addressed their concerns, but not necessarily the manner in which it has been addressed. I'm /not/ asking to know who got a penalty flag (I don't need to know) -- but I and others /do/ have a need to know if those exist and what they are. The only reason I've been looking at past events was to /infer/ what penalties exist due to a lack of information. They exist. They are modified as necessary to fit a particular situation, and range from warnings to technical restrictions on communication to expulsion. Don Armstrong -- If I had a letter, sealed it in a locked vault and hid the vault somewhere in New York. Then told you to read the letter, thats not security, thats obscurity. If I made a letter, sealed it in a vault, gave you the blueprints of the vault, the combinations of 1000 other vaults, access to the best lock smiths in the world, then told you to read the letter, and you still can't, thats security. -- Bruce Schneier 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/20130413173423.gh15...@teltox.donarmstrong.com
Re: Dealing with ITS abuse
Chris Knadle chris.kna...@coredump.us writes: On Friday, April 12, 2013 13:52:42, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. I think both of you have a very strange understanding of how human psychology works if you think public callouts are the best first step in dealing with inappropriate behavior. I also wonder what places you've worked in and what sorts of management interactions you've had if you don't believe private conversation can ever address public problems. Are you saying that if someone communicates abusively in the BTS publicly, they _shouldn't_ be publicly confronted about that at all? No, I'm saying that's often not a productive place to *start*, and hence I completely disagree with this critique of privatization. If private communication doesn't work, some sort of public confrontation may be a next step (in fact, it's possibly inevitable), but it's probably not a great place to start. The goal isn't to punish people; the goal is to convince people that their behavior could be improved and that it would be better for everyone involved (including them!) if it did. Punishment is more of a last resort when we can't manage to find any other social solution. Obviously, getting the abusive behavior to stop is also a goal, but taking a bit of time to try to convince people to do that voluntarily is something that I think is worth it. People generally get much more defensive and therefore less to change anything when called out in public, which is why pretty much every grievance procedure that I'm aware of encourages people to start privately. (Please note: that does NOT mean that public complaints are invalid, or that people should be attacked for not choosing to do that. The onus is still on the person being abusive to change their behavior. But as long as the situation isn't dire, the chances of a positive outcome for everyone are higher, usually, if one starts privately.) Two particular bug reports I was invovled in recently had repeated abusive communication in them with no consequences that I could see for the one communicating abusively. Private communication was used to try to deal with that, and did not stop the abusive communication. That's clearly a problem, and hopefully further action was then taken, but I think it's a rather sweeping conclusion to draw that therefore private communication is useless because in two anecdotal cases for you it didn't help. At the moment I think the above is more relevant than my prior or current places of employment, but I'm willing discuss that if that's more relevant than what happens within Debian. No, no, my point there is just that we're not doing something novel and different here. Humanity has been dealing with social conflicts for quite a while, and there is a lot of established understanding of what tends to work and what tends not to work. If one is advocating an approach in Debian that one would never follow at a place of employment, I think that should at least call into question what we might be missing. Okay. Forgive my ignorance -- I'm not able to find definitive information about how this is dealt with in Debian. [Is there an Employee Handbook for Debian?] Up to now the only penalty discussed was expulsion AFAIK. Most of the sanctions Debian can take are various forms of temporary or permanent revocation of privileges. When it comes to abusive discussion in public places, suspending someone's ability to use that place of discussion is an obvious possibility. If the problem is related to maintenance of a specific package, the Technical Committee can change the maintainership of the package (although I don't recall if that's been done). Most of the first rounds of intervention involve varying amounts of social pressure, with people like the DPL or other team members of affected teams taking the person aside privately and saying look, no, this isn't okay. -- 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/87ehee1dce@windlord.stanford.edu
Re: Dealing with ITS abuse
On Thursday, April 11, 2013 23:49:18, Filipus Klutiero wrote: Hi Chris, 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. ;-) I'm not sure I understand what you're not sure to understand... but I'll try to rephrase. You were asking whether contacting ow...@bugs.debian.org is a good way of dealing with ITS abuse. Officially, reporting such abuse currently has to be done that way. As there is a single way, it's (relatively) as much a good way of dealing with problems as a bad way. In absolute terms, contacting ow...@bugs.debian.org is not a good way of dealing with any problem, as ow...@bugs.debian.org is - as indicated in https://lists.debian.org/debian-project/2011/11/msg00030.html - a private email alias, with little chance of solving the issue. If that doesn't work, you can escalate the issue to project leadership as a last resort... but you'll also hit a private email alias there. Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. What I really want in this game is a penalty flag: unnecessary roughness called by the referee so that there can be a /measured response/ to the problem. Right now Debian doesn't seem to have penalty flags or even a referee, and instead the roughness has to be bad enough that the linesmen step in and eject the player for all time. This is unacceptable. I entirely agree that the solution should be public, but that doesn't mean there will be a public solution. Having any solution would already be more than I expect. That's exactly why we're openly discussing it. -- 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/201304121146.01065.chris.kna...@coredump.us
Re: Dealing with ITS abuse
Chris Knadle chris.kna...@coredump.us writes: On Thursday, April 11, 2013 23:49:18, Filipus Klutiero wrote: In absolute terms, contacting ow...@bugs.debian.org is not a good way of dealing with any problem, as ow...@bugs.debian.org is - as indicated in https://lists.debian.org/debian-project/2011/11/msg00030.html - a private email alias, with little chance of solving the issue. If that doesn't work, you can escalate the issue to project leadership as a last resort... but you'll also hit a private email alias there. Emailing anyone privately leads down the path of privatization. [I've already been down this road.] As such I think it might be better to publicly CC leadership, to invite public comment rather than private conversation, because private conversation cannot address the public problem. I think both of you have a very strange understanding of how human psychology works if you think public callouts are the best first step in dealing with inappropriate behavior. I also wonder what places you've worked in and what sorts of management interactions you've had if you don't believe private conversation can ever address public problems. What I really want in this game is a penalty flag: unnecessary roughness called by the referee so that there can be a /measured response/ to the problem. Right now Debian doesn't seem to have penalty flags or even a referee, and instead the roughness has to be bad enough that the linesmen step in and eject the player for all time. This is not true. However, Debian doesn't have a habit (for all the psychological reasons I mention above) of creating a public wall of shame to record places where people have been given a penalty flag. If you weren't involved in the issue, you probably didn't hear about it, and IMO that's how it should be. This is a volunteer project, so there's some limit to what effective sanction the project has available to it, and it doesn't always work. But the same is true in every workplace I've been in, even though a manager in an employer-employee relationship has many more effective sanctions available. -- 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/87hajbeivp@windlord.stanford.edu
Re: Dealing with ITS abuse
On Fri, 12 Apr 2013, Russ Allbery wrote: However, Debian doesn't have a habit (for all the psychological reasons I mention above) of creating a public wall of shame to record places where people have been given a penalty flag. I've personally been remiss in my goal of creating a Debian BTS wall of excellence to record awesome bug submitters and closers and general awesomeness every month. Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, Chew more! Do more! The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson 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/20130412184805.gi4...@rzlab.ucr.edu
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
Hi Chris, 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. ;-) I'm not sure I understand what you're not sure to understand... but I'll try to rephrase. You were asking whether contacting ow...@bugs.debian.org is a good way of dealing with ITS abuse. Officially, reporting such abuse currently has to be done that way. As there is a single way, it's (relatively) as much a good way of dealing with problems as a bad way. In absolute terms, contacting ow...@bugs.debian.org is not a good way of dealing with any problem, as ow...@bugs.debian.org is - as indicated in https://lists.debian.org/debian-project/2011/11/msg00030.html - a private email alias, with little chance of solving the issue. If that doesn't work, you can escalate the issue to project leadership as a last resort... but you'll also hit a private email alias there. I entirely agree that the solution should be public, but that doesn't mean there will be a public solution. Having any solution would already be more than I expect. Have faith, and you may succeed. -- 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/5167843e.1070...@gmail.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.
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 ).
