Grants talk:IdeaLab/WikiProject management suite

From Meta, a Wikimedia project coordination wiki

Historical development[edit]

Origins of WikiProjects[edit]

The entire concept of a WikiProject was developed as an afterthought of a project to put Wikipedia on CD for distribution to places without Internet access. See Wikipedia:Version 1.0 Editorial Team for details. The CD project has become moot with the widespread adoption of cell phones and WikiProject infrastructure is now used for community management, but it has never been updated accordingly for this new purpose. Blue Rasberry (talk) 12:13, 22 January 2014 (UTC)[reply]

Monthly pageview counts[edit]

en:User:Mr.Z-bot is able to create and maintain lists of pageview statistics for WikiProjects like Wikipedia:WikiProject Birds/Popular pages. However, this tool is not supported and no new users may use it. Traffic reports have not been very interesting to the Wikimedia movement's most publicized outreach projects, but to some other projects like medicine, these numbers are critical for encouraging and recruiting contributors. Blue Rasberry (talk) 12:17, 22 January 2014 (UTC)[reply]

👍Like Absolutely, seeing the pageview stats is a big motivator, and certainly could be a tool for WikiProject Editor Retention. Djembayz (talk) 03:12, 16 February 2014 (UTC)[reply]
I'm always surprised how little pageviews are thought about. I'd put them on every article's talk page... EdSaperia (talk) 09:54, 11 March 2014 (UTC)[reply]

Edwardsbot and MassMessage[edit]

Until October 2013 en:user:Edwardsbot managed on-wiki messaging of any large number of users. After that time MassMessage took over this function. It would be useful to have some interface connecting MassMessage to WikiProjects so that messages could be sent to members of a WikiProject. Blue Rasberry (talk) 12:20, 22 January 2014 (UTC)[reply]

WikiProject Council[edit]

The en:Wikipedia:WikiProject Council has hosted years of discussions of how to use WikiProjects, along with complements and complaints about various aspects of them. Anyone thinking of developing WikiProjects should read all the archives. Blue Rasberry (talk) 12:21, 22 January 2014 (UTC)[reply]

Wikipedia Education Program[edit]

The en:WP:Wikipedia Education Program encourages collaboration between students and Wikimedia projects. There is an interface in which participating classes can be monitored by anyone interested. There should be some way to associate classes with a WikiProject. Blue Rasberry (talk) 12:27, 22 January 2014 (UTC)[reply]

Meetup infrastructure[edit]

Whether in-person or virtually, sometimes communities of Wikipedians meet up to voice chat, video chat, IRC, or drink coffee or tea together in meatspace. WikiProjects should have some functionality for setting up and making a record of meetups as currently maintained in en:WP:MEETUP. Practically all meetups right now have some affinity for some WikiProject, but there are not currently tools connecting the concepts. Blue Rasberry (talk) 12:33, 22 January 2014 (UTC)[reply]

WikiProject setup wizard[edit]

There is some basic functionality which all WikiProjects need and there ought to be a base template. At a minimum, WikiProjects should have a landing page which tells new visitors how to interact with the WikiProject. See

for some discussion of this. Blue Rasberry (talk) 12:38, 22 January 2014 (UTC)[reply]

LT910001[edit]

Great idea, Bluerasberry. This would make a big difference to what I feel a the majority of active and long-term users of Wikipedia. I'm in the process of revitalising WP:ANATOMY, and as you know we have been recently created the Society & Medicine taskforce, so I have some insight into this issue. I'll contribute more at a later date, but at the moment just write a little about my experiences creating and revitalising these, and where opportunities for automation exist:

1. Creating[edit]

Creating a taskforce requires listing it, creating a project page, and creating the template.

  • Problems: few.
  • Improvements: These could all be automated.

Taskforces are a very useful way for a project to categorise its subpages. In Anatomy, for example, we are beginning a subcategorisation scheme based on the type of Anatomy of articles (gross anatomy, neuroanatomy, microanatomy, ...). Users with experience in one field can contribute appropriately.

  • Problems: getting the template to work is extremely confusing
  • Improvements: this could easily be automated, and documentation improved and provided on a single project page

The project page must then be created.

  • Problems: time consuming and finicky. Making the project page is not editing articles, which is what most editors want.
  • Improvements: provide a standard template for projects (discussion, to do, guidelines, article alerts) that can be customised later.

Adding articles to taskforces and the project is the next step. A variety of methods are used, eg. random encounters, keywords, and inter-wiki links. Thankfully I haven't had to start a project from scratch.

  • Problems: (1) unless you have the chance encounter with a Rater user, you have to update articles by editing the talk page manually. (2) unless you are familiar with how to code Rater javascript, you have no way other than manually of updating the taskforce pages. (3) when starting a new project, there is no way to batch add articles, which would be very useful.
  • Improvements: (1) Rater tool is provided on preferences. (2) Adding taskforces to rater javascript is automated at taskforce creation (3) articles may be batch added at taskforce or project creation Example: create WP:MED and add all articles with 'physician', 'doctor' or 'nurse' in the title; create a taskforce and add articles already under WP:MED and WP:BIO to that taskforce

The next task when creating a project or taskforce is to get the assessment statistics working. This requires creating a variety of categories to rate an article by class and then finding the assessment table and getting it to work (still not sure how that is done, luckily other users knew).

  • Problems: very time-consuming
  • Improvements: categories could easily automatically be created at taskforce/project created. The assessment table could be moved under the WP management suite of tools

2. Maintaining - user interest[edit]

Right, so we have a project and now we want to maintain it. This has two components. 1. Maintaining user interest in project. In WPANATOMY and WPMED, focus is given on maintaining an active talk page, and greeting new users with welcome templates. Goals are stated and then progress is displayed on task-bars and monitored at monthly intervals. Users participate in decision-making and the creation of guidelines about articles under the project's aegis.

  • Problems: (1) there is no supported archival system.
  • Improvements: (1) Have a globally-supported archival system that doesn't have a bus factor of one. That is, when the Mizabot server or user retires from Wikipedia, or is subject to another unfortunate event, the entire system fails. (2) Provide a standardised welcome-user template with the project suite (as with the project template on tagged pages) that may be used. (3) Goals could be entered through an automated interface or project management page, and progress monitored.

Multilingual collaboration may be possible, and important particularly for national wikiprojects. Users are also encouraged to note their interest on a registry. This allows members to be contacted for their opinion on decisions, as well as dissemination of project materials

  • Problem: the registry becomes quite useless after 2+ years, as it often becomes filled with inactive and/or blocked users. There is no way to send a newsletter other than manually.
  • Improvement: create a registry of users, and divide users into those who have made > 1 edit in the last 6 months and those who have not. Create an automated format for disseminating a wikipedia page as a newsletter, and storing that in a sequence of other newsletters.

3. Maintaining - articles[edit]

The next component of a project is maintaining articles. A project exists to improve and maintain the articles under its aegis. This is done through consensus-building activities, collaborations, and automated tools:

The article alerts system provides a method of viewing articles under a project's aegis.

  • Problem: we are constantly pinged for AfC articles.
  • Improvement: let AfC reviewers tag an article with a project, and display in the alerts system appropriately.

The cleanup listings tool is provided by Svick, allows viewing of articles by their tags. This is essential for ensuring that pages don't languish with merge and other tags for years on end, due to inattention.

  • Problem: This system has a bus factor of one and relies on the continued interest and responsiveness of Svick, which understandably has no obligation to Wikipedia and would rightly be able to retire at any moment.
  • Improvement: move or create an automated, similar tool that is provided automatically to wikiprojects.

A popular pages list is very useful for a project to target its collaborations.

  • Problem: this system relies entirely on a single user.
  • Improvement: again, move this system to a standard location and automate its provision to wikiprojects

Collaborations sometimes occur.

  • Problem: it is time-consuming to tag pages for collaboration, as there are many steps. On WP:MED, one should: (1) view old collaboration page (2) get the number of the revision (3) enter into collaboration table (4) update the old and new templates for articles currently being collaborated on (5) notify on the talk page (6) record the current revision number of the new collaboration on the COTM page (7) include a COTM template on the talk page of said article. This is in addition to (8) propose article for collaboration and (9) decide on COTM for said article. Summary: many steps
  • Improvement: create an automated tool for selecting a COTM, a duration, and automatically posting on the article's talk page, recording the revision number, etc.

GA articles are often the target of many users, who aspire to increase the percentage of articles under the project's scope that are of GA status.

  • Problem: one must wait an enternity for a review.
  • Improvement: a standardised set of tools could be provided to reviewers, similar to the sidebar provided for the new page patrol, that allow the primary reviewer to make notes whilst viewing the article (eg regarding images or copyright status), and in the review pane, to readily pass or fail the article, without having to make the many edits necessary themselves. This I believe would go some way to reducing the backlog.

Other users may prefer to oversee a list of recent edits to articles under the project. There is no way to do this automatically other than through the use of an automatic tool. On WP:MED, a user was kind enough to create this for us. On WP:ANATOMY, I watch the recent changes to the Overview of Anatomy page as a substitute.

  • Problem: frustrating and inefficient, hidden.
  • Improvement: provide this as part of the suite of tools for new projects. Allow edits to be split by the importance of articles and by user type (IP/user with < 15 days of activity/user). This tool is also used to locate new users and check for vandalism.

Conclusion[edit]

I hope this goes some way to elucidating why I bought this issue up. Having recently, with other users, revived the project and taskforce, I can only describe the process as extraordinarily inefficient, and finicky. To be specific about why this is a problem:

  • It detracts time from editing and contributes to editor fatigue
  • It deters users from forming Wikiprojects and taskforces, and makes projects and taskforces more prone to failure, decreasing the ability of like-minded edits to collaborate, and likely decreasing editor retention rates.
  • Reliance on single users is dangerous. Many tools rely on one or two users to be responsive and/or maintain the bots and servers. This means a problem or user retirement may have a large impact on the function of Wikiprojects

I suggest:

  • Create a standard and mostly automated process to create a Wikiproject and a taskforce within a Wikiproject
  • Provide a standard set of tools for each Wikiproject
  • Provide these tools as open-source tools that are hosted on Wikipedia servers and readily accessible to users.

I'll continue to watch this page and hopefully we can propel some action on this issue. Kindly,--LT910001 (talk) 13:51, 22 January 2014 (UTC) Edited for clarity. --桂彦良 (talk) 02:37, 23 January 2014 (UTC)[reply]

Automating creation of assessment statistics categories would be a big help[edit]

Did this for one WikiProject, and it took way too long. Can't find my way back to the instructions on how to do it, either! Djembayz (talk) 03:03, 16 February 2014 (UTC)[reply]

Other ideas[edit]

Love the idea of a team working on better tools for Wikiprojects[edit]

Would be so great to have people devoting time and energy to making a project like this happen! I wonder if funding someone to community organize the setup and survey wikiprojects to define priorities for first tools that could be volunteer-built would help this get launched? (or, if there were a scoped set of core tools that a grantee/contractor team could develop?). I see IEG potential here, if you do come to a place where you find that sort of support would be useful. Cheers, Siko (WMF) (talk) 23:17, 19 March 2014 (UTC)[reply]

I have no idea how to do this. I might suggest that the Wikimedia Foundation outright hire their own staff to do this. I imagine that most dedicated Wikimedians who participate in community discussions are also users of WikiProjects. I appreciate that the Wikimedia Foundation needs to do outreach to new users, but having better tools for established users might make for a friendlier environment and better atmosphere for all kinds of users. Speaking for myself, I organize a lot of work and collaboration in the context of WikiProjects. Blue Rasberry (talk) 16:21, 28 March 2014 (UTC)[reply]

Similar project[edit]

Hello, I have proposed a similar project here. harej (talk) 23:41, 5 June 2014 (UTC)[reply]