Wikipedia:WikiProject X/Requirements documents

This page details the different products and product components for WikiProject X, as established by the Product Development Priorities.

General requirement: All software developed for WikiProject X must be licensed under the MIT License or a compatible license.

Project Universe

Note: This is already complete.

The "Project Universe" is an automatically updated WikiProject directory featuring metrics for each project and a "similar projects" function. These features work together to provide an comprehensive understanding of the current WikiProjects.

This requires:

• A script that prepares the directory, including WikiProject-related metrics that will also be saved in a database (for future longitudinal study) and a list of project participants (filtered according to certain criteria)
• A Tool Labs web application that presents lists of users that are active in editing the project's scope and space (as defined below)
• A Tool Labs web application that presents lists of related WikiProjects for each WikiProject. The report itself should be generated each month. Each report will be linked to from the directory.

Code must be posted to the wikiproject_scripts Github repository.

Directory

This will largely be derived from the existing ProjAnalysis script, which computes a list of users editing in the project "space" (i.e. the WikiProject page, its talk page, and the subpages) and the project "scope" (i.e. the pages that are tagged by the WikiProject) but with the following changes:

• Change version number to 2.0
• Adapt for the pywikibot module, including conversion from Python 3 to Python 2.
• The script itself is a collection of functions meant to be invoked through a separate execution script. This was when analysis was only done on an arbitrary sample of WikiProjects. Now the goal is to do it on all of them. Get list of WikiProjects through this specific API query (somehow this guy figured out how to get an exhaustive list of all WikiProjects) and have the script gather information for all of them.
• Script currently populates list of project "scope" pages through the WikiProject template. This is problematic because some WikiProjects have dispensed with their own project-specific templates in favor of getting a line on another project's template. Instead, rely on the WikiProject's category. Assume the category has an identical name to the WikiProject; if such a category does not exist, do not run project "scope" analysis. Go as many levels deep into the category tree as needed to get a list of in-scope articles.
• Script currently studies revisions in the fixed time range of 20140301000000 to 20150228235959. Change it to a rolling thirty day period, i.e. UTC midnight of that day minus 30 days. If possible, have the project "space" analysis run on a rolling 90 day period instead.
• Script explicitly excludes me, Harej, from analysis. This was when I spammed a bunch of WikiProjects—twice, no less—and I did not want that affecting the analysis. I do not expect that to be an issue now.
• For project "scope," limit it to ns 0 and ns 1. (In this case, no need for the set comparison that filters out the project "space" pages from the project "scope" pages)
• Replace API queries with relevant database queries (to improve performance)
• It may improve performance if, for each page you query revisions on, you also get a list of the other WikiProjects the page is categorized under. This way, a page that belongs to both WikiProject Foo and WikiProject Bar won't need to be polled twice: first when generating the report for WikiProject Foo, and then again for WikiProject Bar.
• Add limiting criteria: a user is not a project "scope" editor unless they made at least 5 edits in the area in the rolling 30 day period, nor are they a "space" editor unless they made at least 2 edits in the project space as defined above in the rolling 90 day period. This filters out random editors who are unlikely to have an interest in the project or its subject area.
• Instead of saving this information to a CSV, get the counts of number of scope-editors and space-editors (filtered by criteria) and save it to a database (one entry for each time the script is run) and to the directory page(s) on-wiki. As for the lists of usernames themselves, save that somewhere for the benefit of the user list application described in the following section.

Each directory entry should include the name of the project, Articles in Project's Scope, Subject-Area Editors This Past Month, and Active WikiProject Participants. For projects where project "scope" analysis is not run due to a lack of category, return an emdash ("—") for articles in project's scope and subject-area editors this past month. The entry should be in the form of a template, e.g. {{directory entry|project|stat1|stat2|stat3}}. The goal is to separate data from the presentation of data; the template code will include relevant formatting and styling code. For context, each entry will look something like this.

Directory entries should be saved to an "all entries" page and also to different sub-directories. The sub-directories should be derived from the category tree following Category:WikiProjects by topic. The immediate sub-categories of that category get whole pages (currently Culture WikiProjects‎, Geographical WikiProjects, Humanities WikiProjects, Science WikiProjects‎, Society WikiProjects‎, Technology WikiProjects‎, and Wikipedia WikiProjects‎, but this should not be hard coded into the script in case this changes). Sub-categories of those categories get sections on those sub-directory pages. Duplication is fine; some WikiProjects belong to more than one category, and this should be reflected. There will probably be some sloppiness with the sub-directories, given that WikiProject categories are not well maintained, but this will improve with time as the category structure is clarified and improved upon. At first, make each page generated a subpage of User:Harej/WikiProjects.

This script will be run every week, as governed by crontab.

User list app

This takes the lists of usernames generated by the above and presents it for the benefit of editors looking for editors who share their interests. The data should be populated through the process used to generate the directory as described above.

• Each WikiProject gets a page. The application should feature an index page listing all the lists, but the most likely entry point will be through the on-wiki directory.
• Present two separate lists: one for subject-area editors, and another for active project participants. Rank by number of edits.
• Give an easy option for "universal opt-out" from being presented in the application. Their data will still count toward the totals, since it's public information; this would let people opt-out of having their name displayed by this application in particular
• Styling should be done in accordance with the MediaWiki living style guide
• If possible, have an option to serve the same data over an API. This will help facilitate third party reuse of this data

Related Projects

This script, which will run every month, will use set theory to generate lists of WikiProjects that are similar to any given WikiProject.

For each WikiProject, get a list of articles in scope for that project through that WikiProject's category. Then, for each WikiProject, compare it to the others and determine which projects have the highest overlap in scope. Get the ten projects with the most overlap, and present in a report for each page.

As with above, each project gets a page, and there should be an index listing all the projects, but most likely people will be entering through the on-wiki directory. Styling should be done according to the MediaWiki living style guide, and the data should also be served over an API if possible.

WikiProject design

The WikiProjects themselves will consist of various modules which appear on the description page and subpages.

The main components are likely to be as follows:

Introduction

A general introduction for new users/random passerby. Needs to be short enough that they might actually read it; a canned template may or may not be best.

Should cover in most cases:

• Scope
• Project purpose
• Goals/target milestones for the project (if any)
• Anything relevant about the subject itself (expanding on the scope)

Discussion

Discussion is a key part of wikiproject function. Aside from the usual talkpages, sometimes more formal processes are also used:

• RfCs regarding the topic/project
• Dispute resolution
• Nomination processes for contests, quality assessments, importance, etc
• More talkpages

Need something that can adequately link to any/all of these, preferably with some sort of activity indicator.

Noticeboard

Place for announcements for various large-impact things/events. Most projects currently just use talkpages for this. As a separate thing, it would still probably work to include them as a 'sticky' thing on the talkpages as well.

Noticeboard announcements can potentially be anything, but may include the following:

• Local/regional Events
• Contests
• Important news
• Press coverage affecting the project

Tasks info

Perhaps the most important part of the project after the members. A good chunk of why the things exist in the first place.

Will likely be compressed into various lists (displaying short versions on the main page, with full lists of things to do on their own pages) and alerts.

Lists:

• User-added requests (article creation, images, attention/expansion, peer reviews)
• Automated lists (either based on templates (cleanup etc) or other metrics (suggestbot etc))
• Article alerts (afd, afc, rfcs, new articles, unreferenced blps, requested edits, dispute resolution needed, etc)

Resources

Various resources maintained for and by the project. Will likely mostly just be a list of links to guideline pages and various tools.

Likely resources include the following:

• guidelines and conventions (layouts, mos)
• lists of relevant journals, maps, referencing info, scientific peer review
• local tools (recent changes, gadgets, user js, sandboxes, special page stuff)
• external tools (bots, catscan, external links, active pages, readership metrics, active pages, traffic statistics)

Meta objects

• Tools for editing/changing all the other stuff
• Lists of members and task forces (if any)
• Related projects, on other projects, related chapter stuff, event stuff
• Related wikiprojects (parentage, subprojects, related projects)
• lists of covered articles, topics, categories
• maintained portals, templates (awards, banner, barnstars, invite)
• accomplishments (showcase, spotlight, metrics, featured articles, lists, dyk, etc)
• assessment data

Inroads and project creation

ProjectTags and ProjectPing

ProjectTags is a proposed lightweight alternative to individual WikiProject banners. It emphasizes simplicity over features and project-level customization. It is intended to be used by new WikiProjects and WikiProjects that do not need any additional banner functionality beyond the article assessment functions. It will use Lua to allow an unlimited number of projects to be represented.

Design should be based on User:Harej/ProjectTags. Each project entry should be the name of the project, the quality rating, and the importance rating. Icons used for quality should use a switcher such as User:Harej/ptb. There is no currently agreed upon way to represent importance/priority in the design. Each icon/symbol should link to the respective category, such as Category:FA-Class African diaspora articles or Category:Top-importance African diaspora articles. The parameters are:

• projectX= The name of the project without namespace prefixes. Example: WikiProject African diaspora Required field.
• qualityX= The quality class of the article. Example: fa Default is "?"
• importanceX= The importance assessment of the article. Example: mid. Default is "?".

X in each parameter refers to each given project. For example, if a ProjectTags instance includes two WikiProjects, the parameters would be project1, quality1, importance1, project2, quality2, and importance2. A Lua module would loop through all of these until all the listed projects are presented. This will allow an unlimited number of projects to be represented.

At the bottom of the template is a button to message all of the listed WikiProjects, powered by a default-on gadget. The purpose of this button is to make it easier for editors to seek assistance from these WikiProjects regarding an editorial matter. Clicking this button should prompt a JavaScript popup window designed through OOjs UI. This box will give people a form with two fields: a section name (also used as the edit summary), and a message contents box. The default value for the section name field should be "Help requested on [talk page name]." Clicking the "send message" button will send a message to all the WikiProjects as defined in parameters project1, project2, ..., projectN. Script should have some way of telling whether it is sending a message to a Flow board or a traditional talk page. Hide button for users who do not have JavaScript enabled or do not have the gadget enabled.

Project Builder

The Project Builder deploys the new WikiProject design to each WikiProject on an opt-in basis. It also serves as an adjunct to the ProjectTags template, allowing either a one-time population of a WikiProject's scope or a continuous update as new articles enter the project's scope. This would most likely be a Tool Labs tool, designed using OOjs UI and with authentication through OAuth, or it is a Python script where the options are defined through wikiproject.json.

The wizard would work like this:

• What is the WikiProject's name?
  • If the WikiProject does not yet exist, great! If it does, the user is told they are going to overwrite an existing project and that they should have consensus to do so first.
• Through which category or categories should the project be populated? For each category row, offer autocomplete options. Also specify options for how many levels of recursion, with 0 for indefinite recursion.
  • Ask if they want the bot to continuously update which pages are in-scope for the project as new pages are added to the categories in scope. In other words, if a page is newly sorted into Category:X, and that category is part of the WikiProject, should the bot tag that page?
• Quality Rating Inheritance: Should this bot inherit the ratings used by other projects, or should the project undertake its own independent quality assessment? (in the event of a conflict, no quality rating is registered.)

This proceeds results in a new WikiProject (or re-design of an existing WikiProject), new evaluation categories (work with existing WP:1.0 bot?), and automatic tagging of that WikiProject through ProjectTags. If the user signed up for this, the bot would also scan the categories at a monthly interval for new articles and tag accordingly.

Worklist generation

Part of the new WikiProject experience includes automated worklist generation. We require a script that will generate these worklists based on a set of criteria.

Each bullet point represents a sub-page of the WikiProject page; each sub-page will be transcluded into the main WikiProject page. Run each script weekly.

This will not be done for every WikiProject, but for those that specifically sign up. Bot should do it for each WikiProject listed on wikiproject.json where worklist_generation is set to true or where individual worklists are enabled. (Refer to the in-file schema.)

• Article assessment to-do
  • Generate random list of five articles that need quality assessment, and five articles that need importance assessment
  • Link to article assessment thing on Tool Labs (specifying un-assessed articles for that project) for people who want to do more than the five listed
• LanguageTool links
  • LanguageTool is an online application that suggests grammar fixes to articles. The URL to check a specific article takes the form http://community.languagetool.org/wikiCheck/pageCheck/index?url=ARTICLE+NAME+HERE&lang=en
  • Find ten random articles in the category "[WikiProject name] articles" and subcategories, with which to generate a list of URLs.
• Image requests
  • For WikiProject banner templates that have the imageneeded parameter, generate a random list of ten articles that need images
  • For WikiProject banner templates that do not have imageneeded parameter, or WikiProjects that use the ProjectTags template, find the intersection of Template:Image requested transclusions and entries in the category "[WikiProject name] articles" and subcategories. Then, choose ten at random for a list.
• Dusty articles
  • For entries in "[WikiProject name] articles" and subcategories, generate a list of the ten articles that have gone the longest without being edited

Not ready yet:

• Article Request Workshop lists
  • Wikipedia:Article request workshop is an experimental structured list of article requests; the space gives editors an opportunity to "workshop" proposed articles until such a time as they are ready to be created. Unlike e.g. Wikipedia:Requested articles, each article gets its section, which is in MediaWiki terms a Topic-namespace page (for more information see Wikipedia:Flow). This allows, essentially, section-level categorization, which allows a single entry to be shared by multiple WikiProjects. Each entry also has a triage template to allow rejecting requests and clearing requests for further development, which facilitates the development of specialized worklists. (Note that entries that correspond to existing articles are automatically tagged as "article live" and drop out of the article request workflow).
  • Based on entries in the category "[WikiProject name] article requests", generate a random list of five entries that require triage and a random list of five that are under development.
  • Link to page that gives instructions on triage. (TO DO)