Wikipedia:Don't demand that editors solve the problems they identify
 | This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
 | This page in a nutshell: Identifying problems is a valid way to contribute to Wikipedia, even if one does not know how to or wish to go the extra mile to solve them. |
Solving problems on Wikipedia often involves multiple steps: first, the problem needs to be identified, then a solution agreed upon, then that solution implemented. Sometimes, an editor will have the technical knowhow, emotional capacity, or simple desire to participate in only one of these stages. That is perfectly okay—this project is a collaborative, incremental effort in which editors can choose to volunteer as much or as little as they wish.
Editors who participate only in the first stage sometimes receive pushback. A maintenance tag you added will be removed with summary "just solve the issue, don't add an ugly tag"; an editor will respond to a brainstorming session on systemic solutions to bias by saying "just go write some articles in the area"; a redlink to a clearly notable topic will be removed, citing Wikipedia:Write the article first. Sometimes the pushback is framed as encouragement to be bold.
This sort of response is inappropriate. Identifying problems is only the first step in resolving them, but it's a vital step, and even if an editor only takes that one step, it's a net positive. They are laying the groundwork for other editors—who may be more qualified to tackle the later steps—to come in and finish the job.
The response is particularly pernicious when it relates to systemic issues. These issues, by their nature, call for systemic solutions: changes in guidance, process, or design. Because Wikipedia operates on such a large scale, even the most prolific contributor would be capable of making only a tiny dent in the issue just by working on it by themselves. Discussions on larger reforms are needed for these issues, and they should not be shut down out of defensiveness about the problem or attachment to the status quo.
Limitations
[edit]There are some instances in which pointing out a problem can be disruptive if done inappropriately. Particularly, it is important to practice responsible tagging and to not tag bomb articles such that the tags become a greater nuisance to readers than the issue the tags are identifying.
You should be careful when identifying problems in areas where you have not worked extensively or with which you are not overly familiar, as these instances are especially likely to provoke defensive reactions. The area's regulars may have relevant expertise about the problem, but you may also bring a fresh outsider's perspective that the regulars have missed.
Some problems are already well-known, and are either beyond our control (e.g. stuck in a Phabricator backlog) or deemed by prior consensus to be a necessary evil (or even not an evil at all). Identifying these issues is okay (especially if you didn't know about the history), since sometimes additional attention can get a task un-stuck, or consensus can change about whether it's worth tolerating. However, do not continue to harp on them beyond the point of usefulness. If editors are constantly pointing out an unsolvable issue in an area where you work, consider writing an FAQ.