This is a Big Project for WikiProject X to fulfill several goals of the IEG renewal.
The problem: current WPX UI (the new WikiProject design developed by WikiProject X) is based on obscure Lua modules and templates.
- This is difficult to implement on each project and places the maintenance burden on very few people who are proficient in templates and Lua.
- Reliance on wikitext templates makes it difficult to internationalize the interface, limiting its usefulness outside of English-language Wikipedia
- WikiProject module setup and bot deployment are completely separate, requiring a change to an obscure configuration page in order to enable an automated worklist.
Solution is to develop an extension. These are the features of the extension:
- New content model for WikiProject pages, with the layout based on the WPX UI and focused on intuitive inclusion of standardized and customized "modules." Edit window would present a customized edit form, with the option of selecting between pre-registered types of reports (new discussions, suggestbot, etc.) and allowing people to create custom modules.
- One-click option for joining project as a member, which will facilitate optional notifications via the Notifications system.
- Automatically surfaced metrics, including WMF global metrics, for activity of project members. Also metrics for work done to articles that are featured on the WikiProject page, and tracking participation rate on the project and on articles in the project's scope.
- Definition of WikiProject scope within the project page itself, eliminating the need for project banners (they would still be allowed; just not required).
- Lower priority: new streamlined assessment system, making use of the page assessment table (T117142). This would be accompanied by a transition tool that would allow WikiProjects to migrate from template-based assessments to the new system. (Assessments living in both this tool and in the templates would cause conflicts, and it is not feasible to have the extension edit template calls directly.)
Implementation will largely be through ContentHandler with an editing interface that is built on top of the schema in T120928. This extension is focused on presentation; the content of the project will continue to be populated through human- and bot-curation. This allows extensibility by being built on top of wikitext pages, rather than trying to replace them. This also allows third-party bots to easily create reports for WikiProjects. Since bots will read the WikiProject pages as JSON, it functions as a configuration for that project. (e.g. SuggestBot looks for WikiProjects that feature the Suggestion module, and makes edits to the Suggestion subpage accordingly). At first, all the modules will be wikitext pages, but in the future this could be other content models.
- While WikiProject-type terminology is used throughout this document, this is useful for any situation where users are interested in collaborating together on a set of articles, potentially making use of automated worklists. This tool could be used by edit-a-thons, education programs, etc.
- It is not our intention to require people to use this. The goal is to design a compelling product that sells itself and is used in situations where it is deemed useful. Accordingly, if a change to the product would help encourage broader adoption, it should be considered. But we cannot require everyone to use this for collaboration when we cannot assure this will cover every possible use case.
- It should be possible to revert from this novel content model to the default wikitext content model.
- Does this meet the needs of Wikipedia editors? Need to review WikiProject feedback and to actively consult with Wikipedians, including those who do not use WikiProjects.
- Should this content model live in a separate namespace, or should it be in the project namespace (i.e. ns 4) and switched on/off as needed? Pros and cons to both approaches.