GlobalProfile/Affiliation scratchpad

Abstract

In abstract, the focus of this initiative is to connect and enable contributors of all types to better work on the projects.

Within the greater Wikimedian community, identity and affiliation software is often misconstrued to be frivolous and non-encyclopedic. However, users within the community naturally gravitate towards creating their own versions of identity and affiliation, with user pages and Wikiprojects (and like organizations).

A primary indicator of the difference between the two models (Bookface vs. Wikiface) is where the user's itch is scratched within Maslow's hierarchy of needs. Bookface and other social software is targeted towards fulfilling the third level (love/belonging/social) needs, while our affiliation tools drive at the 5th level (self-actualization).

Additionally, Facebook and other "typical" social sites focus on elevating the user's "social graph" - the connections between the user and other users. In the Wikimedia space, we are interested in surfacing the user's "interest graph" - the intersection between

• How the user wishes to contribute (e.g., copyediting, or graphics work, or localization)
• What the user is capable of doing (e.g., research skills, graphic design tools, languages known)
• What the user has knowledge about (subject matter)

It would be disingenuous to state that there is no social component involved with grouping and affiliations. However, the purpose of wiki affiliations is not one geared towards social activities but rather towards creation of an encyclopedic product.

We know:

• Users often have difficulty finding things to do. In fact, this is one of the greater barriers of participation among new users. Much of this can be attributed to
• Users are not often aware that Wikiprojects (or other affiliations) even exist. The primary method of discovery for Wikiprojects is through article talk pages, and even there the "membership" of an article to a project is effectively buried inside of several tan boxes (which users have been trained to ignore).
• Wikiprojects (and other affiliation groups) are fairly good at developing task lists (especially non-controversial tasks)
• Wikiprojects are generally low-drama.
• Invitation culture is extremely effective in generating participation

Hypothesis

Effective tools for affiliation will increase collaboration system wide by:

• Increasing the visibility of various groups and projects
• Introducing new users to structured tasks
• Suggesting additional affiliations to experienced users in order to share their expertise with other groups (surfacing additional interests)

Note

This project is dependant on Flow, Echo, and GlobalProfile. This project is being designed for Wikimedia Foundation projects; no thought has been given to third-party re-use (though they are welcome to use it).

Wikiproject vs. Affiliation vs. Group

"Wikiproject" is a very Wikipedia-centric term. Since the scope of this project is larger than just Wikiprojects, we need a better term. Examples of possible affiliations can include:

• Wikiprojects
• Sysops/Administrators
• Page Patrollers/Vandal Fighters
• Arbitration Committee members
• Foundation Staff
• Translators/Localizers
• Developers
• Teahouse hosts and guests
• OTRS responders
• Chapters
• Local wiki groups

Affiliation Objects

Storage wise, Affiliation objects will have several metadata elements and then associated objects (like lists of articles in scope). Additionally, Affiliations will have a configurable "dashboard" that can contain multiple widgets that provide access to associated objects.

Metadata

• Name
• Logo Image
• Home Page/Dashboard
• Welcome Page URL
• Scope statement
• Flow Board

Objects and Widgets

Problem: Not all groups are structured the same way. Some groups are extremely organized and some groups are loosely tied. Accordingly, not all groups will be served with a cookie-cutter experience; the software must be flexible and allow each group autonomy to include or exclude functionality.

Common elements on Wikiproject pages include:

• List of n+ Articles in Scope
• List of members
• Activity History
• Task Lists
• Lists to common tools
• Brag Box/Accomplishments
  • Featured Articles/Lists/Pictures
  • Peer review candidates/FAC
  • Good articles
  • DYKs
  • Historical content (former FAs, etc.)
    • This is going to have to be configurable

Group Auto-Invitation System

A mockup showing a post-edit invitation

• After X edits to articles in a project's "umbrella" a dialog is loaded with an invitation:

"You've made several changes to articles within the scope of $WIKIPROJECT. Would you like to join the project?"

• "I'll take a look" | "No, thank you."
• Include "do not send me additional invites"

Widgets

Membership List Tool

• Filter by new members
• Global Message
• Membership "Level"/Ranks

Member Profile Tool

This is a "local-to-group" profile

• • GlobalProfile skillsets
  • I'm willing to work on...
    • These tasks are configurable per project, checkboxes

• Send message to member
• Awards?

Task List Tool

• State: Open/New/Closed ?
  • Adding an article to a task is currently handled via MediaWiki categories
• Searchable
• Task Categories/Groupings
• Alert level thresholds configurable by number of items per group
• Task type must be configurable per group
• "Find likely users for this task" & Invite tool (think Quora's Ask to Answer)

Article Lists

This is a list of pages that have been tagged as being in scope of the Wikiproject

Currently, marking an article "in scope" is done by templating the article's associated talk page. This also (typically) adds a Mediawiki category to the article (often a hidden category).

In an ideal world, these articles would be "tagged" rather than placed into a "category". At this time, Mediawiki does not have a tagging system (though one is proposed within Flow).

An additional wrinkle is that standard "tagging" nomenclature doesn't necessarily work for this use case (we would just end up with unweildy tag names like "#wikiproject_cats", which isn't much of an upgrade from the current system of Categories).

Questions

How do you create a new group?

• • Namespaces? All current wikiprojects would need to move to a new space, which sucks.
  • Magic Word is probably best, e.g. {{#affiliation}} with some arguments
    • We'll have to have some way of doing a "soft" transition.

Dashboard Set Up

Consider a set of magic words/transclusions for widgets that can be edited in raw wikitext. The project home page/dashboard is then standard wikitext with additional keywords that inherit from the master "affiliation" magick word, thus:

{#affiliation|name=Cats}
{#affiliationwidget|header}
{#affiliationwidget|scope}
{#affiliationwidget|memberlist}
{#affiliationwidget|bragbox}
additional wikitext here

This solves for the soft transition problem as existing projects can just start declaring themselves as affiliation objects and then slowly transitioning out their existing elements.

Jorm's Scratchpad

• Wikidata connections? This clearly is of great value with GlobalProfile but can it be leveraged for affiliations?

Identity Requirements

Intersection of: * What I can do * What I care about * Groups I belong to * Projects I work on

• List of interests
• List of skills
• List of languages

- Enumerated values (1 - 5) for strength of item on languages and skills - Doesn't make sense for interests

• Bragging rights

Punt Box

• Avatars