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)

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)

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.