Wikipedia:Community feature requests

The following is a draft working towards a proposal for adoption as a Wikipedia policy, guideline, or process.
The proposal must not be taken to represent consensus, but is still in development and under discussion, and has not yet reached the process of gathering consensus for adoption. Thus references or links to this page should not describe it as policy, guideline, nor yet even as a proposal.

This idea is in the brainstorming stage.
Feel free to add new ideas; improve, clarify and classify the ideas already here; and discuss the merits of these ideas on the talk page.

Community feature requests is a continual system for voting on feature requests, much like the m:Community Wishlist Survey but not held once a year - always open to voting.

View a list or category of feature requests

Getting started edit

Place a short but descriptive title after `Wikipedia:Community feature requests/` in the search box below

Scope edit

Despite being hosted on English Wikipedia the scope of the project includes feature requests specific to other projects like Commons and Wiktionary, eg a "Tags system for Commons, with interlanguage support" is Commons specific but may have implications for Wikipedia (eg allowing powerful intersection). "Add audio pronunciation" button may be a common Wiktionary request but it could also exist beneficially on Wikipedia articles.

There are four main types of feature requests:

Feature requests requiring Mediawiki software development (eg Global watchlists)
Feature requests requiring non-Mediawiki software development (eg Toolforge tools)
Feature requests not requiring software changes, changes that only require admin intervention etc (eg Add 'Open Access' tickbox to RefToolbar)
Bug reports. Which should be filed on Wikimedia's Phabricator but are acceptable in this project as voting could be helpful and editors may not like to file bug requests in a foreign environment.

Implementation edit

Each request would sit in its own subpage, just like Dark mode, with description of the problem, proposed solution and benefits followed by discussion and voting.

To display the results a table like this could be generated on Toolforge every hour - ranking the feature requests by number of support votes (for example like the "Current leaderboard" here). Alternatively a script (eg pywikibot) could be developed to create a daily list saved to Wikipedia:Community feature requests/Report.

Categorisation edit

Admins and patrollers; Anti-harassment; Bot and gadgets; Citations; Editing; Miscellaneous; Mobile and apps; Multimedia and Commons; New contributors; Notifications, Watchlists and Talk Pages; Reading; Search and Categories; Translation; Wikidata; Wikisource; Wiktionary.
WikiProjects may also have categories to help them keep track of requests: Disambiguation; Help Project; ...
Main types: Mediawiki software change; Other software change; No software change; Bugs.

Status edit

Status of each request will include: Open; Resolved; In progress; Duplicate.

It is very unlikely that a feature will get archived/closed. Even something like "Allow IPs to edit the Main page" may seem ridiculous and would surely get rejected at the Village pump, but perhaps what the proposer is hinting at is a system to allow anyone to edit the page waiting for admin review, instead of going through the rigmarole of Main Page Errors. This feature would also streamline the Edit requests process. Leaving features open also allows for votes to be garnered over time which may align with changing community consensus.

How to add a feature request edit

Keeping the title as simple as possible:

Create a subpage (eg at Wikipedia:Community feature requests/Dark mode)
Fill out the description of the Problem, Proposed solution and Benefits
Add categories
Sign after Proposer and Save

Alternatively, if you are short on time you can simply post the idea on the talk page and hope that someone fills out the subpage for you. Or keep a list in your userspace for formal addition later (eg).

Applications edit

Volunteer developers will be able to see a list of feature requests and pick out a simple one to work on
The WMF will be able to survey the feature requests and form plans for MediaWiki development
New readers/editors will be able to see key limitations and work around them. Eg if you see Global watchlists as a highly voted feature request then you know you may need to download a user script or set up Watchlist bookmarks in your browser

Participate edit

List of participants edit

Below is a list of editors interested in maintaining and supporting this project.

Interested in feature requests for en.wp, en.wiktionary and Commons.--Commander Keane (talk) 20:48, 23 January 2024 (UTC)[reply]

To do edit

Migrate open (not resolved or in progress items) from:
Trawl the Community Wishlist Survey archives (eg) for good ideas that were rejected
Invite other projects like Commons and Wiktionary to submit feature requests
Invite WikiProjects also
Add milestones section (if there are any for this project)
Add top ten features list to the top of this page
Get the message out about what we are doing to encourage more votes and requests
Add more feature requests!

Why edit

Advantages of a continual system edit

No need to wait for a yearly event, vote any time, think of features any time.
Another resource. For example the feature of turning links to disambiguation pages orange (link) may go unnoticed for some users - it is not mentioned in the FAQ for example. But if they go to make a feature request they will discover the new feature already exists. And if they file a duplicate we know to update the documentation/FAQ.
The Wikimedia Foundation development team can browse the features, in order of popularity, at any time.

Problems with the existing Community Wishlist Survey edit

m:Community Wishlist Survey already exists and a future tool is under development.

Caveat: please note that the new Wishlist system will probably be awesome. It may replace Community feature requests entirely, in which case requests from this project can be migrated to the new system.

Problems include:

Take the Wish Add 'Open Access' tickbox to RefToolbar for example. It was rejected by the Wishlist Survey as it doesn't require engineering resources. True, but it is still a legitimate feature request that can actually be fixed by English Wikipedia admins if consensus allows.
It is on hold. Not taking place this year, instead a new tool is being developed. The new tool may be vaporware and it may not be suited to what the community wants.

On Meta? edit

Should the project be on Meta or English Wikipedia?

Advantages edit

A common place for all feature requests means less duplication. For example a feature like "Global watchlists" applies to all wikis, not just English Wikipedia.
Little wikis (like obscure language Wikipedias) will struggle to get attention to their own list of feature requests but joining a central system would be better.

Disadvantages edit

Users may be less likely to visit a foreign wiki to discuss/vote. They may not monitor their Meta watchlists.
Better number of editors on English Wikipedia may mean better dealing with vandalism, running the Report etc.