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)

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)