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)

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)

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)

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)

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)

"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)

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)

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)

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)