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.

For more details about the split between Wikitech and mediawiki.org, check Dev wiki consolidation.

First iteration
We aim to deploy the first iteration within 3 months of the start date. The project would be coordinated by Quim Gil, with the participation of a contractor paid by the Wikimedia Foundation, Ryan Lane, Guillaume Paumier, and other community members willing to get involved.

Three prioritized drivers define this first phase:


 * 1) User profiles, nodes, projects, tasks and events categorized using Semantic Forms.
 * 2) Announcements sent manually, categorized and received by the users asking for them.
 * 3) Nodes generated automatically out of categories and user preferences.

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

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.


 * Integrated with Bugzilla.
 * Other tools like Gerrit sync with Bugzilla - see, "Integrate git/Gerrit and Bugzilla"
 * Publish tasks for contributors, tagging them by interests, location, language...

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.

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.