My goal is to create tools to automatically organize backlogs of wiki articles and related tasks (with a focus on Wikipedia and Wikidata). Such tools could be used to track the improvement of a subject area on Wikipedia over time, in the manner of a WikiProject, or to curate a list of articles for an edit-a-thon.
- A user could specify that they want to track all pages in a given Wikipedia category tree, or all articles that are of a given subclass on Wikidata, or any manually defined list of articles. These page indices are called “buckets.”
- An automated process updates these buckets as new articles are written or identified for inclusion.
- Once a bucket is created you can start a “sprint”. Sprints are defined by article tasks and are meant to be defined around a period of time, like an edit-a-thon.
- Buckets and sprints can be tracked on-wiki through the use of bot-updated wiki pages, much like a WikiProject. Once the on-wiki page is set up, a bot takes care of the rest. Through a template call, you will be able to sign up for various reports concerning the scope of articles.
- This service will provide an API for bot developers to integrate these buckets and sprints into their tools.
- You can track existing articles that need improvement, or new articles that do not exist yet.
| Focus tools | |
|---|---|
| A WikiCred 2022 Grant Proposal | |
| Project Type | Technology |
| Author | (Harej) |
| Contact | james scatter.red |
| Requested amount | US$9600 |
| Award amount | Unknown |
- What is your idea?
Outputs of this project including a Toolforge-hosted tool, a data backend with update scripts and an API, and a toolkit for setting up buckets and sprints on-wiki.
Wireframes
Concept art. Designs not final.
- Why is it important?
The Wikimedia projects comprise tens of millions of pages, and approximately as many discussion venues (in theory every article can have its own talk page). If you are improving Wikipedia at the scale of an individual article, you can use the talk page. If you want to improve the entire project, there are project-wide discussion venues. If you want something in between, there are several options that are not very good.
At this time, the prevailing paradigm for organizing on-wiki groups is the WikiProject. WikiProjects are not a software feature of Wikipedia, they are a social feature, developed with the same page formatting and template tools as regular Wikipedia articles. This means if you want to set up a collaborative project on Wikipedia, you need to build the project as you would any other article. Then, you need to tie together various tools and templates. Typically this involves creating an article evaluation template system and category tree which are then used to tag the talk pages of various articles. This requires a lot of upfront and ongoing effort, and leaves a lot of on-wiki clutter which is of minimal value to editors. And this is just the baseline infrastructure. To make the project useful requires more work involving identifying other bots and tools.
In 2015 I embarked on a “WikiProject X” to develop new tools for WikiProjects. WikiProjects are typically organized around subject matters, ongoing events, or types of contributions. The tools I developed through this endeavor are in use by WikiProject Women in Red and WikiProject Medicine, two of the largest projects. There are a handful of other users of the “WPX UI” as well. However, the project fell off from a combination of technical challenges and lack of funding.
For years I have been thinking about how I would do it again. First, I would like to unbundle the concept of WikiProjects. In reality there are multiple different needs.
- One purpose is to broadly organize work around a subject area, which can be as broad as biographies in general or as specific as a single, very notable person.
- I have also seen WikiProjects focused around a particular organization, not concerning the organization itself so much as their participation on Wikipedia. (GLAM WikiProjects fall under this.)
- While not exactly WikiProjects, edit-a-thons (online and offline) function as ad-hoc WikiProjects, a voluntary collaboration to improve Wikipedia, but under finite duration of time. You would think WikiProjects would play a bigger role in organizing edit-a-thons, but often, edit-a-thons are organized completely separately from WikiProjects, especially if there are no active WikiProjects to help. Some WikiProjects, like Women in Red, are effectively ongoing edit-a-thons.
While they are different kinds of collaborations, they have some common needs, like keeping track of pages and tasks related to those pages. Based on this I can build a simple yet extensible data model for tracking Wikipedia articles, Wikidata items, Wikipedia articles that do not yet exist, and projects and tasks organized around them.
The next issue concerns the ease of setting up new projects and customizing them as needed. When I developed the first WPX UI template kit in 2015, I sought to make the experience as turnkey as possible, at the expense of flexibility. Wikipedia editors expect an extraordinary degree of flexibility in how pages are shaped and organized. I have been designing a more nimble templating system that gives you as turnkey or as customized an experience as is wanted by allowing the separation of presentation and content on demand. To this I bring my 10+ years experience building templates and Lua modules. I am also avoiding anything that requires new code to be approved on the wikis, whether it be a MediaWiki extension (which would require ongoing support from the Wikimedia Foundation) or an on-by-default gadget (which would require community approval). Since my focus is on templates and tools that do not require community approval, that should eliminate most sources of friction.
Finally, I want this to be a platform that other tools can use. In general, third-party tools in the Wikimedia ecosystem have to invent a lot of their own infrastructure, taking away time and energy from volunteers to work on more interesting things. Even with the existing WikiProject category system, there is not one simple or convenient way to pull all the relevant data. By creating a system to organize focus areas on Wikipedia with an accompanying API, this will save the time of our volunteer developers by doing some of the work for them. Ordering a bot to produce a report for a given bucket should be as easy as updating that bucket’s configuration.
- Link(s) to your resume or anything else (CV, GitHub, etc.) that may be relevant
- Is your project already in progress?
I have put in around 10 hours of planning work.
- How is this project relevant to credibility and Wikipedia?
There are many groups of people out there trying to make Wikipedia better. WikiCred is one of them. For these groups to coordinate, especially to coordinate with the platform they need to improve, they need tools to track their work and identify opportunities to improve Wikipedia. WikiProjects give us a good starting point, but current WikiProject tooling is not nimble enough for organizing ad-hoc projects, and for organizing larger projects requires significantly more work.
- What is the ultimate impact of this project?
If I am successful we will have a successor system for WikiProjects—including WikiProject membership—that can also be used for edit-a-thons, conferences, and meetups.
- Can your project scale?
I have been designing this project to be wiki-agnostic and language-agnostic. It should be possible to deploy to any Wikimedia wiki in any language. It keeps track of pages individually without reliance on any particular template or category scheme.
- Why are you the people to do it?
I have experience doing product research and prototyping work around WikiProjects and I would like to apply my experience from the last several years to develop the next generation.
- What is the impact of your idea on diversity and inclusiveness of the Wikimedia movement?
Wikipedia is not easy to “get” from the outside. You have to know where to look if you want to find community and not be treated as an outsider. With tools that make it easier to organize a community around a subject matter or task, there should be a more accessible entry point for those wishing to get involved. Part of building a diverse community is making the craft of editing Wikipedia more accessible and less esoteric.
- What are the challenges associated with this project and how you will overcome them?
1. Re-designing the user interface of a website you don’t control is inherently challenging. Thankfully, there have been technical improvements to Wikipedia that make this easier, including TemplateStyles. I have also spent time figuring out how to minimize or eliminate dependency on consensus or approval processes. This means avoiding MediaWiki extensions and on-by-default gadgets.
2. Finding projects/communities to test the code. The two choices here are basically (1) overhaul an existing project (2) work to create new ones. Creating a new project is easy, but then you have to work to keep the project up. You could overhaul an existing project, but there is the risk of an existing workflow breaking. Going by my previous experience with WikiProject X, I think the best approach here is to focus on a relatively small number of test cases (no more than 5) to ensure that their needs are fully met. I would be very happy to collaborate with other WikiCred projects here.
3. Quick success can lead to a scaling issue. I think WikiProject X, to an extent, was a victim of its success. It played a significant role in the launch of WikiProject Women in Red in 2015, and that project went on to become one of the largest on English Wikipedia. Our beta test became our flagship project. Thus I found myself in the position of needing to support a significant and serious project with no more resources than I had to start with. If this works, and this succeeds, further scaling will require additional forms of support. Some ongoing support is built into this grant proposal. To make a business case, you will find that you can support more partners and more projects with the same level of resourcing if you have tools that let you do this work more efficiently.
- How will you spend your funds?
I plan to commit around 120 hours to building the prototype systems and adopting them for 2-5 test projects on Wikidata and English Wikipedia.
- How long will your project take?
I will spend around 2 weeks (or 4 weeks if working part time) on software development and a few hours per week on an ongoing basis to support the deployments.
- Have you worked on projects for previous grants before?
I have received grants from the Wikimedia Foundation before, including grants for WikiProject X and Librarybase. I have also administered multiple grants on behalf of Wikimedia District of Columbia.