Talk:Bug management/Phabricator etiquette

Couple of suggestions
Happy to see this happening! Just a few suggestions for improved tone:


 * "No pointless comments." The word "pointless" in this context seems a little more hostile than you probably intended. I'd suggest "off-topic," "subjective," or something like "comments not directly related to reporting, confirming, or fixing the bug."
 * "However, we require that in the process, you attack things, not people." Again, the word attack is a bit strong – I for one don't want anyone "attacking" anything! "Critique" or even "address" are more neutral alternatives. Maryana (WMF) (talk) 16:45, 26 November 2013 (UTC)
 * It also needs some context for "attacks". A good link may be en/DontHateThePlayer; other relevant stuff ProductiveControversy, wiki:AdHominem, maaaybe wiki:AttackIdeasNotPeople. --Nemo 17:11, 26 November 2013 (UTC)
 * I'm also glad to see this developing. I think the 'critique' wording is good.  ("you can critique things; don't attack people"). Superm401 - Talk 20:40, 26 November 2013 (UTC)

re pointless: If pointless sets off alarm bells, I'd say "no non-constructive comments". Maryana's list is a pretty good one (report, confirm, fix) to add in the body as an explanation of what non-constructive comments are; I'd also add triage/evaluate severity to that list. -LVilla (WMF) (talk) 17:33, 2 December 2013 (UTC)


 * Very good points. I've incorporated them in the latest version. --AKlapper (WMF) (talk) 23:12, 5 December 2013 (UTC)

Vote
This is a good suggestion: «If you agree the bug should be fixed, vote for it by using the "(vote)" link». In fact, I find that telling people to vote for a bug is a good way to provide them a vent for their desires/anger which doesn't harm the discussion with noise. However, sadly not all products allow this... for those products, we should be more forgiving with mere "+1" comments, because they happen "by design". --Nemo 16:53, 26 November 2013 (UTC)

Voting is a bad idea in bugzilla; it should be disabled and the reference here removed. As I said a decade ago, "If you need your bug marked up, argue persuasively in the bug that the bug has a serious user impact, or provide a patch." +1 or a vote is neither of those things. -LVilla (WMF) (talk) 17:29, 2 December 2013 (UTC)


 * I'm not a fan of voting myself, but some developers try to use it (though visibility and UI can be improved), so I've left it in for the time being. --AKlapper (WMF) (talk) 23:14, 5 December 2013 (UTC)
 * If we're going to use voting, I think it should be tied to donations, as was suggested at Requests_for_comment/MediaWiki_Foundation with reference to the MWF. That way, there's a built-in check against sockpuppetry and a person who strongly wants to see a bug fixed can put his money where his mouth is. Of course, there's no guarantee that people will drop what they're doing and work on whatever people vote for (even if those voting rights were paid for), but in almost every nonprofit, donors have at least some influence. E.g., suppose Sergey Brin were to weigh in to suggest that a particular bug or request for comment be a high priority. Probably it would have an effect. Leucosticte (talk) 17:40, 9 December 2013 (UTC)
 * Voting is used already for certain products, but not all teams take those into account in the same way (see thread on wikitech-l). I still haven't seen a good crowdfunding tool/extension for Bugzilla to hand out bounties for certain tickets - this is something to persue in a generic way in upstream Bugzilla development. --AKlapper (WMF) (talk) 16:48, 11 December 2013 (UTC)

Respected contributors
I don't like this anti-bold statement. I don't think the point here is the ipse dixit; the point is first w:en:Wikipedia:Drop the stick and back slowly away from the horse carcass / w:en:Wikipedia:No climbing the Reichstag dressed as Spider-Man and second that what matters is the Consensus (or rather RoughConsensusAndWorkingCode?) among the relevant group, which may be very large in the case of some areas of MediaWiki core or just one person for some obscure extensions.

What's important is that the bug's status reflects reality, not who set it. --Nemo 17:11, 26 November 2013 (UTC)


 * I boldly changed the language to refer to maintainers and contributors to the component in question. Steven Walling (WMF) &bull; talk   20:59, 26 November 2013 (UTC)


 * Thanks, very welcome! --AKlapper (WMF) (talk) 23:14, 5 December 2013 (UTC)

Pointing out bad ettiquette
It says, "make them aware of this document, preferably via private email to avoid criticizing in public". I agree that's appropriate for minor cases, or when they're probably unaware of the policy. But for egregious bad conduct, I think it is sometimes appropriate to point it out publicly. Public silence can be interpreted as tacit support or tolerance of the bad conduct. Superm401 - Talk 20:40, 26 November 2013 (UTC)


 * +1. I've differentiated now between minor and major cases in the latest version. --AKlapper (WMF) (talk) 23:15, 5 December 2013 (UTC)

Link to "how to report a bug" and vice-versa?
Might want to link to How to report a bug and vice-versa? -LVilla (WMF) (talk) 17:35, 2 December 2013 (UTC)


 * Yes! Done now in the first sentence via "reporting". --AKlapper (WMF) (talk) 23:15, 5 December 2013 (UTC)

"other people's bugs"
From the main page:


 * 1) No messing with other people's bugs. Unless you are the bug assignee, have some say over the use of their time, or a contributor to the component in question, never change the "Priority" or "Target Milestone" fields. If in doubt, do not change the fields of bug reports that you are not the assignee of - add a comment instead, suggesting the change and the reasons for it.

This is pretty strong, and definitely not what we should be encouraging. If you're the reporter, or affected by the bug in a drastic manner, I'd hope you change the priority and leave a comment explaining why you did what you did. There are plenty of bugs I've fixed where I don't even use the extension or that code section, so as the assignee, I would be the wrong person to be setting priority. Legoktm (talk) 05:26, 4 December 2013 (UTC)


 * I've changed the language asking people to avoid it, to read about the definition of fields first (linked), and if unsure to add a comment only argumenting convincingly. I think it works as a compromise. --AKlapper (WMF) (talk) 23:16, 5 December 2013 (UTC)

Negativity
After thinking about it a bit, this whole draft is pretty negative, saying what you shouldn't do, not what you should.


 * "No pointless comments" --> "leave thoughtful comments"
 * "No abusing people" --> "Treat people respectfully"
 * "No private email" --> "Do things publicly"

Or something. The whole applicability part isn't very good either. It's basically a loophole for anyone to do anything, and will only hurt newcomers. Legoktm (talk) 05:40, 4 December 2013 (UTC)
 * Agreed. --MZMcBride (talk) 05:55, 4 December 2013 (UTC)


 * +1. I've taken your examples and also tried to rephrase the rest to use positive ways to express it. --AKlapper (WMF) (talk) 23:17, 5 December 2013 (UTC)

Copyright?
What's the copyright status of ? Without explicit permission, copying and pasting the content here isn't allowed, even with attribution. --MZMcBride (talk) 05:50, 4 December 2013 (UTC)


 * I have contacted the authors to clarify and currently I am awaiting a reply. --AKlapper (WMF) (talk) 22:38, 5 December 2013 (UTC)


 * Quoting the email reply by Gervase Markham about https://bugzilla.mozilla.org/page.cgi?id=etiquette.html: "I was the primary author of this document. Please feel free to reuse it under CC-BY-SA 3.0 or, at your option, any later version." --AKlapper (WMF) (talk) 10:54, 6 December 2013 (UTC)

Inapplicable to Wikimedia's Bugzilla installation
As noted on this talk page, the current version of these draft guidelines is basically a copy and paste of .

In addition to possibly being a copyright violation and importing a lot of unnecessary negativity, this draft is largely inapplicable to Wikimedia's Bugzilla installation. The etiquette guidelines don't match reality (current practice) or expected behavior, which is probably a predictable consequence of copying and pasting guidelines here that were meant for elsewhere.

Broadly, it's unclear why etiquette guidelines are needed. If there's a demonstrated need for etiquette guidelines, they should grow organically and be specific to Wikimedia's Bugzilla installation. --MZMcBride (talk) 06:06, 4 December 2013 (UTC)


 * I've contacted the authors to clarify the license and whether their material can be reused. The difference to current practice is partially intentional - if current practice was perfect, guidelines might not be needed. The reason is explained in the first sentence; if something is unclear I recommend that you ask as a followup in the mailing list thread. --AKlapper (WMF) (talk) 22:38, 5 December 2013 (UTC)


 * These are not theoretical issues. All of the problems it discusses have actually occurred on our Bugzilla, repeatedly.  That's the demonstrated need.  Generally, the problems have been dealt with on a case-by-case basis, but that has not always been effective. Superm401 - Talk 00:51, 6 December 2013 (UTC)

Invitation to do it yourself
Should the "No obligation" item invite people to consider fixing the bug themselves, and point them in the direction of How to become a MediaWiki hacker? It could be very empowering to some people to become developers, but I wonder what percentage of Bugzilla users would be willing and able to do so. I also wonder if some might construe it as suggesting that their bug is unlikely to be fixed unless they personally code the solution; that could deter filing helpful bug reports. Leucosticte (talk) 17:40, 9 December 2013 (UTC)
 * Yes, it should! Good point, I've added a link to that section. --AKlapper (WMF) (talk) 16:50, 11 December 2013 (UTC)

RESOLVED statuses (possibly off-topic)
Perhaps it's outside the purpose of this page, but one thing I've noticed is there isn't really a "resolved" status for "this is a bug in some other piece of software, not ours". Examples include 38109 and 58178. Anomie (talk) 17:47, 9 December 2013 (UTC)
 * "INVALID" says there wasn't a bug in the first place, but there was. This seems closest, though, because there wasn't a bug in MediaWiki.
 * This also seems to me to imply that the filer should have thought better than to file the report with us, which could come across poorly.
 * "WORKSFORME" implies it couldn't be reproduced, but it can be with the old version of the external software.
 * "WONTFIX" implies it won't be fixed, but it hopefully was or will be.
 * "FIXED" implies we fixed it when we didn't.
 * "This also seems to me to imply that the filer should have thought better than to file the report with us, which could come across poorly." The truth hurts. :) I guess we could have a RESOLVED CANTFIX...Leucosticte (talk) 18:29, 9 December 2013 (UTC)
 * I agree this can be a problem sometimes, but I prefer to keep it simple and stupid (if possible), so INVALID with an explanation why we cannot do anything "on our side" and where to push the bug instead kind of works for me... but I have on my list for next year to take a look which resolutions other projects use in Bugzilla. --AKlapper (WMF) (talk) 16:52, 11 December 2013 (UTC)

Conflict resolution instead?
The document still (even after recent changes) reads pretty negative; I am afraid that this will be used for bashing users, especially those frustrated and with the limited English language skills will be first victims. I don't think that our Bugzilla is riddled with hard to handle conflicts. I would suggest to split this document into two guidelines:


 * 1) How to report a bug should be expanded with some explanations about our workflow and how to be more helpful not only when reporting but also when working on the bug; Bug management/Bug report life cycle should be more visible and give examples of positive/negative behaviour and explain our users what exactly happens after the bug is reported; that a volunteer might or may not pick it, how we assign priorities and that we don't provide a premium customer service.
 * 2) Community conflict resolution guidelines: what to do if you believe you are handled improperly; you think you have been ignored or treated unfair; including advice to developers how to interact with users. This should cover not only Bugzilla, but also code review and the mailing list.

What I would like to avoid that the only practical use of this page will be in the context of the message "You [will be/have been] blocked from Bugzilla, for details please see mw:Bug management/Bugzilla etiquette". I don't think that hurts that much if somebody posts "Polish wikisource is broken please fix!!!" bug to vent off; we have edit and Mark as Duplicate buttons available to deal calmly with those cases.

« Saper // talk » 21:40, 9 December 2013 (UTC)
 * Instead of saying that the document reads pretty negative, you could have said this document can be improved so that it will read more positive. Leucosticte (talk) 21:58, 9 December 2013 (UTC)
 * Community conflict resolution guidelines sounds like a way broader topic that (as you wrote) isn't Bugzilla only. It's definitely in the scope of the Engineering Community Team though (which I am a part of) so I encourage you to bring it up at our next IRC meeting (they are monthly). --AKlapper (WMF) (talk) 16:55, 11 December 2013 (UTC)

Thank you for addressing this problem
Many users are focused on content, and are unlikely to notice or submit a "bug." They may not know what a "bug" is, or how it is defined. They certainly don't know who's who in the coding pecking order. Predictably they will err in presentation, content, and deferment. Problems of this nature are necessarily unavoidable and irresolvable; however, "Don't get your panties in a twist" if novices don't conform to complicated conventions should have a prominent place in your etiquette. Fred Bauder (talk) 11:09, 10 December 2013 (UTC)
 * I don't see an issue if users don't know what is a bug or not, as long as somebody who knows explains it in a friendly way in an (errorneously created) bug report and points to a better place where to bring up the issue. :) Who's who: It's up to the community and the bugwrangler (me) to make sure that the right people get aware of a bug report that covers their area of code. If you refer to comments, there have been approaches in other Bugzilla instances how to display some more info, e.g. Maemo Bugzilla had an icon for established community members based on a Bugzilla group; GNOME Bugzilla had a "points" system, and Mozilla Bugzilla displays "New to Bugzilla" next to newly registered Bugzilla users - that's what quickly comes to my mind in this area. Could you elaborate on "Don't get your panties in a twist"? Does that translate to "Be lenient towards new users" or do you mean something else? --AKlapper (WMF) (talk) 17:00, 11 December 2013 (UTC)
 * get one's knickers in a twist, presumably. Anomie (talk) 15:20, 12 December 2013 (UTC)
 * Yes, don't make a big fuss over predictable newbie errors. Fred Bauder (talk) 14:08, 19 December 2013 (UTC)

Not resolving social issues in a bugzilla
I would like to see a one-liner that for social matters that it encourages and prefers a discussion via an RFC, rather than trying to start a discussion that addresses and attempts to resolve societal issues in BZ. This is more so important at WMF (than Mozilla) where there is a huge social user base, many of whom are not technically orientated. — billinghurst  sDrewth  12:50, 10 December 2013 (UTC)
 * You're talking about this kind of RFC rather than this kind, right? Leucosticte (talk) 18:58, 10 December 2013 (UTC)
 * I'm pretty sure that this is a great point that we should cover, but I still often fail myself to understand "when" complexity is high enough that an RFC would be a better place. Are there "When to turn a topic into an RFC" guidelines? :-/ --AKlapper (WMF) (talk) 17:01, 11 December 2013 (UTC)
 * I don't think social issues are in scope of bugzilla (or mediawiki type rfcs) whatsoever. These should be decided on mailing lists or on some (non mw.org) wiki depending on context. Bawolff (talk) 03:25, 20 December 2013 (UTC)

Net gain in success and that through peace
"When we have a bug, we all lose. When we fix it, we all win. Therefore, together, we shall work about it, and together shall we overcome!".

If only everyone works towards this slogan and goal, Bugzilla would be a completely tameable and homely daemon.

If only everyone who logs on to those pages realize that our goal is common and our true winning is accomplished only when there is a net gain for the movement, with an attitude to come off with one's own prejudice and ego, Bugzilla would raise higher shining than the star of Wikimedia in general itself. Viswaprabha (talk) 18:10, 13 December 2013 (UTC)
 * Even when people have good intentions and agree on a common goal and even the means for attaining that goal, they can still inadvertently act uselessly, wastefully, or counterproductively. Leucosticte (talk) 18:35, 13 December 2013 (UTC)
 * People with good intentions are passionate about them. So we might have the same honorable goals but disagree strongly about the best way how to achieve these goals. Sometimes I have the feeling this might be the reason why we have not achieved world peace yet... :) --AKlapper (WMF) (talk) 18:40, 13 December 2013 (UTC)
 * I don't think it's an excess of passion that's the problem. There are some bugs, for instance, that people don't care all that much about, and therefore don't express any vehement disagreement about. The apathy in those areas doesn't help fix the bugs; it just masks the underlying problem, which is that even if we did care (which is another way of saying, even if he had enough resources to devote some effort to every problem, including those that are low priority right now), we might not be able to figure out the best approach.


 * It's probably the same way with the larger world. It takes a lot of passion just to do what's necessary to survive in this universe. If we were more apathetic, we'd disagree less, but the forces of entropy would gain the upper hand and overwhelm us, because we'd lack the motivation to overcome them. People go to war over their fears that some allegedly evil political, economic or religious faction or system will destroy them. It makes sense, if you accept the assumptions put forth as to how important human existence is, how great a threat those "evils" are to human existence, how wonderful the proposed remedy would be, and how ethical it would be to implement it.


 * The human mind being as imperfect as it is, people will often go down the wrong path in their assumptions. Those of us who have changed religions and political affiliations repeatedly are well-aware of this, but despite all those humbling experiences, it's still necessary to act on whatever belief one thinks (based on one's best understanding of the logic and evidence available) is optimal, because the alternative is to give up on trying to pursue what seems to be the best way forward, and sit around helplessly doing nothing. You either risk doing too little, too late out of hesitancy; or too much, too soon, and in the wrong way out of excessive eagerness. Victor Hugo, in Les Misérables, compared those who hesitate to cats who loiter in a half-open door "at the risk of being crushed by fate abruptly closing the opportunity." I was going to say "Welcome to the human condition" but apparently it's also the feline condition. Leucosticte (talk) 19:50, 13 December 2013 (UTC)
 * Very thoughtful and true. Thank you for writing this, Leucosticte. --AKlapper (WMF) (talk) 01:10, 14 December 2013 (UTC)
 * While we're at it, let's mention some more French people: is it worth using the Volonté générale concept somewhere? The status of a bug is something which is out there, we just have to discover it. (Note, the en.wiki article's view looks disputable.) --Nemo 09:32, 20 December 2013 (UTC)

How non-tech users view some of these issues
There's often a disconnect between the apparent conventions of Bugzilla "regulars" and those who come only sporadically to the site. One of the most obvious is "WONTFIX", which is sometimes used for "we don't have the resources to do this" (e.g., a proposal that will require 50,000 person-hours and lead to zero gain); sometimes it means "we don't want to do this"; and sometimes it means "we can't do this" (i.e., it's just not technically possible to meet the request). I've seen all three uses, and even reading the comments thoroughly, I'm often not able to tell *why* something is WONTFIX. The absence of clear explanations for WONTFIX leads to reporter frustration, particularly when multiple reporters from different projects and varying facility in English are participating in the bug.

Sometimes something is identified as a bug on multiple projects over time. If the first report was closed as WONTFIX, the subsequent ones are all lumped in to that first report and are all closed WONTFIX, without consideration to whether the continued reporting of the same problem from different users should be re-evaluated. It's poor etiquette to just shuffle off these repeated concerns like this, and it's another source of frustration, especially for the infrequent bugzilla reporter.

There is the practice of saying something is "RESOLVED-FIXED" when only one aspect of a bug is fixed. If there are multiple criteria that must be resolved for the original bug to be fixed, it shouldn't be closed as fixed until all criteria are fulfilled. It's fine to break it up into separate bugs and attach them to the original, which can act as a tracker, but that bug isn't fixed until all the sub-bugs are resolved. This practice of marking bugs as fixed before all the problems mentioned in the original report are resolved directly leads to people reopening bugs.

Bugzilla isn't a friendly place for people who don't know the idiosyncracies of the language; in fact, it's scary and full of people asking questions that non-technically oriented people are incapable of answering. Too many times I've seen something described as a 'social issue' when, in the view of the users involved, it is an issue that prevents them from using the software effectively. I can't count how many times I've come away from bugzilla feeling like I've just been called stupid. Please remember that we're not all technical geniuses. Risker (talk) 21:06, 19 December 2013 (UTC)


 * in regards to wontfix for things that we do not have resources to fix. I don't think that should happen, ever. We are a volunteer organization (sort of). Bugs that the wmf doesn't care about should stay open in case someone outside wmf wants to fix it. Wontfix should be reserved for cases where we wouldn't fix the bug even if someone handed us the fix on a golden platter. (Exception: if fixing the bug would require inordinate amount of code change we  might wontfix on a its not worth it. But that should only be in extreme cases). Last of all, the reasoning of wontfix should always be clear. If it isn't don't hesitate to ask for clarification
 * in regards to partial fixes - the bug should be split into multiple bugs in that case, and it should really be the responsibility of the bugzilla regulars to make sure that happens. Imo its totally acceptable to REOPEN the bug if a situation like that happens.
 * in regards to not being a friendly place for the non technical - I'm sorry to hear that. There is going to be technical jargon, as it is primarily a place to do technical work, not a support forum. However queries directed to users really shouldnt be overly technical. Last of all, its always ok to ask for clarification. If that's not coming across we should try to do something to make sure it does. Bawolff (talk) 03:18, 20 December 2013 (UTC)
 * Here's a thread from November 2012 discussing use of WONTFIX for low-priority items. That was a fix that required intervention by someone with shell access, but there were ways that other contributors could make it easier, e.g. by writing a script. If we were to WONTFIX stuff that WMF doesn't want to invest resources in fixing, then we would need another Bugzilla for issues that people outside WMF might want to fix.


 * We could, I guess, have the "assigned" field or another field indicate that it will need to be someone outside WMF. But really, isn't that what the "priority" and/or "importance" fields are all about? When I see that a bug has been listed as low priority/importance, I assume that means that I might be on my own if I want it fixed.


 * It is good to clarify when it's okay for users to be bold and when it's better for them to err on the side of exercising restraint when it comes to making changes. Sometimes that can be implemented by having the software warn that a particular change might be disruptive. Leucosticte (talk) 03:33, 20 December 2013 (UTC)
 * I was mostly thinking about mediawiki issues. I guess Bugs against wikimedia operations issues might more reasonably be wontfixed in such circumstances as the pool of potential fixers is small. Bawolff (talk) 04:12, 20 December 2013 (UTC)
 * To be honest, I think there may be some issues with not considering the beneficial work of hundreds of volunteers, even if it is a "wikimedia operation". Huge chunks of mediawiki as we know it, including some useful extensions, were written by volunteers specifically for wikimedia operations. Some of them are really good at it - after all, WMF keeps hiring them... Risker (talk) 04:20, 20 December 2013 (UTC)
 * Bawolff above says it very well. I have a feeling that this etiquette won't work, if it's not perceived as fair; and that it currently doesn't yet look equal enough. Etiquette demands should be symmetrical for all involved parties, even when they're more likely to be used in one direction than in the other.
 * The tone of "Changing fields" is what could be improved, IMHO; perhaps also this recurring ugly term "bug owner" (ownership, what a horrible focus; we could even reverse it, "you don't own MediaWiki"/your bug?). For instance: "Do not reopen INVALID or WONTFIX bug reports as a sign of protest" -> "Do not reopen or close bug reports just to reflect your personal view on the issue (examples: as a sign of protest; as a consequence of how your own time will be spent). --Nemo 09:09, 20 December 2013 (UTC)
 * Regarding wikimedia operations issues: For more and more things at least patches can be written by any volunteer, e.g. Apache configuration or DNS changes, and I try to advertise this in corresponding Bugzilla tickets. "bug owner": I cannot come up with something better than "people maintaining the area of code that the bug is in". I really like your change for "Do not reopen or close bug reports", please be bold and add it! Thanks! --AKlapper (WMF) (talk) 17:06, 20 December 2013 (UTC)
 * maybe something like: the priority field should only be modified by people who have the ability to potentially fix the bug. There is a real problem with people upping the priority on their pet bug, which is bad as then the priority field no longer reflects the bug's priority in reality, which makes the field useless. I agree that "ownership" should be avoided. We have never really had strong notions of things owned by certain developers imo (however, we do historically have notions of certain devs (e.g. Brion, Tim) being decesion makers that can make final decesions on a matter, which is different from someone owning something), i dont think we should start owning thing now. Bawolff (talk) 20:29, 20 December 2013 (UTC)
 * Making the assignee field more clear is an idea I dropped in 57648. However I don't see any value of describing whether something might be done by WMF staff or not. In the end we all work on the same software project in the same community, paid or not. Expectations on when to expect a certain ticket to be fixed should be expressed via the Priority field. --AKlapper (WMF) (talk) 16:52, 20 December 2013 (UTC)
 * I agree, having some bugs marked as staff only/volunteer only would be really bad imo. Bawolff (talk)
 * Hi Risker, thanks for your comments!
 * I want "WONTFIX" to only mean "Maintainer is actively against fixing this request". Current lifecycle might be too vague by saying "will not be fixed"? WONTFIX should NOT mean "we don't have time to work on this but we would accept patches". Lowest priority should be used for that instead.
 * Decisions in general should be explained to avoid confusion. However this is idealistic as time to explain is limited when you are also expected to get some code written (plus I'm pretty sure that sometimes developers are afraid that a way bigger discussion starts after they have explained their reasons).
 * "WONTFIXing without consideration to whether the continued reporting of the same problem from different users should be re-evaluated." - Totally agree. This is one thing that the duplicates statistics should be used for, which currently does not display bug resolutions. Sigh. I've turned that into a ticket so I don't forget.
 * Sometimes there are different ideas of when to consider a bug report as FIXED, but I haven't really seen a "practice of saying something is RESOLVED-FIXED when only one aspect of a bug is fixed". Maybe my understanding of "practice" is different. It's hard to generalize but I'd say that if a functionality is implemented and worked in a quick test, than a report can be closed as FIXED. But of course code is never perfect so follow-up issues should be handled in separate tickets. If we aim for perfect, bug-free code and leave tickets open as dependencies I'm afraid that we will never consider a task/ticket implemented and FIXED. :)
 * "asking questions that non-technically oriented people are incapable of answering": I think we can only try to minimize that by allowing triagers and developers to spend less time on elaborating how to provide information X plus improving related documentation. At some point I'd like to turn my "stock answers" script into a proper extension so everybody can use them in Bugzilla (with the naive hope that this will increase friendlyness and quality of instructions to provide more information). Yeah, point taken. :-/ --AKlapper (WMF) (talk) 16:50, 20 December 2013 (UTC)

Blunt, dense tone
I got an impression that the tone is blunt and dense. The vocabulary is weak. Perhaps that is intentional to target foreigner audience, but it does make reading more difficult. --Gryllida 00:31, 20 December 2013 (UTC)
 * I suggest you to just edit the tone and vocabulary; if people disagree, they'll revert. Discussion on writing style tends to get unproductive, editing is more focused. --Nemo 08:42, 20 December 2013 (UTC)
 * I agree. Sometimes just making the attempt to figure out alternative wording causes it to become evident to the person that, despite the drawbacks in how it's written, there's no better wording that comes to mind. In some of those cases, one has to reach the uncomfortable conclusion that what we have is optimal. The optimal may still happen to suck, but what can you do?


 * However, it might be appropriate to say, "Here are some examples of possible wording I've thought of" and list them and the pros and cons of each. E.g., I could say, "Rather than 'bug owner', let's call it 'bug category coordinator' or 'specific software functionality lead developer'. Unfortunately, the first name is ambiguous (does the person coordinate bugs or categories?) and both of those names are relatively lengthy, which will lead people to turn them into acronyms, which will confuse people further."


 * Even if they're bad ideas, they might be thought-provoking. On the other hand, lately I'm starting to wonder if it actually is helpful to list bad ideas I've come up with in hopes that someone will come up with a way to turn them into good ideas; it seems like more often, they have to be scrapped entirely. Leucosticte (talk) 17:34, 20 December 2013 (UTC)

Notifications
I see that discussion above is quite active already/again, but nevertheless I think a post on wikitech-l (and a mention that I think there was on the monthly report) is not enough. I forwarded to mediawiki-l but that's just the minimum. Perhaps we could add a line to MediaWiki:Sitenotice for a week or so? Does bugzilla have a sitenotice-like feature controllable via the UI? --Nemo 08:32, 20 December 2013 (UTC)
 * Personally I see the main focus of Bugzilla for developers and tech-oriented users, so I won't push for a sitenotice on some wikisite (but wouldn't be against it either). Bugzilla can display at the top of every HTML page the HTML that is entered in its "announcehtml" parameter. We used this last year to announce downtime for the upgrade to version 4.2. Any text proposal? :) --AKlapper (WMF) (talk) 16:57, 20 December 2013 (UTC)
 * "Bugzilla etiquette guideline drafted: help complete it"? IMHO users registered on this wiki are likely to have an interest in this, I'll add it to the sitenotice. --Nemo 09:48, 21 December 2013 (UTC)

"Accept decisions"
Sorry, but this is not going to improve our Bugzilla at all. On the contrary, it will restrict communication throughput, lead to wrong decisions, increase user dissatisfaction, decrease the quality of bug resolutions and therefore is detrimental to overall quality of the MediaWiki software.

If we were to "accept decisions" we would have to silently endure wrong decisions like the inital deployment of VisualEditor, ULS or other much disputed projects. The MediaWiki developer's (ore more often WMF employee's) decisions are not beyond reproach – they're human after all and therefore errors occur. We have to accept this and so we have to consider this also in our Bugzilla etiquette.

Regarding the amendment "you can add a comment to the bug report without reverting the status or resolution of the bug report": No, this does not work. I've seen enough bug reports to know that if a bug is closed (and not reopened) it is closed for good. A decision won't be revised once a bug is closed. If the decision was wrong, the bug has to be reopened to allow for an productive outcome. Even if it might seem inconvenient for the person who closed it initially.

After all it's better to revise a decision and live with it than to stick to a wrong decision for the sake of not admitting one was wrong. --Patrick87 (talk) 18:18, 21 December 2013 (UTC)
 * I hate to say, it, but this page is mostly just codifying the way Bugzilla works already. The concerns you mention (developer mistakes and wrong decisions) are often best addressed off Bugzilla - on mailing lists, wikis, etc. This, that and the other (talk) 03:31, 22 December 2013 (UTC)
 * Would it be helpful if people would provide examples of the situations in which the current etiquette hasn't been working? Some of these criticisms sound pretty abstract. Leucosticte (talk) 04:29, 22 December 2013 (UTC)
 * For the opposite of what you're asking, an example where people fought over a decision, would be things like the revert war over the status of 6455. I agree with you that people should not have to blindly accept decisions, developers are certainly not infallible. The problem comes in when people think a good way to change developers minds is to spam the bugzilla comments with rants or try to have a revert war over the status field. Bawolff (talk) 05:48, 22 December 2013 (UTC)

No obligation
I think I actually disagree with no obligation to fix issues. Don't get me wrong, for most bugs that is 100% correct. We have the same amount of obligation to fix somebody's random pet peeve, that a Wikipedian has to write an article on a particular topic for me. However given we are not just making random (Free) wiki software, but also supporting a large wiki-farm, I do think we have some (very limited) obligations. For example in cases of downtime, or severe bugs that utterly prevent Wikimedians from fulfilling the mission of their project, I think we have an obligation to at least spend a reasonable amount of effort to try to make the sky un-fall down. On the MediaWiki side, I would say we have a reasonable obligation to third party users to address security issues in a timely fashion once we are aware of them. These obligations don't give others the right to scream abuse at developers if they feel that we are not living up to what they imagine our obligations are, but I don't think we should state that we have zero obligations. Bawolff (talk) 06:34, 22 December 2013 (UTC)