The Wikipedia Library/Processes/Library card platform proposal

Approval/Account management system

Problems

TWL has hit a process efficiency barrier during the approving and distributing account information to editors (for documentation of the current process see Signup Setup). Currently, seven sets of problems make the management of signups cumbersome, reducing efficiency of paid labour and making volunteer responsibilities unwieldy:

• the need to manage initial sign ups for accounts in a public space (on-wiki signups), while needing to maintain the actual information for distributing accounts in a separate private space (Google Forms), means that both volunteers and coordinators have to track multiple sets of user data in multiple spaces. This leads to several layers of customer loss at each layer, with as many as 10-15% of experienced users that qualify for accounts, not receiving access because they get lost in the business process because of a) the number of steps required or b) the amount of time between steps. Attrition happens at other points in the account usage as well: We don't have a reliable method of reminding volunteers with access, that they have access. Frequently users will sign up and get access, but forget they can use it for any number of reasons, they forget about the access: without more tracking tools, we don't have reliable methods for reengaging users at any stage in the process.
• Converting lists in these tracking areas for metrics and transference between platforms becomes labor intensive, making it harder to provide management-level metrics, and ensure that editors don’t fall through the cracks.
• The need to use the Wikipedia “Email user” function to email editors before acquiring emails in the Google Form, means that emails are often lost in spam folders.
• Editors who apply to multiple partnerships or on multiple different language wikis are often repeatedly screened, because current workflows don’t provide easy crosslisting, and solutions using our current systems would require giving personal information access to multiple volunteers who don’t need it.
• Management of partnerships, and maintenance of metrics on number of accounts in each individual partnership currently require manual compilation, based on multiple different forms/lists
• Currently we are tied to partners providing access codes or activation on the partners’s end. OAUTH integration would allow us to manage access directly through an editor’s library card.
• We don’t have a system to track individual usage of accounts, which is something that we must ask partners to provide, but we would rather have in house for ease of access and ability to produce on demand. Having a system that can link directly into a link tracking tool like Linkypedia V.2 would help us strengthen our reporting and customer and partner support.

Proposed Solution

We propose a technological solution be implemented to help us better organize and systematically collect applicant information, ease coordinator time impacts (making volunteer work less cumbersome), and centralize the management of accounts, so that managing coordinators (Jacob Orlowitz, Alex Stinson, Patrick Earley, Nikkimaria), can provide more effective oversight, process metrics and better support volunteer work. The functionality of the tools would require functionalities that could replace our current reliance on form submission in Google Docs, spreedsheets to track users and their information, and mail merge and/or custom emailing. The following elements are important to our vision of the tool:

Primary Functions

Library Card - Simplifying application and access process for TWL subscribers Collection and storage of applicant information for TWL as a Library Card, so that it can be used to facilitate access on multiple accounts. Currently we collect information via a form on Google Forms that is mostly standardized, but for each account we have to collect the information separately. If each user had a standard set of information held locally, we would not require repeated collection of that information.

• Required data storage

• User name
• Email address
• Languages user declares activity in

Additionally, it would be useful to create additional data fields that could be partner-specific (for example, in addition to answering "What is your background editing Wikipedia", it would also be able to ask, "Why do you want access to [Elsevier]?", "Why do you want access to [JSTOR]?" etc.

The ability to apply for access to partnerships, including the ability to write an “application” that allows them to submit two pieces of data for each partnership

• A block of text describing how the customers would use the specific partnership.
• A digital affirmation of the TWL and Partner T&C

Subsequent the information entry, the tool would need to provide the associated Library card holder with:

• A “status” function to track where Screening and Distribution of an account is based on the coordination functions (see below). Currently, a majority of email traffic from TWL customers relates to status checks.

Coordination

Screening and Distribution of accounts (for the process governed by this function see https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Library/Processes/Partner_pages#Step_Five:Processing_Accounts)

• Once a user has entered information, and submitted a specific justification for access, the coordinator needs secure access to the justification and links to user status checking tools. Status checking tools should function in a fashion similar to popups and will provide the Volunteer coordinators the ability to screen applications quickly and efficiently.
• The ability to check if customers have been approved in other partnerships. This would allow volunteers to more quickly approve repeat customers.
• Once approved, the Volunteer coordinator should be able to send a form email (in a mail-merge type function) from a TWL-specific account that provides the user with information on how to access the partnership, or any other change in status (denial, waitlist, or need for additional information to approve accounts).
• Coordinators should be able to create form emails for specific partnerships in order for them to be used via the mail-merge.
• Coordinator should be able to create text describing the partnership and include a link to on-wiki information pages.
• An extra feature could include activation of a messaging bot on-wiki that allows distribution of messages to multiple on-wiki users.

Management

• Create metrics with overview status on all partnerships, with # of applicants at each process stage of the account issuance.
• Eventually, this could also provide other user-related metrics, for example: how many languages are the editors in a partnership recently active in? How many edits have they made since getting access? How many edits include links to a specific partner.
• Integration of Linkypedia V.2 metrics, to help track linking materials.

Possible GUIs

• Library Card Portal - a form interface for editors to manage which accounts they are applied to, and examine access information. Initial sign up should be associated with their Universal Login, and allow them to insert basic information for TWL coordination.
• Transparency portal

• currently initial screening of applications is done on-wiki because we want editors to be able to see what the status is for all applicants, so that the TWL processes remain transparent to the Wikimedia community. We would like to create a portal for each partnership that allows community members to see who has been approved and not approved.

Coordinator Screening Portal

• Provides access to applicant information, and queues of customers that need to be screened for individual partnerships
• The ability to create partner pages and form emails.
• The ability to track usage of the partner’s urls per user (Linkypedia V.2 metric).

Management Portal

• This portal allows TWL coordinators to view the status of applications on a whole, with metrics on the number of customers approved for each partnership, alongside numbers of customers at different stages in the process
• Output metrics into usable reports.
• The ability to zoom into the coordinator portals in order to interact with Coordinator functions

Requirements

• Web-based
• Hosted on Wikimedia Labs
• Login facilitated through SUL and MediaWiki Apps; once logged in, personal information needs to be securely stored
• OAuth integration

Levels of access

• Public - Transparency portal
• Wikimedia SUL based/Library card access - Individual information in Library Card Portal and below
• Volunteer Coordinator - Coordinator Portal and below
• Admin - All levels of tool

Priorities

• Library Card and Partner Coordinator functions
• Library Card and Coordinator Portals
• Transparency Portal
• Management functions and portal
• OAuth Integration