Wikidata:WikiProject Linked Data for Production/Practical Wikidata for Librarians/Project recipes/Coordination

Overview

These notes offer food for thought on coordinating Wikidata projects at libraries, beyond the nuts and bolts of workflow. For the nuts and bolts, please reference Wikidata:Linked open data workflow and Practical Wikidata for Librarians.

Also see:

• LD4-Wikidata affinity group call (22 Sep 2020)
  
• Wikidata project reflections, which informed the above presentation

Planning

Project scope

• When scoping the project, consider prior work which may have helped prepare data needed for contribution to Wikidata.
  • Example: a project history of ISNI contributions from previous URIs in MARC pilot.

Data models

What properties and constraints do we use?

• See resource lists (example)
• See other WikiProjects for comparable entities

How far do we describe?

• Data fields map to various Wikidata properties and constraints, and you can describe entities to varying degrees of detail. You may choose to:
  • Take existing decisions from documentation and WikiProject guidelines found during research
  • Specify layers of description
    • Example: Core - Standard - Extended description

What is the order of work?

• Some description will be contingent on other description
• Working out a logical order of operations in advance will save back-and-forth

Collaboration

Timebox

Regular meetings hold space for edits, training, questions.

These might look like:

• weekly/biweekly 1-hr meetings

You can use these to:

• make contributions predictable
• provide training as needed (there’s a limit to front-loading)
• allocate time for hands-on practice (easy to put off)

Roles

It is a good idea to have some point person(s) whom participants can default to for questions, at least in the initial stages. This need not be a hierarchical structure with a single point of convergence. If the participant pool allows for it, it can help to have multiple point people who take active stake in pushing project forward. Shared roles also help prevent burnout and keep the project sustainable.

Name roles to make participation bite-size and open up space for active contributors. You can even write fun descriptions + list prerequisites!

These might look like:

• scriptmaster, our go-to for custom exports
• documentation czar, help us do words
• tutorial wizard, find us that YouTube video

Inviting can also go a long way in proactively expanding participation.

Training

Training can help make tasks feel easy. Since many recorded trainings exist (examples), you could also just host a watch session.

Initial training (or video watch session) might cover:

• concepts and important ideas
• item editing, creation
• batch editing

Ongoing training might cover:

• focused practice on specific part of workflow
• additional tools + features

Onboarding

Onboarding might involve some mix of initial training, project updates, and a list of to-dos. It helps to make onboarding concrete, focused, and clear. Too many resource links or lack of focus can feel overwhelming. A buddy/peer can also offer guidance and be a go-to contact.

Support structure

Consider horizontal support structures that make it easier for participants to help one another.

These might look like:

• a buddy system (allow participant flux)
• train-the-trainer (like Carpentries)
• culture of shared edits to accessible documentation

“Not knowing” + cooperation as the norm helps more than “knowing” + dependency as the norm.