Project:New contributors

How to attract volunteers and connect them with interesting people and activities?

The problem
We have a problem engaging volunteers and motivating them to stay. The amount of documentation, tools and channels is so overwhelming that even we have a hard time following it all. Because we're in the shadow of Wikipedia, we could generate massive interest from tech-friendly users, and we could offer them suitable technical tasks. In reality, we miss many newcomers, and our community efforts don't scale.

In more detail:


 * Wikipmediawiki: what you need to know as a tech contributor is spread out over 3 or more wikis...
 * Plain text identification: it's 2013 and our user profiles consist of a textarea.
 * Memory in spreadsheets: all we have are lists of contributors maintained (or not) manually by various people.
 * Inefficient mass promotion: every time we start almost from scratch, unable to selectively reach target audiences.
 * Inefficient personal promotion: manual pokes in Talk pages + emails from those spreadsheets won't get you far.
 * Difficult to propose a first task: it's difficult for us - imagine how it is for new volunteers alone. After 1-2 attempts, they're gone.
 * Difficult to find peers: "ask in wikitech-l or #mediawiki" is not the answer.
 * English only: all of the above only gets worse when writing English is not your strength.

Proposal
"Mary registers on one site, and after filling out her profile, she is notified about projects, tasks and events related to her interests. She also finds information, contacts and opportunities to contribute organized around thematic nodes that she can follow. She will receive new notifications whenever there is an update suiting her preferences."

The Semantic MediaWiki and Echo notifications frameworks could get us there. We are the MediaWiki experts and we can iterate fast eating our own dog food. Wikitech already has the ingredients in place.

This experiment would be useful to the Wikimedia movement and to all the communities using MediaWiki. Even if our technical implementation wouldn't scale to the needs of Wikipedia, we would provide a priceless proof of concept with lessons learned.

The first phase proposed below doesn't require any disruption in mediawiki.org and our current processes. The discussion about the location of the content for technical contributors continues at Dev wiki consolidation.

First phase
The goal of the first phase is to create a functional prototype without disrupting mediawiki.org. This would be done through intermediate releases of new features (see ). No content from mediawiki.org would be migrated at this point. Content creation during this pilot would focus on the real use of the new tools (e.g. events or tasks) and the project documentation.

Three prioritized drivers define this first phase:


 * 1) User profiles, nodes, projects, tasks and events categorized using Semantic Forms.
 * 2) Basic functionality of targeted notifications in place.
 * 3) Nodes generated automatically out of categories and user preferences.

The project would be coordinated by Quim Gil, with the collaboration of Ryan Lane, Guillaume Paumier, and other community members willing to get involved. The small Engineering Community Team actually handles most of the key areas of this prototype: publishing events and possible tasks, sending notifications to potential contributors, encouraging users to register and identify their interests, bringing up interesting reports in Bugzilla... We also have projects and publish status reports just like any other Wikimedia Engineering team.

We could consider more features, but only after establishing this foundation. Check the /Roadmap/ for details.

People
Identify yourself to connect with relevant people and activities.

The User page is extended with category data using Semantic Forms, becoming a proper profile. All fields are optional and feature autocompletion:
 * Interests: OSS activities, programming languages and projects.
 * Opt-in options for each: Send me updates, Show me in lists.
 * Locations.
 * Languages.
 * Free software/free knowledge project involvement.
 * Social media handles.
 * Avatar.

The User Talk page is preloaded with LiquidThreads.

Nodes
The key information around a specific topic

Nodes attract newcomers and connect them with more established contributors sharing their interests. You visit a node to learn about a topic and the activity around it. You join a node to identify yourself, receive notifications, meet peers and collaborate.

Expect nodes about PHP, Android, Gadgets, Security, Open Data, Labs, Wiki Loves Monuments, Women, Bangalore, French...


 * When a user enters a new category through her profile, the corresponding node is created automatically in the Node namespace.
 * Users can define their level of involvement in the node: supporter or follower.
 * Supporters are listed at the top of the list.
 * Followers are not listed by default, but they can activate the option in their profile.
 * Users are listed and delisted automatically according to their profile preferences.
 * Users can join / leave a node via an an option in the node page.
 * Users can watch / edit / discuss in the node page & related Talk page, but they can't remove or manipulate the list.
 * The nodes' Talk pages are preloaded with LiquidThreads.
 * Duplicated / mistyped nodes can be redirected to the right ones.

Implementation under discussion.

Projects
A standard way to report goals, members, tasks and updates.

All projects are encouraged to have a standard page under the Project namespace. The structure contains:
 * A box with data fields to be defined, like WMF projects have.
 * Members, connected with user profiles.
 * Description.
 * Standard process for status reports.
 * Related categories.

Tasks
A funnel to connect pending work with potential contributors.


 * Publish tasks for contributors, tagging them by interests, location, language...
 * A quick way to advertize and categorize in MediaWiki tasks that are already described and handled elsewhere (Bugzilla).
 * NOT a new parallel tool.
 * Integrated with Bugzilla.
 * Other tools like Gerrit sync with Bugzilla - see, "Integrate git/Gerrit and Bugzilla"

Events
A standard way to advertise activities and discover the people joining them.


 * Events share a lot with Tasks, but they are tied to dates and have many participants.
 * Task mentors = Event organizers. Interested in task = Sign up to event.
 * Events are automatically listed on a Calendar.
 * People signing up are automatically listed at the event.

Notifications
Receiving updates about the things that matter to you.

Maintainers can contact users, filtered by tags, with:
 * Promoted tasks.
 * Events.
 * News and announcements.

If Echo is not ready yet for this we can fallback to an adaptation of TranslationNotifications. In the future, Flow should take over.

One ontology
A common vocabulary to classify items across all our tools

Call it categories, keywords, topics, tags, metadata... What we need is one set of words applied consistently to wiki content, helping to connect related people, nodes, projects, tasks and events.


 * Location: cities, regions...
 * Contributors' activities: based on the How to contribute structure.
 * Programming languages: PHP, JavaScript, HTML, CSS, Puppet...
 * Human languages: English, German, Hindi...
 * FLOSS projects:
 * Wikitech / MediaWiki projects.
 * Other free software / free knowledge projects.
 * Task identificators: [priority], [severity], easy, mentored, patch-in-gerrit...

This ontology should be consistent with the rest of the tools we use, enabling easier, even automatic connections and aggregation of content:


 * Bugzilla keywords.
 * Gerrit tags.
 * Wikimedia tech blog tags.

If you want to promote a bug, a changeset, or a post to a specific set of contributors, tag it accordingly in your tool. We might not have the technical solutions to automate this promotion today, but consistent tagging is already useful to ease manual work.

Development
The features developed in this phase can be organized around tracks. Each track can have a list of features developed mostly sequentially. However, the development focus can alternate to a new track after each feature released. In theory this would create a gap between development sprints inside a track, used to evaluate the impact of the release and plan the next steps accordingly.

Each feature includes evaluation factors. Work in progress...

FAQ
Remarkable early criticism that helped shaping this proposal before the RFC.


 * Looks like a solution looking for a problem.
 * We do have a serious problem but it is less obvious for established contributors. People out there want to help but most of them have a hard time getting on board. Engaging new contributors and lowering barriers for participation is a top priority for Wikimedia.


 * It seems too ambitious.
 * It is feasible. To make it more manageable we have pushed many features to the /Roadmap/ and we have spinned-off the proposal about mediawiki.org & Wikitech.


 * It lacks a proper implementation plan.
 * The priority has been to draft a vision and share it with the community asap. We are getting into implementation details as we feel that there is enough interest to continue the work.


 * It's not scalable for Wikipedia.
 * It is scalable for our community, which is the problem we want to solve today. When a better solution exists for the whole Wikimedia movement we can migrate.


 * What if I don't care about feature X or altogether?
 * You can continue doing what you are doing. All the new features are optional. The worst that can happen is that you find in certain pages a soft-redirect, or a form instead of a.


 * What about privacy?
 * There are no changes compared to the current situation. New user profile fields are optional. Appearance in the new Nodes is opt-in.