OpenRefine 2024 Barcamp: Improving Contributor Pathways

Community
1

This session focused on reviewing and enhancing the contributor guides for various roles within OpenRefine, particularly designers and support/helpdesk contributors. The discussion emphasized the need for clearer user experience leadership, better documentation, and more accessible design frameworks to effectively support community engagement. See the Barcamp page.

Introduction

Earlier this year, @martin participated in the CSCCE Community Playbook workshop, an organization fostering better community management practices in scientific fields. This resulted in the drafting of three playbooks to support the community better. Details about the approach are available on the forum: Requesting Feedback: Documenting OpenRefine Community Handbooks.

During the workshop, @martin identified the following contributor types:

  • Developer
  • Designer
  • Technical Writer
  • Translator
  • Trainer and Advocate
  • Support
  • Admin support (project manager)

We are missing users in this list. They ask questions, report bugs, and suggest new/missing features.

In this session, @martin reviewed the contributor guides that describe how one can contribute to the project. While there are existing guides for developers and an early version for designers, there is limited documentation for other roles. The conversation focused mostly on how we can better support designers and contributors in a support or helpdesk role rather than discussing how to set and manage permissions for each role.

Related documents and discussions:

Designer Role

History of the Design Role at OpenRefine

We acknowledge that OpenRefine's '20 paradigm can be hard to understand for the younger generation. Collectively, we did a brief summary of OpenRefine's design contributions since 2021:

  • 2021: Wikimedia Commons extension funding included a paid designer role with Lozan, who looked at various design aspects, including terminology.
  • 2023: Outreachy designer role:
    • Worked to sort out the usefulness of potential contributors.
    • Granted role, looked at designer pathways (see Contributing as Designer), and started using Figma.
    • Seen as a success, as we now have more design issues for new contributors to pick up as good first issues.
  • 2024: Designer in a paid role; outcomes are not yet seen.

What Does Design Encompass?

We identified four levels of design:

  • Screen Design: GUI design, suitable for more junior contributors.
  • System Design: Architecture and workflow design, often performed by more senior individuals.
  • Brand Design: Logo, website, merchandising.
  • @thadguidry: We need a Javascript/GUI senior designer like James Home. What we lack is a Javascript and UI/UX expert to work with us help us prototype things and get community feedback.

Current Status

We recognized that we do not have a clear person responsible for user experience. Our design process relies on a decentralized team without a product owner or manager. In the room, seven people identified themselves as participating in the design of OpenRefine; most did not have a formal design background but had in-depth knowledge of OpenRefine and user expectations. They are helping to scope requirements and contribute to designing screens and building workflows.

Take away question: How can we make the design framework more accessible to the rest of the community and teaching them how to use it.

Support / Helpdesk Role

Ten people in the room identified themselves as providing user support. Most also identified themselves as trainers. Support happens on platforms such as Twitter, Mastodon, StackOverflow, private email, and community Slack instances like the British Library.

Individual Experience

We started with a roundtable on individual experiences providing user support:

  • @ostephens: Contributing support in the Slack instance of the British Library where he conducts courses a few times a year. Doing OpenRefine support can be a distraction from his primary tasks, but complex questions are often more interesting.
  • @yaeln: Gives classes in the community and participates in discussion groups.
  • @Susanna_Anas: One-on-one mentoring of users going through a data cleaning process on their own.
  • @mack-v: Direct communication between users and trainers is common, often bypassing generic support channels.
  • @thadguidry: Before retirement, received many private emails asking for help. Now directs people to the forum to seek help from the wider community.
  • During the session Using OpenRefine with wikidata, wikibase and Wikimedia commons, we discussed how we support users asking questions by mixing OpenRefine and wiki-related issues.

large user group is working with wikibase, wikidata or wikicommons with OpenRefine. Often they mix OpenRefine and wikibase issues into the same question. Their questions cannot just be answered in OpenRefine; needs wikibase, wikicommons or wikidata knowledge. See, for example, Wikibase Reconciliation service: issues with EDTF Date/Time data type. Question: how do we as a community react to that?

Short videos might help, as people often skim through reading material. We need to update our introduction video.

Forum Structure

Perhaps the documentation is too technical for some people, and introductory documentation (FAQs) could help.

The Support Category is Intimidating
Support category questions look complicated, possibly discouraging users from asking basic questions. Especially here, content should be available in many languages, as low-level users might struggle with English and technical terms. We discussed renaming the section from "support" to "helpdesk" to be more inviting. The conversation continued in Renaming the Support Category to Helpdesk.

Creating Sections by User Type
Should we segment the support section by user type (e.g., GLAM, Science, Journalism, GIS)? For example, we already have tags like Wikibase, Wikidata, and Wikimedia Commons. There is a risk of people posting in the wrong sections, but moderators can easily recategorize or split conversations into new threads.
@thadguidry: In Discourse, we can create user group. We should try enabling this option to allow the community to join groups, which is different from categories.

Designated Community Leader

We discussed having a helpdesk mentor to manage traffic and direct questions to the right people could be beneficial. We can recognize this role formally, possibly as a paid position, and offering training would help.
@mack-v: We can assign community leaders as moderators to categorize? Regular meetups to exchange experiences would be required.
In the Carpentries community, there are yearly check-ins to confirm if people still want to feel responsible for a course, regardless of their activity level.

During the session Using OpenRefine with wikidata, wikibase and wikiemdia commons we discussed the option to invite more wikimedia expert on the forum to help answer those questions.

Developer Role

In the Reconciliation in OpenRefine session, @Ayushi_Rai presented her experience as a developer and how she joined the project. For clarity, notes have been merged with this session.

@Ayushi_Rai learned about OpenRefine from another Outreachy intern. It was her first hands-on experience with open source. She described the OpenRefine community as "really active." The developer documentation was a good starting point but still lacked some information, which might be a good basis for a FAQ for developers.

The "Good first issues" are essential for an intern to qualify for the scholarships. @antonin_d mentioned that we were running out of good first issues in the last Outreachy run. In 2023, @abbe98 helped @Ayushi_Rai find good first issues. @jfaurel suggested having interns recommend new "good first issues" as the last task they do to help refill the list.

The documentation on Cypress testing needs updating: Cypress Brief Overview.