You don't have to be for-profit to have a self-sustaining business model. But you do have to have a problem (or a need), with a solution, that customers are willing to pay for to solve. Even if you give the software away for free, is that the entire solution to the problem? On Fri, Mar 8, 2019 at 10:20 AM Dennis During <dcduring(a)gmail.com> wrote:

On Fri, 2019-03-08 at 20:03 +0200, Strainu wrote: {{Citation needed}} andre -- Andre Klapper | ak-47(a)gmx.net https://blogs.gnome.org/aklapper/

Yes, I've seen a lot of cookie licking. It makes it hard to solve even simple bugs.

A customer, by definition (https://en.wikipedia.org/wiki/Customer) exchanges something of value (money) for a product or service. That does not mean that a freemium model ( https://en.wikipedia.org/wiki/Freemium) is not a valid business model. However, if there is no exchange of value, the person consuming the free version of the product or service, is not (yet) a customer. If MediaWiki is the thing we give away for free, what do we charge money for? Are our customers successfully subsidizing our free (as in beer) software? On Mon, Mar 11, 2019 at 7:33 PM John Erling Blad <jeblad(a)gmail.com> wrote:

Regardless of definition-related issues, I concur editors' most shared/fundamental needs deserve being addressed spending some money. Vito Il giorno mar 12 mar 2019 alle ore 11:50 John Erling Blad <jeblad(a)gmail.com> ha scritto:

For whom is the backlog a problem? On Tue, Mar 12, 2019 at 4:36 PM Pine W <wiki.pine(a)gmail.com> wrote:

Andre, good points, thanks. I think that this ties in with my comments regarding having a common situational awareness. I don't think that I have good situational awareness regarding the state of the backlog, the composition of the backlog, etc. I'm confident that there is a backlog and that there are tasks in that backlog which I would like to see solved, but it's difficult to get a sense of the big picture. Pine ( https://meta.wikimedia.org/wiki/User:Pine ) On Tue, Mar 12, 2019 at 9:13 PM Andre Klapper <aklapper(a)wikimedia.org> wrote:

On Tue, Mar 12, 2019 at 10:29 PM Bartosz Dziewoński <matma.rex(a)gmail.com> wrote: Sorry, but what I said initially was "bugs with know fixes and available patches". It could be some "major issues", but I have not referred to any one, and I'm not sure it is wise to start discussing specific issues.

What frustrates me the most are - bugs found by the editor community, that has obvious simple fixes, which isn't acted upon for several years - new features that isn't fully tested, and you have to answer in the community about stuff you rather want to throw out - new features and changes that are advertised but never implemented The first one is perhaps the one most easily fixed. I believe WMF could set up either an official bug squad, or use bug bounties to speed up fixing of bugs. I tend to believe bug bounties works best, but it would be really nice to know that bugs are handled in an orderly fashion by a bug squad. When introducing new features make a help page at Meta or Mediawiki, and link to the page from the feature. On that page make a visible link "Don't panic!" and link to the issue tracker. Don't expect the users to figure out which extension provides the specific feature, they don't have a clue. For all important issues make an estimated fix time, and if no one works on the issue say so. Don't assume the users understand fancy wording about "need volunteer". Need volunteer for what? Making coffee? Some features are described in Phabricator, which is fine, but some of them has extensive cookie licking which could give someone the impression that you actually will implement the feature. That often leads to users asking about the feature, and when it will arrive at their project. When it does not arrive users gets upset. If you are working on something, say it, but also be very clear if something has gone into you personal freezer. On Tue, Mar 12, 2019 at 9:35 PM Pine W <wiki.pine(a)gmail.com> wrote:

On Sat, 9 Mar 2019 at 11:26, Strainu <strainu10(a)gmail.com> wrote: Almost all of them, they just keep it secret. Companies pay millions of dollars each year for support packages, even after having paid for software in the first place, specifically because otherwise their support issues may not be answered in a timely fashion, or even answered at all. I don't think comparing us to commercial products makes much sense in this context. I don't agree with shifting responsibility onto the Wikimedia Foundation. There's an anti-pattern here: we all have a big mailing list discussion, agree there's a problem, agree that the Foundation should solve the problem, then ask again in a year what they did even though they didn't actually say they'd do anything about it. That's not a healthy dynamic. The technical space is owned by all of us, so if we, as a technical community, decide this is important to us, then we can look at the problem and try to tackle it, and then figure out how the Wikimedia Foundation could catalyse that. Dan

Dan, Thank you for your response. I appreciate far more someone disagreeing with me than someone ignoring me :) Let me start with a simple question, to put the references to wmf into context. You keep talking below about volunteer developers and how they can take over any project. While that's true, how many fully-volunteer teams are there? How does that number compare to the number of wmf teams? Am I right to assume the ratio is hugely in favor of wmf teams? Note: teams, not developers, since decisions on project management are usually done at team level. Pe sâmbătă, 9 martie 2019, Dan Garry (Deskana) <djgwiki(a)gmail.com> a scris: In my experience in b2b contracts they don't keep it a secret, they usually have SLAs they respect, but ok, let's leave it at that. Responsibility for what? Developing and hosting MediaWiki? Helping communities concentrate on creating and attracting content without having to work around bugs? I'm sorry, but that's precisely one of the responsibilities of the wmf and this is what's discussed here. This is one thing that we agree on: nobody committed on anything. Ever. That's why I asked above: what does it take to have someone (anyone) at the WMF act upon these discussions? My role in the Wikimedia tech community is tech ambassador above all else, so I'm caught in the middle here: I have to explain new features and technical decisions to people who don't care about php, js or server performance , but I also feel obligated to relay their requirements, as I see them, to the development team. This second process does not happen as smoothly as it should. It's not healthy to ignore discussion after discussion and claim it's a community issue. It's not. It's a governance issue and it's growing every day. The projects belong to the community at large, not just the technical subcommunity. They are the ones affected by the bugs and also they are the ones that need our support. So why should they be ignored in taking this decision? My proposal is to begin the discussion here: how can we better relay issues that are more important to communities than new features? How can we have a "community whishlist for bugs"? Cheers and a great weekend to everyone, Strainu

Regarding: Well fundamentally it starts with making a list. This is basically a lobbying discussion right. People think WMF should do more of X. Lobbying discussions are more successful the more specific they are. Having a list of the top 20 worse bugs is something you could convince people to do something about. Even something like /WMF spends too much time on new features and not enough time on maintenance/bug fixing/, is something you could convince people to change, if you for example knew how much time WMF currently spends on bug fixing, and you have an idea of how much time you think they should be spending. Even if management doesn't agree with your proposal, it would at least be specific enough to debate. When these discussions start from vague places, like there's too many bugs, is when they go nowhere. Even if WMF stopped everything else it was doing, and worked solely on bugs, I doubt they would fix every bug in existence. (We can't all be TeX!), and attempting to do that would be a bad idea. Change happens when stuff is measurable, and people can work towards a goal. Failing that, change happens when people can be held accountable. Objective measures are needed. -- Brian On Sat, Mar 9, 2019 at 10:31 PM Strainu <strainu10(a)gmail.com> wrote:

Re reading this now on the ground in Austin, reminds me not to send emails in a hurry from an airplane! So trying again - hopefully more grammatically sound this time! The Tech Engagement team (which includes Wikimedia Cloud Services) in the Tech department is investing in a developer advocacy team who I hope will (amongst other things) speak on behalf of the communities that are affected by tech debt. All the best, Victoria

According to https://wikimedia.biterg.io/ that does not appear to be the case. Or is there some other metric that is more accurate? On Sun, Mar 10, 2019 at 6:33 PM Zppix <megadev44s.mail(a)gmail.com> wrote:

On Wed, Mar 13, 2019 at 11:02 PM Strainu <strainu10(a)gmail.com> wrote: There's something called code stewardship [0] and there is a process called code stewardship review for projects that are under-, un- or unclear maintained [1] which basically a piece of code either gets undeployed from WMF infra or we find maintainer(s) to fix the bugs. You can find the list of current and past reviews in [2]. If you think a project doesn't have enough maintainer, you can start the review process. If there's an active maintainer [3] but they are not fixing bugs, most importantly critical bugs, you can raise the issue probably here but with **concrete examples.** [0]: https://www.mediawiki.org/wiki/Code_Stewardship [1]: https://www.mediawiki.org/wiki/Code_stewardship_reviews [2]: https://phabricator.wikimedia.org/project/board/3144/query/all/ [3]: https://www.mediawiki.org/wiki/Developers/Maintainers -- Amir

În joi, 14 mar. 2019 la 01:02, Amir Sarabadani <ladsgroup(a)gmail.com> a scris: I'll rant about UW in a separate thread, right now I just want to mention that [3] presents 3 possible maintainers for it, **none of which did any work on UW in the last 6 months** (and presumably much longer) according to Phab timelines. I know documentation is hard, but this feels a lot like a wild goose chase. Strainu

În joi, 14 mar. 2019 la 22:23, Gergő Tisza <gtisza(a)gmail.com> a scris: That's an overstatement: 18% (not counting bugs closed as declined) is almost double to 11%. If you're going this route, we're doing much worse than Chromium. I'm 99.9% sure the wishlist is relevant in at least half the categories (Admins&patrollers, Bots&Gadgets, Editing, Notifications, Programs&Events, Watchlists, Wikidata, Wikisource, Wiktionary) and very likely (80%) also for Anti-harassment, Categories and Maps. I'm not sure how you arrived at the $2M figure (even 36 months of dev time - 18 teams, 2 man-months/team - only add up to ~$400K, unless Glasdoor is waaay off on the salaries there [2]), but presumably going down on the list will also surface bugs and not only features, which will take less time to solve. Investing an additional 1% of the revenue into this seems reasonable to me. [2] https://www.glassdoor.com/Salary/Wikimedia-Foundation-Salaries-E38331.htm I did not claim (or asked) that it was. What I said is that it is an important part of the infrastructure and that it should be maintained properly. I also said I will try to come up with a more detailed critique later on and see if it has any result. Strainu

În sâm., 16 mar. 2019 la 15:55, David Barratt <dbarratt(a)wikimedia.org> a scris: Maybe, maybe not - I'm not familiar with Drupal development, but precisely because of the fragmented contributions, chances are some bugs fall between teams. As discussed previously in the thread, MW development is much more centralized, so better coordination is to be expected. That being said, their org stats are pretty awsome, is there any way to obtain similar stats from Phabricator/Gerrit (at least by email domain if nothing else)? A large backlog by itself is not alarming. A growing one for components deployed to WMF sites is. It indicates insufficient attention is given to ongoing maintenance of projects after they are no longer "actively developed", which in turn creates resentment with the reporters. I've checked the burnup graphs Andre referred to for some of the extensions with high editor visibility (UW, VE, CX) and they all have a similar pattern - huge increase in the first ~12 months after being widely deployed, then a much reduced, but visible, growing rate, with some sharp decreases which correspond to a peak in activity (new team culling the backlog? volunteer developer solving a few bugs?). I tried to compare that with the overall pattern, but Phabricator timed out - if somebody could obtain and publish the overall burnup rate data somewhere, that would be great. I guess the question is what's an acceptable backlog growing rate (key secondary question: for who?) and if it is different between projects. I don't know how to respond to that.

On Fri, Mar 15, 2019 at 9:25 AM Strainu <strainu10(a)gmail.com> wrote: I have a hard time imagining that anyone would be upset that 18% of our tasks are open but would be fine with that number being 11%. A hundred times more is significant difference. 60% more, not really. I just wanted to point out that open bugs being about one magnitude less than total bugs is fairly normal for an opensource project (possibly closed projects too, it's just harder to find data there). Just to have some more data points: Firefox has 1.4M bugs, 140K are open; Debian has 140K active and 800K archived bugs; PHP has 77K bugs, 37K of which are closed; Apache has 47K bugs, and 5900 open ones (including LATER). I'm not sure how you arrived at the $2M figure (even 36 months of dev I used $200K per year as a rough guesstimate for the total cost of one man-year of development (which includes salary, taxes, benefits, office space, event participation costs, salary for administration and management which has to scale up with the number of developers...), which I think is on the low end (for a mostly Bay Area based organization, anyway). Also one month of a team's time is something like 5-6 months on average. Anyway, the point is that we are talking about fairly large amounts of donor money here, which should be spent responsibly. Taking community feedback into account is important, but it's not the only thing that needs to be taken into account (one should consider how much it impacts contributors who are for some reason less likely to speak up; how much it impacts readers; future maintenance costs; how well it matches current capabilities; how well it fits the roadmap; how it compares in importance to strategic priorities; etc). The wishlist (or voting in general) is not an ideal tool for that. IMO one opportunity for improvement there is having a list of bugs which are relatively easy to fix (so people can work on them in their free time or 10% time) but relatively important to (some group of) editors. There are plenty of developers interested in working on tasks like that. But curating it would not be a trivial effort. (I tried something similar with the developer wishlist two years ago (except it wasn't limited to relatively small issues, which I think is the main reason it wasn't very successful); that took something like six weekends if I remember correctly. Granted, it wasn't done in a particularly efficient manner, plus, some of the infrastructure had to be invented.) I did not claim (or asked) that it was. What I said is that it is an Are there any components for which that is not true? At a glance none if the 2019 wishlist requests involved UploadWizard, so it does not seem like the most pressing concern on editors' mind. And strategically, doing structured data storage first and fancy contribution and display features afterwards is a whole lot easier than going the other way (something we learned at our own expense with MediaViewer). On Sat, Mar 16, 2019 at 8:23 AM Strainu <strainu10(a)gmail.com> wrote: It really doesn't. The backlog is the contact surface between stuff that exists and stuff that doesn't; all the things we don't have but which seem realistically within reach. As functionality expands, that surface expands too. It is a normal process. (We do have projects which are basically unmaintained. Those are not typically the ones producing lots of new tasks though, since most relevant issues have been filed already. And realistically the choice is between having poorly maintained components and having far less components. Would undeploying UploadWizard, for example, reduce resentment? I don't think so.)

Hi, First, I'll respond to Scott's comment that " A secondary issue is that too much wiki dev is done by WMF/WMFDE employees (IMO); I don't think the current percentages lead to an overall healthy open source community. But (again in my view) the first step to nurturing and growing our non-employee contributors is to make sure their patches are timely reviewed." I'll make a distinction between two types of proposals: a, Offload development work from WMF onto volunteers, and b, Grow and support the population of developers.. The first type of proposal is likely to get a cold reception from me, but I'm more supportive of the second. I don't know how many non-Wikimedia organizations which use MediaWiki software have staff that contribute in significant ways to WMF in the forms of software, time, or money, but growing the significance of those contributions sounds like a good idea. I also like programs such as GSoC and Outreachy, and for WMF providing support for volunteer devs who create tools, bots, etc. on their own initiative. Second, returning to the subject of technical debt, my understanding was that WMF staff were concerned for years about the accumulation of technical debt, but in this thread I get the impression that WMF staff has changed their minds. Am I misunderstanding something? If the consensus opinion among the staff changed, how and why did that change happen? Thanks, Pine ( https://meta.wikimedia.org/wiki/User:Pine )

On Mon, Mar 18, 2019 at 10:52 PM bawolff <bawolff+wn(a)gmail.com> wrote: To set degree of ickyness you need a stakeholdergroup, which is often just the sales department. When you neither have a stakeholder group or sales department you tend to end up with ickyness set by the devs, and then features win over bugs. Its just the way things are. I believe the ickyness felt by the editors must be more visible to the devs, and the actual impact the devs do on bugs to lower the ickyness must be more visible to the editors.

On Tue, Mar 19, 2019 at 12:53 PM bawolff <bawolff+wn(a)gmail.com> wrote: The devs is not the primary user group, and they never will be. An editor is a primary user, and (s)he has no idea where the letters travels or how they are stored. A reader is a primary user, and likewise (s)he has no idea how the letters emerge on the screen. The devs are just one of several in a stakeholder group, and focusing solely on whatever ickyness they feel is like building a house by starting calling the plumber. A sales dep is in contact with the customer, which is a primary user of the product. If you don't like using the sales department, then say you have a support desk that don't report bugs. Without anyone reporting the bugs the product is dead. Actually this is the decade old fight over "who owns the product". The only solution is to create a real stakeholder group. Not going to answer this, it is an implicit blame game

On Tue, Mar 19, 2019 at 3:49 PM John Erling Blad <jeblad(a)gmail.com> wrote: The devs are just one of several in a stakeholder group, and focusing Nobody claimed they were. In fact, everyone said the opposite. I think you're just misunderstanding the definitions of the words being used(?) Well lets make it explicit - If you want change, but refuse to say what change (whether that be structural or whether that be specific bugs you want fixed) then it is 100% your fault that the change doesn't happen. Complaining people/orgs won't change but not saying how you want people to change is just a waste of everyone's time. Developers are people not telepaths. -- Brian

On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman < d.j.hartman+wmf_ml(a)gmail.com&gt; wrote: Yeah. Having tech debt is never great but what gets people concerned is when it just grows and grows, and management dismisses concerns because it is always more important to have the next feature out quickly. We used to have a bit of that problem, but IMO there have been lots of positive changes in the last two years or so, and there is now a credible organization-wide effort now to get debt under control (mainly looking at the Platform Evolution program here). Having the core platform team also helped a lot, and in my impression some other teams that had in the past focused on fast feature iteration have also been given more space to do things right.

I think the entire software industry would prefer to have that, but as far as I know, that type of measurement does not exist. On Wed, Mar 20, 2019 at 4:23 PM Pine W &lt;wiki.pine(a)gmail.com&gt; wrote:

Pine, please see the exact (quite precise) definition of https://en.wiktionary.org/wiki/technical_debt https://en.wikipedia.org/wiki/Technical_debt https://martinfowler.com/bliki/TechnicalDebt.html I.e. Technical debt is Not at all equivalent to "bugs". The topic is a tangential one. Software can work perfectly fine for end-users even if it has a lot of "technical debt", it is just a pain for developers to change anything in it or connected to it because the code has complex issues (it's a mess, or imperfectly architected at a higher-level, or "icky", or other factors). It is not possible to measure, and is somewhat subjective in nature. Overall this thread is going in circles, and I recommend dropping it here. There are several good suggestions above if anyone wants to put effort into actual solutions.

It is a strange discussion, especially as it is now about how some technical debts are not _real_ technical debts. You have some code, and you change that code, and breakage emerge both now and for future projects. That creates a technical debt. Some of it has a more pronounced short time effect (user observed bugs), and some of has a more long term effect (it blocks progress). At some point you must fix all of them. On Thu, Mar 21, 2019 at 11:10 PM Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: I don't think this will be solved, so "move on" seems like an obvious choice.

Wikimedia Foundation is not even in the top 100 non-profits in the United States: https://www.forbes.com/top-charities/list/ Money is relative. On Sun, Mar 24, 2019 at 10:34 PM Nathan &lt;nawrich(a)gmail.com&gt; wrote:

Sorry, but this is not valid. I can't leave this uncommented. Assume the article is right, then all metrics would be bad. Thus we can't find any example that contradicts the statement in the article. If we pick coverage of automated tests as a metric, then _more_ test coverage would be bad given the article pretense. Clearly there can be bad tests, like any code, but assume the tests are valid, would increasing the coverage be bad as such? Clearly no. Pick another example, like cyclomatic complexity. Assume some code controls what or how we measure cc. If we change this code so _more_ code is covered by CC-measurements, then this would be bad given the articles pretense. Again clearly no. Yet another one, code duplication. Assume some code measure code bloat by a simple duplication test. Testing more code for code bloat would then be bad, given the article pretense. Would all code duplication be bad? Not if you must keep speed up in tight loops. So perhaps you may say a metric for code duplication could be wrong sometimes. Measuring code quality is completely valid, as is measuring article quality. The former is disputed, but the later is accepted as a GoodThing™ by the same programmers. Slightly rewritten; "Don't count me, I'll count you!" On Thu, Mar 21, 2019 at 7:07 AM Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote:

On 2019-03-09 12:25, Strainu wrote: In my experience WMF teams usually have a way to distinguish "bugs we're going to work on soon" and "bugs we're not planning to work on, but we'd accept patches". This is usually public in Phabricator, but not really documented. For example for VisualEditor, if a task is put in the "Freezer" or "External" columns on the workboard [1], then we're not planning to work on it. I know other teams use a similar system, but the workboards were created independently by every group and have various differences. [1] https://phabricator.wikimedia.org/project/board/483/?hidden=true -- Bartosz Dziewoński

It seems like some projects simply put everything coming from external sources into deep freezer or add "need volunteer". If they respond at all. In some cases it could be that the projects are defunc. On Mon, Mar 11, 2019 at 9:51 PM Stas Malyshev &lt;smalyshev(a)wikimedia.org&gt; wrote:

Yes, there should always be a response to all bugs. Without a response the impression in the reporting wiki-community would be "nobody cares about our bug reports". Someone in the community finds a bug, and it is posted and discussed in the community. Then another one writes a report in a task at Phabricator, but nothing further happen. A couple of months later the first one ask again about the bug, but does not get a satisfactory answer, and gets angry. This usually happen in cycles of a few months to a year. We must somehow break those cycles, they are bad and disruptive and creates a "us and them" attitude. Users from the wiki-communities don't visit Phabricator to see all those small administrative tasks, they see the notes from the official and unofficial tech ambassadors, and they see the changes in the "tracked" templates. The templates are only changed when the bugs are closed for whatever reason, which could take years. Creating additional manual interventions does not work, the process must be simpler and more efficient. On Thu, Mar 14, 2019 at 1:23 PM Andre Klapper &lt;aklapper(a)wikimedia.org&gt; wrote:

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, March 14, 2019 3:56 PM, David Barratt &lt;dbarratt(a)wikimedia.org&gt; wrote: Yes. Frustration, mostly. It is not entirely unexpected that this message originates from @wikimedia.org.

Hi! Would a canned "thank you for your feedback, please stay on the line, your call is very important to us" response make anybody feel better? The reality of a project with huge userbase and limited resources is that there are more bugs that can be addressed seriously and substantially, not with a canned response that does not solve the issue, than there's developer resource. It doesn't mean "nobody cares about the bug reports" - it means some bug reports will be cared for first and some later (and possibly some, unfortunately, never). This set of priorities can be influenced by alerting developer's attention about specific bugs needing addressing, and by existing prioritisation processes, which very much include community input, but the harsh reality of having a lot of bugs dictates that giving serious non-canned attention leading to satisfactory outcome to 100% of them is IMHO not realistic. We could of course institute the policy of "every bug should have a comment from a developer within X time" - but unless X is very large, I think it will be unsatisfactory, since getting "yes, it's a very important bug, thanks for submitting it" comment without the bug being fixed is IMHO no better than getting no comment at all. -- Stas Malyshev smalyshev(a)wikimedia.org

On Sat, 2019-03-16 at 04:52 +0000, Pine W wrote: What does "understanding" imply; which understanding do you lack? It's hard to help understand without knowing what's specifically missing. :) Which specific problem do you think would be improved by reports? Not sure if it's what you're after: There are Burndown charts. Example: https://phabricator.wikimedia.org/maniphest/report/burn/?project=PHID-PROJ-… or in Phlogiston. For more information, see https://www.mediawiki.org/wiki/Phabricator/Project_management#Scrum_in_Phab… Can you explain why a "larger view" would solve a problem and which problem that is? It's probably not 'some bugs will never get fixed'. Maybe it's 'some tickets don't get a reply'. Maybe it is 'some tickets should get prioritized differently'. Or maybe something else. These are different things... For the records, that would require excluding feature requests from any statistics. Plus definitions and understanding of tech debt differ. Plus tech debt can also be "TODO" code comments and many other things. If something happens on an individual ticket, someone communicates that in that ticket. Examples: People move some tasks on workboards, people assign some tasks, people add some comments. What exactly is missing? Do you have an example that's not abstract high-level, please? :) It's still unclear to me which actual underlying problem(s) you'd like to get solved. The message seems to mix several things ('no reply to some tasks', 'some tasks might get replies but not fixed', 'some tasks should be prioritized differently' etc) but maybe I misunderstand. andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

This is like an enormous sinkhole, with people standing on the edge, warning about the sinkhole. All around people are saying "we must do something"! Still the sinkhole slowly grows larger and larger. People placing warning signs "Sinkhole ahead". Others notifying neighbors about the growing sinkhole. But nobody does anything about the sinkhole itself. I doubt this will be fixed. John

On Wed, 2019-03-13 at 21:01 +0100, John Erling Blad wrote: And repeating the same thing over and over again while repeatedly ignoring requests to be more specific won't help either... andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

On Thu, 2019-03-14 at 12:35 +0100, John Erling Blad wrote: Hmm, why is this thread called "Question to WMF" instead of "Question to developers"? Basically: Because you did not fix these bugs. Longer version: https://www.mediawiki.org/wiki/Bug_management/Development_prioritization {{Citation needed}}. If that was the case: Because your priority was to write code for a new feature instead of fixing an old bug. Longer version: https://www.mediawiki.org/wiki/Bug_management/Development_prioritization Not really - I see 60000 open bug reports in Chromium, for example: https://bugs.chromium.org/p/chromium/issues/list (Only if you want to imply that only "Google" was responsible for fixing all bugs in that free and open source project, of course.) Feel free to extend https://www.mediawiki.org/wiki/Template:Tracked I disagree. Different people see different priorities. Longer version: https://www.mediawiki.org/wiki/Bug_management/Development_prioritization It does not, because software development is not a popularity contest: https://www.mediawiki.org/wiki/Bug_management/Development_prioritization Voting would create expectations that nobody will fulfill. Cheers, andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

On Thu, Mar 14, 2019 at 4:36 AM John Erling Blad &lt;jeblad(a)gmail.com&gt; wrote: 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_Future… ), 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 Users who are interested in that information would be spared the enormous effort of pressing a button on the mouse, I guess? 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.) 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.

Hi and thanks for joining the discussion! On Sat, 2019-03-16 at 20:37 -0400, Thomas Eugene Bishop wrote: I fully agree. I was referring to bug reports in my emails. Code review is an area in which Wikimedia is very frustrating. There are regular emails about patches by new contributors awaiting review [1] but that obviously only covers a small group of contributors. And while we recently started to have code stewardship reviews [2] to fill some gaps in the list of responsible persons and teams [3] per code base, we for example still lack meaningful statistics how big the code review problem is, in general and per team. andre [1] https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091632.html [2] https://www.mediawiki.org/wiki/Code_stewardship_reviews [3] https://www.mediawiki.org/wiki/Developers/Maintainers -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

On Sun, Mar 17, 2019 at 2:38 PM C. Scott Ananian &lt;cananian(a)wikimedia.org&gt; wrote: I find this argument strange, as it imply there is some kind of magical difference between contributions from an employee and a community member. There are no such difference. Both the employee and the community member should take responsibility for the code base, but that does not imply they should take the same actions on that code base.