Bug management/Development prioritization

This is a high-level essay about software development. It is meant to help understand better how planning works. (It does not and cannot list every single software maintainer's or engineering team's workflow details though.)

Basics
In free and open source software projects like Wikimedia's software projects, all software code is public. A public task tracking system (like Phabricator) is used to manage software bug reports and feature requests. Anyone can report bugs or request features or propose code contributions.

Why has nobody fixed this issue yet?
Individuals, third-party stakeholders (who use Wikimedia software projects for their needs), and members of several organizations (Wikimedia Foundation, chapters like Wikimedia Deutschland or Wikimedia Sverige ...) work on the code of software projects. All of them have their own interests, priorities, goals, motivations. Some developers might write code to "scratch their personal itch", other developers might write code because their organization wants to see a certain functionality in the software.

Many individuals and groups with different interests exists when it comes to activities (readers, editors, translators, documentation writers, developers, media uploaders, designers, ...), roles (stewards, oversighters, admins, ...), preferred human languages and how well these languages are supported in the software, Wikimedia projects interested in, the type of implementation of the software (gadgets and user scripts, modules, templates, code repositories, bots, tools on Toolforge), etc. It is not easy to cover and balance all those different needs of different people and groups in ways which always feel best to everybody.

In theory and in the long run, people and time are unlimited, as more people could start contributing to a project at any time. In practice and in the short run, both people and time are limited resources. Teams organize and plan their work in certain ways, for example as sprints. Adding unplanned additional work to a sprint usually only happens when urgent problems appear.

As the task tracking system is public and anyone can propose anything, the number of ideas and feature requests is usually higher than the number of developers working on them. Some tasks might also be very complicated to fix (software architecture issues where efforts might outweigh gain), considered too risky, or the maintainers consider it out of scope of the functionality that the software should cover. Even if someone wrote and proposed code which implements a feature, there might not be resources to maintain the costs of the additional code in the long run. Adding code adds more complexity: Someone needs to update it when other code that it relies on has changed. Some bugs only happen when a certain combination of options is enabled which makes it harder for developers to reproduce these bugs. Hence there are many tasks which will stay unresolved forever. It is unrealistic to expect all tasks to ever get fixed.

In Wikimedia Phabricator, anyone could set the priority of a task. This can create wrong expectations, as priorities should only be set by those who do the work or own a position to plan work and not by someone requesting work to be done by someone else. Furthermore, not every developer or team necessarily uses the Priority field for their planning – some might prefer using the workboard columns in Phabricator or other ways to plan what's being worked on next. Hence it is not a problem per se that many tasks do not have a Priority set.

If you really want something to be implemented, sometimes the best bet is to provide a software patch and getting it reviewed or to convince someone else (maintainers, developers, external developers) to write that software patch. (Making code review happen can be a follow-up problem though. Code review of proposed patches is out of scope for this essay.)

Why wasn't I consulted about these changes?
With half a billion users, it is not reasonable to expect developers to ask everyone about every change (or even trying to reach consensus). It would heavily slow down any development. The problems of the silent majority and self-selection bias exist, and if you try to apply the most popular opinion by pleasing the most vocal people, you often end up with a wrong answer. Furthermore, future Wikimedia community members cannot express their needs because these people are simply not yet part of our community.

There are several ways to learn about new developments. A lot activity happens and is documented in public:
 * For proposed changes with a major impact on people's workflows, research is usually performed beforehand (for example by running A/B tests).
 * On-wiki consultations take place to make decisions about major software features or new products, often supported by the Community Relations team of the Wikimedia Foundation.
 * Changes with a bigger user-facing impact are announced weekly in Tech/News to which anyone can subscribe.
 * Quarterly Wikimedia Foundation department check-ins focus on the big picture and progress of annual plan goals and other large projects.
 * Many teams have a monthly or sometimes weekly newsletter and/or on-wiki updates page.
 * The Wikimedia Foundation Technology department lists its annual plans and quarterly goals on their wiki page, the Wikimedia Foundation Audiences department lists its goals and annual roadmap on their wiki page.
 * There are regular Research showcases and monthly Tech Talks.
 * People write blog posts about larger or more interesting developments on the Phabricator blog and the WMF blog.
 * If you are sufficiently interested in a specific team, team Phabricator boards are public.

For a Wikimedia Foundation example, see PM'ing in public in which Josh explains the steps performed when planning and working on a new software feature.

How I can influence what is worked on?

 * Write Phabricator task descriptions and comments as clearly as you can. Provide links to examples. Provide links to related documentation and/or discussions. Summarize the details as clearly as you can, and indicate what is still unknown. Explain the scope of the problem so that the developers can determine how it fits into their other plans. Be friendly/polite. I.e. Make it easy for someone to help you.
 * For reporting software bugs: see How to report a bug for more tips.
 * For requesting new software features: Clearly explain the general type of task that you hope the feature will solve (the actual underlying problem) along with a few specific examples; but do not demand a specific solution, as there might be other/better solutions. Provide links or notes on any related software.
 * For software deployed on Wikimedia web sites, the Developers/Maintainers wiki page lists teams and individuals who are responsible per project. Most teams list their communication channels on their wiki pages which allow you to engage, discuss and influence what is being worked on.
 * Take part in on-wiki consultations to influence decisions about major software features or new products.
 * The annual Community Wishlist Survey and its voting results help developer teams identify and prioritize popular technical requests for smaller projects.
 * Provide a software patch that offers the functionality you'd like to see. If you plan to work on a larger software project yourself, Project Grants are available to fund community members.