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 communitywiki:en/DontHateThePlayer; other relevant stuff meatball: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#Idea_.232:_Community_.2F_donor_driven_prioritizing 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 m:Consensus (or rather meatball: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) • talk 20:59, 26 November 2013 (UTC)

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

This was re-addressed by [1] as part of a conversation below. --Nemo 09:13, 24 December 2013 (UTC)

Pointing out bad etiquette

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)

This was re-addressed by [2] as part of a conversation below. --Nemo 09:13, 24 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 <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>? 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 <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.

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)

Can we remove the whole section? WMF-representatives usually do not omit emphasizing that it is their task running WMF-wikis properly on public communication.

Suggested edit summary for the removal: If MediaWiki developers are not obliged to stop serve bugs from happening they should not be paid. And even if you submit patches, they take ages to be reviewed. And of course, if you know s.o. or poke them in IRC, it's done faster.

But since I probably want continuing working together with you, I thought it would be better bringing this to the talk page first.

Btw. the fake-wiki-look did never make things easier for me. It raises the wrong assumption that it would work wiki-like which it simply doesn't, neither the parser works wiki-like, nor does the discussion style match in any way.

Setting up this wiki page is nice but to whatever conclusion/consent this collaborative works leads, it should be reflected in WM's Bugzilla installation. There is a lot of space next to the description field where good hints could be added and having a bug-creation-wizard asking questions whose answers are important and valuable would solve most of the issues this etiquette-policy is trying to address, making even some other supplementary pages superfluous (who actually reads the manual?). I believe information should be where they are needed and not burried in books. -- Rillke (talk) 22:35, 27 December 2013 (UTC)

"bug-creation-wizard": We have that. What's missing in the guided bug entry form? --AKlapper (WMF) (talk) 14:31, 28 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".

• "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.

Examples include bugzilla:38109 and bugzilla:58178#c7. Anomie (talk) 17:47, 9 December 2013 (UTC)

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

wikt: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)

I like "people who have the ability to potentially fix the bug" but the text now says "bug assignee, part of their management, or a contributor to the component in question" instead of "bug owner". I think we should still replace it by bawolff's proposal. Would love to hear Nemo's thoughts too. --AKlapper (WMF) (talk) 15:05, 22 December 2013 (UTC)

That "potentially fix the bug" doesn't work, it would exclude even most WMF managers. :) We need more opinions because I'm just repeating myself here: what we need to make clear, IMHO, is that bug status (state, severity, priority, milestone) just reflects reality, but doesn't cause it. There are relations among the two, but only because changing/discussing status is part of the process of development. No idea how to define those who have the ability to do this job: setting status is also an exercise in social chrystal-balling and technical guesstimates, even for the Official Product GodKing of a component, unless the way forward has been completely fleshed out in stories, tasks, assignments and whatnot. --Nemo 10:17, 23 December 2013 (UTC)

"Bug status, priority, milestone mostly reflects reality, it does not cause it." is a pretty good summary. But I cannot come up with a good way to describe the group of people setting it either. I think I initially called it "established community members", and I guess we'll have to accept that we just won't find a really good name but just an okayish well kind of works but not happy with it name... --AKlapper (WMF) (talk) 18:18, 23 December 2013 (UTC)

Ok, I inserted the sentence. I also replaced the summary of the paragraph, because "change planning" is not in the power of bugzilla anyway. I didn't plan to change the description of those "special people", but while reducing repetitions and improving the grammatical flow I replaced the long "unless you are" sentence with three words, "experience doing so" which is also closer to what you originally meant I think. If we really need a term/definition, we might use component stewards perhaps, unless that's too unclear/niche a word. As long as we don't convey a sense of exclusion as words like "owner" or "established" do, anything is fine IMHO. --Nemo 09:10, 24 December 2013 (UTC)

Again on equality, [3] is ok because that point only added burdens on reporters (was unidirectional). --Nemo 08:43, 29 December 2013 (UTC)

Making the assignee field more clear is an idea I dropped in bugzilla: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)

The only practice I've seen resembling "practice of saying something is RESOLVED-FIXED when only one aspect of a bug is fixed" is that MediaWiki bugs are normally marked fixed when they're fixed in master, even though it may take a week or two for the fix to be deployed to all WMF wikis. Which is far better than it was a few years ago, when it could be months or years before a fix was actually deployed to WMF wikis. I don't think this should be changed unless some automated process can handle the "go back and mark it FIXED two weeks later" step that humans are going to forget; personally, when I close a bug I try to include a note naming the wmf revision in which the fix will be included and pointing to MediaWiki 1.23/Roadmap. Anomie (talk) 14:47, 23 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)

Hi Gryllida. I agree with you. I've tried to clean up some of the language. Perhaps you can have another look at this document and let me know what you think? :-) --MZMcBride (talk) 08:03, 24 December 2013 (UTC)

Leucosticte, Nemo, I added a version which I find more intuitive in a subsection below. Gryllida 21:55, 25 December 2013 (UTC)

Leucosticte, Nemo, now I have edited the page directly. Gryllida 00:30, 28 December 2013 (UTC)

Thanks! (Diffing is easier.) --Nemo 08:50, 29 December 2013 (UTC)

Revision 1

• Scope: Comments should be directly related to reporting, confirming, evaluating the severity, or fixing the bug. Constructive and helpful thoughts unrelated to the topic of the report (for example, meta-level discussions on priorities in general, on whether a new extension is wanted at all) should go to the appropriate mailing lists or wiki talk pages.
  • Criticize ideas, not people. A healthy amount of constructive criticism helps to improve software. Vibrant debate inside of the Wikimedia community is encouraged.
  • Act in public. Unless you were asked to email somebody with specific information, place all technical information relating to a bug report in the report itself.
• Bug fields: Bug status, priority and milestone should reflect (summarise) reality, they don't cause it. If in doubt, read about the meaning of the fields and do not change them, but add a comment suggesting the change and convincing reasons for it.
• Timing: Don't demand a bug to be fixed, even if it seems top priority to you (if priority is underestimated, add a comment with missing information). Providing a patch often helps to speed up fixing a bug; +2 is one policy for approving proposed code.

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)

Thanks for doing this, Nemo! --AKlapper (WMF) (talk) 15:06, 22 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 bugzilla: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)

Thank you for that example; that bug report was interesting reading. It definitely made me realize what a great innovation Extension:Scribunto was. So, what happens when people disagree with Tim, Brion and/or Mark, as happened in that case? Then I guess the disgruntled users' next step is to go up the chain of command, perhaps all the way to the board of trustees if needed, or support a candidate in the board elections who will seek to use the board's authority to get that bug fixed? Is there anyone higher-up in that chain of command who would be interested in listening to such complaints? (If not, we may as well not encourage people to contact them.) Leucosticte (talk) 07:59, 22 December 2013 (UTC)

Patrick87: "wrong decisions like the inital deployment of VisualEditor, ULS or other much disputed projects" is nothing that would have been planned in Bugzilla and that would have changed by reopening tickets in Bugzilla. Your criticism refers to general high-level project planning which happens outside of Bugzilla anyway, so this does not apply here. --AKlapper (WMF) (talk) 15:09, 22 December 2013 (UTC)

But completely wrong decisions are taken on bugzilla and forced on users ignoring community consensus. May I know the threat - "Repeated ignoring of these guidelines may result in losing editbugs rights on Bugzilla or in your Bugzilla account being disabled" is applicable for the developers also? Why doesn't this draft mention anything about bugzilla requests by community (editor) consensus. I am really sorry, but I felt that the entire page is written around 'we need veto power' kind of attitude.--Praveenp (talk) 03:28, 23 December 2013 (UTC)

Don't take this the wrong way, but sometimes things really do need to be vetoed. People suggest some wacky things on bugzilla sometimes, which we just aren't going to do (For example, if someone requested that we send all the user data to google, in order for us to have fancy statistics on visitor viewing patterns, or if someone asks for an extension to be installed that has a security vulnerability in it that would allow people to take over other people's accounts [Yes, people request that sort of thing on bugzilla from time to time]). However, I doubt those are the type of situations you are referring to. There's other situations where WMF vetos certain changes that it feels goes against the mission or against the wiki-way (e.g. ARCTRIAL on 'pedia, although Wikipedian's sometimes treat that as a shocking new occurrence, where really, similar things had been vetoed in the past, usually for different wikis). Usually for something like that, a better place to yell and scream about it is probably foundation-l (maybe? Yelling on bugzilla probably won't do much good). Other then those situations, I think its rare for things to be outright vetoed on bugzilla if they have community consensus. Things might not get fixed that have community consensus if there is insufficient resources (or insufficient interest in allocating the resources to fix the thing), but that's life when there is finite developer time and an over-abundance of things to do. Last of all, there is a possibility of vetoing something if it has a long term cost - e.g. It would make it difficult to accomplish something in the future that we intend to do in the future, or its the type of thing that would require constant attention once its turned on. Those situations are rather rare (imho), but when they come up its important to remember that developers are a community to, and that community has its own interests which need to be balanced against the interests of the communities they serve. Bawolff (talk) 08:20, 23 December 2013 (UTC)

p.s. Specific examples may serve to inform this debate, So we could see when issues arise instead of talking in abstract. Then we could try to come to some conclusion about if the behaviour of developers should have been different in that instance or was it ok, and if lessons from that instance should be incorporated into guidelines. Also personally, I'm not sure I like the threat of loss of bugzilla rights in the guideline. People don't like ultimatums, and I can only recall knowing about a single situation where somebody had their bugzilla rights removed due to etiquette violations (I believe it was due to making repeated personal attacks after being warned), so its not like ettiquite violations are such a problem that a threat hanging over people's heads is needed. Bawolff (talk) 08:20, 23 December 2013 (UTC)

For the records (and while ignoring the disabling of spammer accounts in Bugzilla), I have disabled two Bugzilla accounts in the last fifteen months due to aggressive behavior and ignoring warnings to stop it and change the tone. (One of these accounts I re-enabled in the meantime.) This just refers to my own actions, as I cannot tell (means: cannot find out) whether other Bugzilla admins might have disabled other accounts. --AKlapper (WMF) (talk) 18:27, 23 December 2013 (UTC)

I commented so just because, while reading the draft, I immediately felt some similarities between some bugzilla comments and some sentences here. Please see the "Last Warning" here :-). There, then, we (ml.wikimedians) were kicked out even without an input mechanism for a week (bugzilla:51019). Later somehow they agreed community request! However a similar bug from en.wp community never treated by such a vengeance, though IMHO it was closed misinterpreting the original request. See the up and downs of bugzilla:49930 also. Also I recently saw someone mistreating community request from 'old English' wikipedia users, which I am not able to pin point now.--Praveenp (talk) 18:15, 23 December 2013 (UTC)

The problem of "completely wrong decisions" (quoting this rather subjective term) and community consensus on deployment decisions in the "Wikimedia" product (I don't consider changes in the MediaWiki software itself and its extensions subject of community consensus) won't be solved by guidelines that specifically refer to Bugzilla, as it is a higher-level problem ("which influence and power in which areas has a community on decisions made by non-community members which affect community members", or however you want to put it into words). So this draft does not mention anything about Bugzilla requests by community consensus because I don't see how this aspect is related specifically to Bugzilla. Refering to your specific comments, the "reopen edit war" in bugzilla:49894 made me add comment 13. It is one example why this Etiquette draft mentions "You can also comment on a report without reopening it". I have no idea what you refer to by "kicked out". Refering to the ml community without any input method: I have explained this in bugzilla:51019#c16 already, not sure how this is on-topic when it comes to Etiquette. The similar bug from en.wp never received such "vengeance" (huh? I have no idea why you come up with such an interpretation) because the tone in that report was neutral, not everybody felt the need to add non-technical "me too! +1!" noise in form of comments, and hence comments like bugzilla:51019#c15 were not needed in the en.wp ticket. And that might be a good example why the idea of an Etiquette came up. With regard to the 'old English' request: I highly disliked the behavior of one Bugzilla user adding destructive, off-topic, meta-level comments to a valid community request. So yes, I'd consider account disabling or editbugs removal applicable to all Bugzilla users, as all users should treat each other respectively while keeping the workflow constructive, no matter if users are developers or not, paid or volunteers, X or Y. --AKlapper (WMF) (talk) 18:42, 23 December 2013 (UTC)

Well, that Old English bug (which I read now for the first time, I believe) derailed because it had been poorly scoped, as far as I can see. No judging here, it happens (sadly; or maybe naturally). --Nemo 19:01, 23 December 2013 (UTC)

I've removed this section for now as it was inaccurate and didn't match reality. It also doesn't make sense to include such a section without also including guidelines for marking a bug report as "wontfix". Most of the conflict on Bugzilla seems to surround the use (and misuse and abuse) of "wontfix", so simply stating "accept decisions" is unacceptably shortsighted, in my opinion. If such a section is to be included at all, it must be accompanied by a section explaining when it is appropriate to use "wontfix". --MZMcBride (talk) 08:01, 24 December 2013 (UTC)

Current draft

Be willing to accept decisions. Bugs and enhancement requests may be set by the development team to higher or lower priorities than you would like, or they may be closed as WONTFIX if they are changes that those with authority over the matter have decided should not be made. You may disagree with these decisions, but do not fight the decision by re-opening (or closing) reports or by posting rants. Further technical information may still be submitted in Bugzilla. Efforts to persuade others that the wrong decision was made should take place outside of Bugzilla.

I still think this section sets the wrong tone, it's largely duplicative of the "aim for realism" section, and it doesn't address when it's appropriate to use "wontfix", which I think is essential if this section is to be included at all. I'd prefer to simply omit this section as I don't see any value to including it, but I'd be interested to hear what others think. --MZMcBride (talk) 23:45, 24 December 2013 (UTC)

The wording has problems, but maybe someone can find a way to summarize this complicated subject in a paragraph. I attempted to clarify the matter by writing Authority to make changes to the codebase and Wikimedia wiki configuration. Doesn't it boil down to, if the change is within your area of authority and you don't agree with it, you can WONTFIX it; and if you happen to be of equal authority as the person who WONTFIXed it, you can reopen it, as long as you're not revert-warring? (The same problems arise as on Wikipedia as to how you define "revert-warring"; basically it boils down to BRD, does it not? If you get reverted, then you discuss?) Leucosticte (talk) 23:58, 24 December 2013 (UTC)

Framing the issue in terms of authority is probably unhealthy. Anyone can mark a bug as wontfix or re-open a bug, but both acts require a deep understanding of context and surrounding nuance. --MZMcBride (talk) 00:17, 25 December 2013 (UTC)

So in other words it's a situation of be bold but please be careful! That's always a tricky balance. As a WikiDragon, I tend to favor boldness. Maybe there are some BugDragons around here too. As the linked wiki page on the topic notes, wikidragons have a tendency to get slain and to become endangered. A friend of mine commented, "Wikidragons tend to be loners, wikiknights organize together to fight wikidragons. That's why wikidragons lose so often. Isolated. Wikidragons also have a bit of a problem with the fire-breath. 'Hey, I was just breathing. How come you turned black, fell apart, and blew away?'" Leucosticte (talk) 00:41, 25 December 2013 (UTC)

You may be interested in User:MZMcBride/Bugs#Philosophy. --MZMcBride (talk) 11:30, 25 December 2013 (UTC)

Personally the "Authority to make changes to the codebase and Wikimedia wiki configuration" page confused me a bit and I'm actually not convinced it is needed. "Authority" does not feel right, as anybody could prepare a change and put it into Gerrit, but only some (+2) could merge that change.

Thanks for the draft above! Two small nitbits: I'd still prefer to keep the explanation for WONTFIX on Bug management/Bug report life cycle and I've tried to clarify its meaning (differentiation form lowest priority) in this change. Was wondering if "Efforts to persuade others" should become "Other efforts to persuade others" to make it clearer that technical arguments (previous sentence) are indeed still and always welcome. --AKlapper (WMF) (talk) 20:26, 25 December 2013 (UTC)

To the extent that we have a problem with people warring over WONTFIX declarations, then we need to explicitly address this here. That could be done by expanding the "Aim for realism" section, but I think it's better in a separate section.

I do not agree with MZMcBride that telling people (e.g., like me) not to re-open bugs that someone with far more technical knowledge (e.g., like MZMcBride) has declared to be a WONTFIX issue should only be done if we simultaneously tell the code maintainers that they're only allowed to use WONTFIX in certain circumstances. If we have a practical problem with this, then we can also have rules in place about that, but these are separate issues. We don't need to omit the "no fighting allowed" rule just because nobody has gotten around to writing the "no biting allowed, either" rule. Whatamidoing (WMF) (talk) 19:32, 26 December 2013 (UTC)

Warring over wontfix declarations is a direct result of the frequent misapplication of wontfix. Without addressing when wontfix should be used, I think it's nearly impossible to stop users from arguing over it. People like you are welcome to re-open any bug if that's the appropriate decision to take. Bugzilla is certainly blind to who specifically is making an action. I see no reason we (as Bugzilla users) can't similarly be blind. It isn't about who is making an action, it's about whether the action itself is appropriate. --MZMcBride (talk) 05:07, 27 December 2013 (UTC)

Well, you probably know more about this than I do, since one of my hopes in this document is for me to understand it better. But it seems to me that warring over WONTFIXes is, at least for a non-trivial minority, related to people honestly not knowing (or perhaps caring) what's appropriate and/or believing that changing the status is going to change reality. An explanation of when to use or not use WONTFIX is a complicated and nuanced subject that could fill a long page of its own, and it is only partly related to the subject of this page (which is etiquette). "Stop your Wikipedia-style edit warring already: it irritates people and it doesn't work anyway" is a pretty simple concept and IMO definitely belongs here. Whatamidoing (WMF) (talk) 19:10, 27 December 2013 (UTC)

I think there are lessons to be learned from Wikipedia, actually. In particular, BRD applies: marking a bug as wontfix, especially without discussion and appropriate consideration, is a bold action. Anyone who does so should expect quick reversion and subsequent discussion in many (if not most) cases.

Again, simply saying "accept decisions" is a bad idea in my opinion. It isn't appropriate for me or anyone else to simply accept the wrong decision. If anyone, Wikimedia Foundation staff, volunteer, passerby, or otherwise inappropriately marks a bug as wontfix, it should be reopened. And conversely anyone can mark a bug as wontfix iff that's the appropriate action to take. I think the discussion about authority and code maintainers and such only serves as a distraction. The purpose of Bugzilla is to try to ensure that good ideas are queued until properly resolved and that bad ideas are appropriately marked as unacceptable as a reference for posterity. --MZMcBride (talk) 00:15, 28 December 2013 (UTC)

Is there such thing as a lead developer inappropriately marking a bug as WONTFIX? I thought it was kinda like how in the theology of certain religions, you can't argue that anything the deity does is unjust, because the deity sets the standard of what justice is. So, if the deity says "Kill all people who fall into category x" that is automatically considered just, because how will you argue such a matter, or anything else, with the entity that has power to destroy you? Same concept here; the authority figures at WMF ultimately decide who has access to Bugzilla, Gerrit, etc. so how will we say anything they do is inappropriate? Leucosticte (talk) 00:43, 28 December 2013 (UTC)

The deities analogy really isn't helpful. --MZMcBride (talk) 16:33, 28 December 2013 (UTC)

The argument remains: If Developer-in-Charge says "I don't care what you think, I don't care if you write it, that feature will only be deployed over my cold, dead body", then what's "wrong" or "inappropriate" about the Developer-in-Charge telling people his decision (i.e., marking it WONTFIX) and what's wrong with us telling people not to edit-war over the nominal bug status? What's wrong with us telling them, "If Developer-in-Charge marked it WONTFIX, then it really is WONTFIX (for now), even if you edit-war over it to make it falsely appear to be "open"—and if you believe that the Developer-in-Charge is wrong about this decision, then you need to spend however many hours it takes to change his mind, rather than spending five seconds every day to make the bug status field tell lies, until you get kicked off Bugzilla for edit-warring"? Whatamidoing (WMF) (talk) 18:39, 28 December 2013 (UTC)

If Developer-in-Charge's decision to mark a bug as wontfix is the appropriate decision, there's nothing wrong at all with marking the bug as wontfix. But if you look at how Bugzilla is actually used, you can see various cases over the years of bugs being marked wontfix by senior-most developers (such as Brion V. and Tim S.) that were subsequently reopened and then eventually resolved/fixed. I personally have filed bugs that have been marked wontfix, marked bugs as wontfix, or reopened bugs marked as wontfix. I'll apologize for the boldness, but this point is apparently still getting missed: it doesn't matter who marks a bug as wontfix, it only matters whether that's the appropriate action to take.

I don't think anyone is advocating edit-warring, however if Developer-in-Charge inappropriately closes a valid bug, of course it should be reopened. No developer, however senior, is infallible. And while I generally agree with you that wontfix means "we'll never accept patches for this, so stop asking," the reality is that circumstances change. Off-hand, consider bugzilla:11190. This is a bug about adding in-browser chat for individual talk pages and it's currently marked as resolved/wontfix. I personally marked it as such in 2008 and Max S. (who coincidentally now works for the Wikimedia Foundation) marked it again as such about two years later in 2010. At the time, both of us were fairly convinced this was never going to happen. Fast-forward to 2013 and it seems that we were probably wrong and that our cold, dead bodies may be irrelevant: for better or worse we'll probably see in-browser chat in 2014 or 2015. Should people edit-war over the status of that bug report? No, we should seek to minimize conflict on all of our projects (wiki or otherwise), all of the time. But does that mean that it's appropriate to simply "accept the decision" that it will never be fixed? Of course not. It likely will be fixed!

We must focus solely on whether a particular bug resolution is appropriate. We should generally be blind to who is making such a decision because that is generally irrelevant: Bugzilla isn't an exercise in government. Bugzilla resolutions are not about determining ultimate authority and who's "in charge." Bugzilla is about capturing and queueing valid ideas.

If you watch how very smart people such as Brion and Tim interact with Bugzilla, you'll notice very little edit-warring and I don't believe either have ever banned a non-spam account (unlike Andre). Please consider why this might be. --MZMcBride (talk) 00:20, 29 December 2013 (UTC)

I'm more concerned with the process for dealing with a WONTFIX that I disagree with, than with the end result. I assume that in the end, the right decisions will be made. So let's say that someone—someone who is actually responsible in some signficant way for that area, so that person's viewpoint matters in practice—closes a bug as WONTFIX. I happen to disagree with the decision. That person may be fallible; I may be fallible. Should I:

(a) immediately re-open the bug,

(b) post a rant in the comments about how that person hates The Community™ and ought to be fired, and/or

(c) leave the bug status alone for now and instead try to persuade this person (or other people), in a w:How to win friends and influence people manner, possibly using a public mailing list or a relevant talk page here (so that others can join without irritating uninterested people with bugmail), that the wrong decision was made? Whatamidoing (WMF) (talk) 20:40, 30 December 2013 (UTC)

(un-indent) This is a false trichotomy. In any case, you'd probably want option a or possibly option c, though the latter will likely lead to the former. That is, let's say bug X gets marked wontfix and you disagree. Rather than simply re-opening the bug (iff that's the appropriate action to take) following option a, you instead e-mail others following option c, and one of those others then re-opens the bug. You've just wasted more time of more people and achieved exactly the same result. --MZMcBride (talk) 00:53, 2 January 2014 (UTC)

You are making the unwarranted assumption that I'm right, or even that I can reliably tell which one of us is right. It's flattering of you to think so, but let's deal with reality:

I file a bug report. Someone else (who, in my case, very likely knows more than me about this) says absolutely not—WONTFIX.

We do not know which one of us is right. What should I do, given that I do not actually know what the ultimate outcome ought to be? Also, what should we advise people to do, given that a few people are very bad at differentiating between "what I want" and "the objectively right thing to do" (see, e.g., most newbies who get blocked for edit warring on all of the public wikis)?

Think of it this way: We'll say, "If you are absolutely certain that the WONTFIX is a mistake, then re-open it. However, in the many cases when you are somewhat uncertain, you should…" How do you finish that sentence? Whatamidoing (WMF) (talk) 18:09, 3 January 2014 (UTC)

Your self-deprecation is cute.

I suppose I would end such a sentence with "... leave a comment on the bug report with additional information that might change the outcome." Or something like that. However, wontfix is often seen as a definitive (and off-putting) action, so, again, I think it's important to stress when it's appropriate or inappropriate to use. --MZMcBride (talk) 19:40, 31 January 2014 (UTC)

I've got no problem with having instructions (here or elsewhere) about when to use WONTFIX. I only object to excluding this information because the other part hasn't been written yet.

Are you sure that commenting at the bug is (normally) the best approach? The other obvious options are personal e-mail to the person who applied the WONTFIX, or public e-mail to a list (which might attract attention from people who aren't already involved). Whatamidoing (WMF) (talk) 23:41, 8 February 2014 (UTC)

Specific examples

Hah, Bugzilla search is actually quite impressive. It's trivial to find cases of bugs that are currently marked resolved/fixed that were previously marked wontfix. Limited to the "MediaWiki" product, there are 136 such bugs currently. Limited to the "Wikimedia" product, there are 71 such bugs currently. These are both very limited searches, but already we can easily find dozens (if not hundreds) of examples where a bug was marked as wontfix and then ultimately marked resolved/fixed.

If we look at bugs that are currently marked resolved/fixed that were previously marked invalid (as opposed to wontfix), we can see 106 such bugs currently for the "Wikimedia" product and 168 such bugs currently for the "MediaWiki" product.

Hopefully these and other queries provide some food for thought. --MZMcBride (talk) 00:33, 29 December 2013 (UTC)

Briefly looking through some of these bug reports, I see current Board members (such as Sj) and current Wikimedia Foundation staff (such as Matt F. and Brion) re-opening wontfixed bugs and becoming increasingly exasperated at the use of wontfix (cf. bugzilla:218#c25 or bugzilla:1893#c6). bugzilla:218 is particularly enjoyable as it was marked wontfix on three separate occasions and also includes some of Brion's legendary/infamous shouting (cf. bugzilla:218#c31). I wonder what the proposed Bugzilla etiquette guidelines would make of that. ;-) --MZMcBride (talk) 00:52, 29 December 2013 (UTC)

That's exactly why I'm not sure what insight taking a look at numbers of past WONTFIX usage provides. Reopening WONTFIX is nothing bad per se if it's done because of valid reasons (e.g. good new technical arguments), and there are also cases where WONTFIX was used incorrectly anyway. --AKlapper (WMF) (talk) 11:37, 2 January 2014 (UTC)

"Reopening WONTFIX is nothing bad per se" and "there are also cases where WONTFIX was used incorrectly anyway" both sound like very reasonable arguments for not including any "accept decisions" language. --MZMcBride (talk) 04:26, 3 January 2014 (UTC)

I think there is still a valid case for "You can also comment and challenging decisions without changing the status". Mistakes happen everywhere for all involved parties but that doesn't necessarily mean that guidelines couldn't be helpful. --AKlapper (WMF) (talk) 12:05, 3 January 2014 (UTC)

Is there a valid case for "Don't change the bug status as doing so will only antagonize those following the bug report and accomplish nothing" as a guideline? I still don't understand the seeming eagerness to tell people not to re-open a bug without addressing the inappropriate bug closure itself. --MZMcBride (talk) 16:28, 4 January 2014 (UTC)

That requires that the closure was in fact inappropriate. There are enough examples where reopening was merely a sign of protest and disagreement on non-technical grounds (though not necessarily intentional), but numbers for my statement would be hard to gather if you don't want to re-read many reports again... :-/ --AKlapper (WMF) (talk) 19:37, 5 January 2014 (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)

Where there is a right, there must be a remedy. I guess in those cases, people would seek a remedy by reminding the devs, "The Bugzilla etiquette page says that you have an obligation to do x"? Leucosticte (talk) 07:59, 22 December 2013 (UTC)

I doubt it. The closest document on the topic is probably +2, "+2 rights may be removed if: you've repeatedly merged bad code [...]". --Nemo 08:27, 22 December 2013 (UTC)

I don't necessarily mean an obligation in the same way as a right. More of a moral obligation. Being deficient in such responsibilities should not come with a punitive penalty, but simply a loss of the moral high ground. I also mean that it would be inappropriate to say "We have no obligation to fix your bug", if the bug was all Wikimedia sites are down for all users. Bawolff (talk) 08:53, 22 December 2013 (UTC)

I think this depends on who "we" is. Does "we" mean "the WMF"? Well, the organization kind of does have an obligation to get its wikis working. That's how the WMF accomplishes its educational mission. Does "we" mean "individual developers"? Then the answer is no: no developer has any obligation to fix any bug (at least, no obligation unless and until his or her boss—who may or may not be a WMF staffer—says, "Fix it or you're fired").

For the purposes of this document, though, which is more like a summary to the first approximation than a detailed explication of every nuance, I think that "no obligation" sums it up pretty well. WhatamIdoing (talk) 19:06, 24 December 2013 (UTC)

Even the organization doesn't really have an obligation to do anything not required by contract, even in circumstances that threaten its existence. It is entitled to fiddle while Rome burns if it wishes. Leucosticte (talk) 19:09, 24 December 2013 (UTC)

There is a difference between moral obligations and legal obligations. WMF is not morally entitled to let Rome burn. Well I agree that individual developers do not have an obligation to anything, the community as a whole does in some things (e.g. security). In a similar way, individual wikipedians dont have obligations, but the community holds it has moral obligations to treat BLPs in certain ways (I think anyways. Not really a wikipedian). Bawolff (talk) 22:09, 24 December 2013 (UTC)

Now that I look closer, I see that section 3 of the bylaws states, "The Board and its Trustees are understood to act as fiduciaries with regard to the Foundation, and their duties include, but are not limited to, the fiduciary duty of care and the fiduciary duty of loyalty, as described in Sections 617.0830 and 617.0832 of the Florida Not For Profit Corporation Act (the Act)." Section 617.0830 states, "A director shall discharge his or her duties as a director, including his or her duties as a member of a committee . . . In a manner he or she reasonably believes to be in the best interests of the corporation." So, contrary to what I wrote above, those at the top of Wikimedia are required to look out for the well-being of the organization.

However, reasonable people might disagree as to whether certain proposals are in the best interest of Wikimedia. Otherwise, people probably already would have sued over some of these bugs. Maybe they could sue and win, though, if the Foundation were to simply let all the wikis stay down and spend all the funds on extravagant board meetings in Key West, Maui, etc. instead. Leucosticte (talk) 23:31, 24 December 2013 (UTC)

Meta discussions

Nemo, you removed this, which I understand, but it probably made more sense before this change. What I was aiming for originally is "don't yell at the dev if you don't like decisions made by the devs' grand-boss. Only yell at the developers about things that the devs themselves have the authority to change".

So, to give a timely example, if you hate the fundraising banners that run every December, then you don't need to change a dev's mind; you need to change the Board's mind, or the Executive Director's mind. No amount of yelling at some poor dev on Bugzilla is going to change a decision that is completely outside that dev's own control. Perhaps you can think of a better way to put this. Whatamidoing (WMF) (talk) 19:41, 26 December 2013 (UTC)

Thanks, I had indeed missed the original wording of that specification. I think that's too complex a concept to express in that section: whether a comment is "directly related" to e.g. declaring the issue's status is tightly connected to how that status is determined, but that's another point of the document (which we need to make clear and cohesive).

Probably it could fit in the point about realism, or in the one about decisions (if/when that's re-added): it's similar to "change that is outside the power of MediaWiki development" (linked above), where we mention upstream libraries but we could easily add things the law forces and explicit decisions taken "elsewhere". Does this need to be in this document or is the other page enough?

As for the first point, perhaps "unrelated to the topic of the report" is a bit too strong and negative. As you say, the appropriateness of the forum depends on the setting and participants being the correct ones: we should find a way to say that "you should write your thoughts where you're more likely to find the people able and interested in hearing, discussing and acting on them". While most discussions happen on mediawiki-l, wikitech-l or wikimedia-l, finding the correct venue for an issue is inherently hard, something that we may want to address here (if you declare bugzilla the wrong venue, offer/suggest an alternative one?). --Nemo 21:26, 26 December 2013 (UTC)

+1 for something like "When it is pointed out that Bugzilla is not the right place, it is recommended to point the commenter to a more appropriate place" so it weakens the potential impression that criticism is suppressed while we're only after redirecting it to a better/right place. --AKlapper (WMF) (talk) 01:33, 27 December 2013 (UTC)

I like Nemo's idea of helping people find the right place, too. Whatamidoing (WMF) (talk) 19:11, 27 December 2013 (UTC)

Hm, we forgot to include this bit. --Nemo 10:08, 5 February 2014 (UTC)

I'm not sure how much level of differentiation is really needed for this very specific case - in case somebody wants to yell at WMF folks, the person might not care if it was the WMF developer or the WMF manager who made a decision that the person highly disagrees with. ;-) I guess I simply don't want too much WMF-specific stuff in this etiquette, as behavior recommendations should ideally apply to anybody, no matter if paid or not. --AKlapper (WMF) (talk) 01:28, 27 December 2013 (UTC)

Thanks for working on this

Thank you to everyone who's been working on improving this. I am happy to see us all helping make Bugzilla a more hospitable place to work. Sumana Harihareswara, Engineering Community Manager (talk) 16:51, 2 January 2014 (UTC)

Seconded. It's a nice document and I think it represents our norms well. --Ori.livneh (talk) 10:27, 13 January 2014 (UTC)

Closing time...

I'd like to thank everybody for the thoughtful and passionate discussion here. I plan to finalize this etiquette by the beginning of next week, assuming that no new major points are brought up. --AKlapper (WMF) (talk) 22:18, 9 January 2014 (UTC)

I personally liked some of the longer versions better, but this will probably do. Here's what's left on my list:

• "Act in public" should probably be qualified with "please don't post sensitive security information until the bug has been fixed"
• We need to directly tell people not to fight over WONTFIXes and priorities, and to provide them with specific, concrete actions they can take instead, ideally including links to suitable mailing lists. This includes three major cases:
  • If you think someone ought to assign more resources to your bug report, so that it is, in reality, a higher priority, then take it up in e-mail.
  • If your bug was marked WONTFIX, and you still think it's a good idea, then take it up in e-mail.
  • Don't hassle the devs over stuff outside their control (e.g., the decision to have a fundraising campaign, the decision to permit unregistered users to edit Wikipedia, the decision to allow people to upload photos from their mobile phones…).

Other than that, it's probably done. Whatamidoing (WMF) (talk) 18:52, 10 January 2014 (UTC)

These are very good points. I must admit that after writing this I also started wondering again if current wording has gotten slightly too vague when it comes to describing expected constructive behavior so my comment here was probably premature and there is still more work to do; especially making clear that maintainers and developers have the last word on what is being done (because that's also what I see in every other open source project). --AKlapper (WMF) (talk) 00:07, 11 January 2014 (UTC)

With the difference that WMF is not an open source project. Although we are preparing general guidelines for the MediaWiki Bugzilla I'm afraid that especially WMF employees (not you personally) are the people who are inclined to exploit such a "last word" rule to resolve bugs in ways the design teams might find appropriate – while ignoring potential community consensus. As long as you don't offer a proper solution for this problem, such a statement should by no means be part of any official MediaWiki Bugzilla etiquette! --Patrick87 (talk) 02:24, 11 January 2014 (UTC)

WMF is not an open source project itself - WMF is a non-profit organization supporting numerous open source projects like MediaWiki. To repeat myself: In the end maintainers of a code repository have the last word. I don't care if they are paid by $insert_random_organization_here or maintaining as volunteers. I don't believe in design by committee as a concept in software engineering. To clarify (this might be the underlying misunderstanding), I don't refer to configuration settings of Wikimedia servers as a codebase. It's not that I want to abolish community consensus or such. :) --AKlapper (WMF) (talk) 13:31, 11 January 2014 (UTC)

Well (maybe that's the underlying misunderstanding in the underlying misunderstanding), often configuration settings of Wikimedia servers are treated as Bugzilla bugs. Design of new features (which are developed for the sole purpose of being deployed and enabled on WMF Wikis) is also tracked on Bugzilla. Bugs and feature requests that only apply to WMF Wikis are also tracked in bugzilla. How should those be differentiated from bugs which apply to the Open Source project "MediaWiki" in general (were community consensus might not always be a criterion)? --Patrick87 (talk) 14:35, 11 January 2014 (UTC)

Configuration of Wikimedia servers (files like InitialiseSettings or CommonSettings which define which extension is enabled on which servers, or namespaces) goes to the Wikimedia product in Bugzilla. New features are in MediaWiki or MediaWiki extensions (slightly simplified) and hence part of the Open Source project "MediaWiki" and its codebase. --AKlapper (WMF) (talk) 19:40, 12 January 2014 (UTC)

Where'd the Spanish Come From?

Hey, does anyone know what the level-two bullet point that says 'para ver un bug resuelto es proporcionar un parche patch ; 2 es una política para la aprobación de proyecto de código' in Spanish means? Shouldn't we translate it to English? I'd do it, but the person who put it there seems to have some issues with Spanish grammar, so I can't really decipher it that well…

RandomDSdevel (talk) 00:45, 12 January 2014 (UTC)

It came from a user either vandalizing or trying out VisualEditor in this change. It has been reverted, thanks to others. --AKlapper (WMF) (talk) 17:06, 12 January 2014 (UTC)

Rename

(AKlapper among others; this is still marked a draft, so I'd like to raise this issue.) I don't like «etiquette» word, it makes a «rules book» impression. Could we please rename to «Bugzilla usage guide», and maybe also merge How to report a bug into this page? Gryllida 09:06, 29 January 2014 (UTC)

Covering which field has which meaning is out of scope, and I am afraid that "usage guide" implies this. Filing a ticket feels also distinct enough from general recommendations on behavior in Bugzilla. I'm against merging, this would become a long text and I might not be interested in how I file a new bug report if I was after finding out what is recommended when commenting on existing ones. --AKlapper (WMF) (talk) 11:04, 29 January 2014 (UTC)

I agree with Andre that a merge is probably not a great idea for now. A rename sounds fine if there's a better title. "Bug management/Behavior guidelines"? --MZMcBride (talk) 20:44, 30 January 2014 (UTC)

I guess we could always create a redirect at some point. Going to https://en.wikipedia.org/wiki/Etiquette I see "For Wikipedia's guidelines on etiquette, see Wikipedia:Etiquette." so it feels consistent (plus also implies "guidelines" instead of "rules" over there). --AKlapper (WMF) (talk) 14:15, 4 February 2014 (UTC)

(AKlapper among others) The intent of the rename proposal was to keep everything on one page in some way. Details on the meanings of bug fields could go to 'Bug fields' section of a 'Usage guide'. A draft here... --Gryllida 05:59, 6 February 2014 (UTC)

I'm mostly missing the Etiquette part on that page - so far it looks like a mashup of https://en.wikipedia.org/wiki/Wikipedia:Bugzilla and https://www.mediawiki.org/wiki/How_to_report_a_bug to me). Anyway, I've written above why I'm not in favor of merging the Etiquette with something else, as technical settings and social behavior are not the same to me. --AKlapper (WMF) (talk) 08:24, 6 February 2014 (UTC)

Requirements for bug reporters

Once a reporter has done their best to respect How to report a bug, is it good manners for a maintainer to demand more from the reporter, like for example that the reporter produce a solution for the report, and failing that close the report? --Nemo 12:43, 28 August 2014 (UTC)

It's not the task of a reporter to propose technical solutions. Actually, initial tickets that only include solutions but don't describe actual problems are an issue in bug management. --AKlapper (WMF) (talk) 13:01, 28 August 2014 (UTC)

Move to Phabricator/Etiquette

This page should be a subpage of Phabricator, listed together with other subpages and their discussions. IMO its name "etiquette" isn't too intimidating, and the kids would not grok an "Emily Postnews" or "Phabby Postbugs" joke. It's also no guideline or policy, unless somebody arranges an RfC on Meta or whatever it takes. IOW, just move this page to Phabricator/Etiquette and be done with it, please. Everybody can still edit it, it's a wiki. –Be..anyone (talk) 04:26, 1 March 2015 (UTC)

Feel free to create a redirect. :) --AKlapper (WMF) (talk) 16:10, 1 March 2015 (UTC)

@Be..anyone and AKlapper (WMF):  Done. Jdforrester (WMF) (talk) 01:27, 2 March 2015 (UTC)

Redirect from B to A isn't the same as move from A to B, but I guess it's good enough, thanks. –Be..anyone (talk) 04:49, 3 March 2015 (UTC)

We have a history of having some pages about a tool (called "Bugzilla" or "Phabricator") and some pages about some of the processes done in or via that tool ("Bug management"). The border is very blurry in some areas but I haven't consider getting an idea of what's best and cleaning it up on mediawiki.org and moving around pages and creating lots of redirects a really great use of my time yet and I guess I never will. :) --AKlapper (WMF) (talk) 09:05, 3 March 2015 (UTC)

Actionable

Feedback from https://etherpad.wikimedia.org/p/Wikimania-2015-Code-of-Conduct : Peter suggested we work to make tasks more clear and actionable, to help new contributors, and avoid issues like duplicates. I think this is particularly important on tasks that a new contributor might realistically consider working on. Mattflaschen-WMF (talk) 21:33, 16 July 2015 (UTC)

Implement a temporary block?

When a user behaves impolitely, they may be warned, and after the final warning their account will be permanently (aka indefinitely) disabled. However, in Wikimedia users will seldom be blocked indefinitely. (The duration of blocks should be related to the likelihood of a user repeating inappropriate behavior.) So I purpose to implement a temporary block in Phabricator. Before Phabricator allowing us to do so, a list of temporary blocked users should be maintained in a page here, and Phabricator admins should unblock the user when the block expires.--GZWDer (talk) 02:16, 4 August 2015 (UTC)

As I've blocked two or three users in Phabricator since November 2014 due to repeatedly ignoring the Phabricator etiquette, I'm happy to follow whatever the community consensus is resulting from this discussion (and I hope I already expressed that in phab:T102577). --AKlapper (WMF) (talk) 06:46, 4 August 2015 (UTC)

I don't have an opinion on how exactly temporary bans should be handled, but I agree that having something between no ban and permanent ban makes sense.--188.77.24.128 15:47, 12 October 2015 (UTC)

Phabricator needs some unblocking and blocking procedures.

Admins need to know when to block and when to unblock.

A user was blocked because he did not follow the rules.

When he asked to be unblocked the admin didn't know where for him to request to be unblocked since this wasent discussed.

There need to be a way for users to request unblocks.

Maybe follow Wikimedia example by if a user is abusive you asked for them stop that if they continue you get block for like two to 3 days if after that 3 day period they continue an admin should have a right to block permantly until he/she agree to stop.

Also spam should be blocked indefinite if you detect or suspect it is a bot.

There needs to be support for when an admin blocks you that phabricator sends an email explaining why you were blocked and how long you decided to block for and including where to go to ask to be blocked.

Paladox (talk) 11:14, 10 October 2015 (UTC)

Google Docs

I keep finding cases where a Phabricator task links a vanished Google Docs item for details. There are some systematic problems with using Google Docs:

• by default things are private to users in the wikimedia.org domain, AFAICT;
• files are bound to disappear, in particular when the user stops working at the Wikimedia Foundation;
• and of course there is no way to find things (no internal links, no categories, no search or lists of documents).

All this is very bad for collaboration and mid-term productivity (first line of the etiquette). I'm not sure where to document the problem, but we should suggest that users:

1. check a document's permissions before linking it (e.g. in a private window), to ensure they match expectations;
2. transfer ownership to some shared WMF account which is not going to disappear, whenever they think the document relevant for others;
3. download any related documents and upload it to a public wiki, when work on the task is completed or stops.

For the second point, someone should find out which wikimedia.org placeholder addresses exist. For the third point, PDF download is ok for archival; but it would be better to archive the "original" in openDocument format.

We can allow ods and odp upload here on mediawiki.org, while for odt it's usually better to just copy ad paste the content in a page with VisualEditor. --Nemo 07:27, 4 April 2017 (UTC)

I agree with all of the above, and I'd also add that google docs is a closed SaaS solution, the use of which comes with pretty serious privacy implications. In fact, while I'm ok accessing the docs with my wikimedia.org google account (it's a work account after all) I could understand if someone wasn't as happy to use their own private Google account to access these documents. I understand people might have reasons to work with a document editor rather than in a wiki, (or, say, that one wants to prepare some slides in google sheets), but things in phabricator should eventually refer to either an on-wiki document, or to something uploaded to commons. GLavagetto (WMF) (talk) 07:38, 4 April 2017 (UTC)

Relation between Phabricator Etiquette and Code of Conduct

Since early 2014 we have Bug management/Phabricator etiquette. Since 2017 we also have a Code of Conduct for technical spaces. This has led me to some questions in phab:T167786 how these two documents influence each other. Your thoughts are welcome in phab:T167786 (so the discussion is centralized in a single place). Thanks in advance! --17:40, 18 October 2017 (UTC)

Based on comments in phab:T167786#3735498 I plan to add one sentence at the very end of the Etiquette for clarification: "In case the disregard can be seen as unacceptable behavior defined by the Code of Conduct, the Code of Conduct committee will be informed." Again, comments are welcome in phab:T167786. --AKlapper (WMF) (talk) 19:23, 4 November 2017 (UTC)

Resolved in phab:T167786#3753457 --AKlapper (WMF) (talk) 21:47, 12 November 2017 (UTC)

Question about thanking etiquette

Hi all. What is the etiquette in Phabricator for thanking someone for working on a task? I'm sorry if this is already documented and I didn't spot it. 198.73.209.241 19:10, 26 August 2022 (UTC)

It's fine (and encouraged!) to thank people. Legoktm (talk) 05:42, 12 November 2022 (UTC)

Page not found: "What_to_do_and_what_not_to_do_in_Bugzilla"

In section => Document inspiration , reference is obsolète => https://developer.mozilla.org/fr/docs/What_to_do_and_what_not_to_do_in_Bugzilla does not exist (neither other generic form *What_to_do_and_what_not_to_do_in_Bugzilla* )

Please correct or remove. Thanks.

Christian 🇫🇷 FR (talk) 13:06, 5 November 2022 (UTC)

Swapped to an archived link. Legoktm (talk) 05:42, 12 November 2022 (UTC)