On Thu, Mar 14, 2019 at 4:36 AM John Erling Blad <jeb...@gmail.com> wrote:
> Google had a problem with unfixed bugs, and they started identifying > the involved developers each time the build was broken. That is pretty > harsh, but what if devs somehow was named when their bugs were > mentioned? What if there were some kind of public statistic? How would > the devs react to being identified with a bug? Would they fix the bug, > or just be mad about it? Devs at some of Googles teams got mad, but in > the end the code were fixed. Take a look at "GTAC 2013 Keynote: > Evolution from Quality Assurance to Test Engineering" [1] > Sorry to be direct but you seem to have little understanding of what you are talking about. You are equivocating different things and shifting goalposts every time you comment on this thread. You are jumping between various positions involving "a large bug backlog is bad", "important bugs are not getting prioritized accordingly", "the WMF should scale its services down so it has the capacity to respond to every request" (ie. fire some developers, hire more community liasions), and now you are talking about broken builds. Every time someone challenges your claims, you just switch to talking about another one. This is frustrating and a waste of other people's time. Please try to pin down what you are trying to propose before making the proposal. For those unfamiliar with development processes, a broken build means the application is not starting at all, which means other developers cannot test their own work, which means the entire development process grinds to a halt. That is a huge hit to productivity so software organizations usually try hard to avoid it, even though it's an internal issue with no user impact (well, other than the organization shipping less features / fixes in the next release because developer time was spent less effectively). The closest equivalent we have for that is continuous integration tests broken by merged code (although that's less severe since it usually doesn't stop the application from working). While I'm sure the handling of those could be improved (incidentally, that's just happening, see https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG ), it has nothing to do with the original topic of this thread, since it is happening in the development cycle and not visible to users. About backlogs in general, Chromium is probably the biggest open-source Google repo; that has currently 940K tickets, 60K of which are open, and another 50K have been auto-archived after a year of inactivity. (As others have pointed out, having a huge backlog and ruthlessly closing tasks that do not get on the roadmap are the only two realistic options, and the latter does have its advantages, no one here seems to be in favor of it.) We have 220K tasks in total, 40K of which are open, so that's in the same ballpark (not that that comparing open task ratios is particularly meaningful - but it hopefully shows that Google's handling of the completely unrelated build breaking issue does not magically make them have zero bugs). What if we could show information from the bugs in Phabricator in a > "tracked" template at other wiki-projects, identifying the team > responsible and perhaps even the dev assigned to the bug? Users who are interested in that information would be spared the enormous effort of pressing a button on the mouse, I guess? > We say we don't want voting over bugs, but by saying that we refuse > getting stats over how many users a specific bug hits, and because of > that we don't get sufficient information (metrics) to make decisions > about specific bugs. Some bugs (or missing features) although changes > how users are doing specific things, how do we handle that? > How many people vote on a bug and how many people are hit by a bug are two entirely different things, and most of the time it's hard to measure the latter. Voting will be dominated by power users who are more engaged with the development process, users who understand English, users who come from a larger wiki community and can canvass better, etc. (And Phabricator doesn't support voting anyway.) > What if users could give a "this hits me too" from a "tracked" > template. That would give a very simple metric on how important it is > to fix a problem. To make this visible to the wiki-communities the > special page could be sorted on this metric. Of course the devs would > have completely different priorities, but this page would list the > wiki-communities priorities. > Having a page which lists the priorities of wiki communities (more realistically, one specific wiki community) would be very useful, IMO. As others have pointed out, the reason no such list exists is that people are spending their time complaining here, instead of building lists on their wiki. (At which point they would quickly find out that actually getting a consensus on priorities is a lot harder than complaining about why everything is not being worked on at the same time.) Various people have done various priority lists in the past, some of which have been fairly successful in directing attention. It's definitely worth a shot doing the same for the community you intend to represent. Voting is not a serious replacement for that, though. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
