It's been almost 2 years since we introduced projects to The Vault, and I think it's time to take a look at what worked, what didn't and what could be improved.

Looking at the list of projects, only 6 (out of 23) have reached completion. A lot of them are dormant or carried by a single editor - of the 6 completed ones, only 3 really were group efforts. So clearly there's some room for improvement.

My goal is to gather other people's thoughts, see whether they perceive the same problems I do and what suggestions they might have, so you're more than welcome to comment ;)

Fundamental principles

Simply put, projects need to be engaging, fun and rewarding. As such, I think the areas we need to work on are:

  • Giving projects clear goals (so people have something to work towards)
  • Directing more attention towards projects (so people notice projects in the first place)
  • Helping people stay up-to-date (so people become engaged and can more easily spot where they can help)
  • Reducing bureaucratic overhead (so people don't waste too much time on documenting what they're doing)
  • Keeping people motivated (so people keep contributing)

Clear goals & focus

Projects need a clearly defined and, most importantly, reachable goal. Some of the current projects can never be completed as they basically concern ongoing maintenance tasks (e.g. The Vault:Bug Verification Project or The Vault:File maintenance project). I think this is not what projects were intended for, and participating in a project which never ends is not very appealing to people as it is not very rewarding.

In addition, such "eternal" projects add up over time, eventually drowning out real projects. As such, I'd require projects to always have a reachable goal. In the same vein, it'd probably be beneficial if we could agree on a period of time after which admins can remove "still-born" projects from the list.

Directing more attention towards projects

To contribute, people need to know a project exists in the first place.

Number of concurrent projects

I think we need to limit the number of concurrent projects. Our editor base is simply not large enough to support more than a few projects, which means that with a lot of projects each one has only a few (if any) contributors. These few contributors then try to handle an enormous amount of work which in turn means most of them burn out sooner or later. Simply put, less is more. Not sure what the appropriate number of concurrent projects would be - up for discussion I guess.

Project spotlighting

Something to consider is designating a "project of the month", where a specific project would be highlighted for - surprise - a month in a prominent location (such as sitenotice, community corner or community portal). The goal is to draw more attention to the project and focus editor activity on it. As a tie-in to achievements, people could receive badges for contributing to the project of the month.

Helping people stay up-to-date

Helping people stay up-to-date makes sure everyone is on the same page and sees where he/she can contribute.

Project talk pages

Few people participate in discussions on project talk pages or even pay attention to them. As a result, not all participants are always up-to-date as far as the project's conventions are concerned which results in frustration and unnecessary workload.

One possibility would be the creation of a "project discussion" subforum, in which all projects could be discussed. If the threads are named properly (i.e. always include the name of the affected project), I think this might help a bit - people are more used to checking forums than checking talk pages, it seems. The related threads could be displayed on the project page.

Recent changes related to project

Project pages could include a "recent changes" feed which only shows pages within the scope of the project, allowing participants to easier keep track of recent project activity.

Reducing bureaucratic overhead

The less time is spent on managing the project, the more time can be spend actually contributing to it.

Project tags & progress tables

Progress tables are, quite frankly, a pain in the ass. Not only blow they up the project pages to gargantuan sizes for larger projects (which means they take longer and longer to load and edit), but they also double the amount of edits project participants have to make - for each article edit, they need to make another edit on the project page just to mark their progress. Not to mention the tables require constant updating when new pages are added to the project. As such, I propose to get rid of them entirely.

Of course, we still need to track the progress made so people can see what still needs to be done and where. As a replacement, I'd expand the function of the project tags (those yellow-ish boxes at the top of pages). Rather than only showing that the page is affected by a project, they could also be used to track the progress - each task would be a template parameter, and once an editor has done a task he/she can simply put his/her signature there. The advantages are obvious - other editors can see what needs doing right on the page itself rather than having to check the project page and it's no longer necessary to edit another page to mark progress.

The template would place the page in (hidden) categories for each task, i.e. either in the category "Task XY completed" or "Task XY not completed". These categories can then be used to track progress for individual tasks and the project as a whole. This is actually a pretty central part of my proposals - a lot of other things I'm suggesting in this blog depend on this change for technical reasons.

Visually, the project boxes would change only slightly. They would show a series of yesIcon check and noIcon cross icons (or a progress bar) depending on which tasks have been completed and which have not, and could be collapsed/uncollapsed to show who has done what exactly.

Participant lists

I think the participant lists are rather useless, to be honest. All too often people who are on the lists do not contribute to the project at all or people who do contribute are not listed. I'd replace them with a short list of people who can be contacted if other participants have questions and be done with it. Less work, less clutter on the project page.

Keeping people motivated

People like progress and people like rewards.

Visualize progress

I believe that visualizing progress could help motivate people. I created a template a while back ({{Progress}}) which displays "percentage of completion"-style bars. These bars could be added to the project page, both for the project as a whole and for specific tasks. With the change to the function of project tags outlined above, the bars would update automatically.

Another benefit of the bars is that editors could more easily see which areas of the project need the most attention and what they can help out with.


As shown recently, achievements are a motivating factor. We should make more use of them for projects, although we'd probably have to consider whether there should be a separate track of achievements for each project or whether there should simply be a general "project" track.

Size of tasks

Judging by the current projects, doing a lot of small tasks is more appealing to editors than doing a few large ones. Tasks like checking images, adding IDs and similar things usually get done rather often, while larger tasks like rewriting article text are far less popular. I think the lesson to be learned here is that we should aim for smaller, more doable tasks in general (by splitting up larger ones).


Looking forward to feedback and other suggestions for improving projects :)