1. Homepage
  2. Events
  3. Wednesday (Day 2)

Wednesday (Day 2) 19.06.2024, 10:00 - 18:00

We will continue to work together on Wednesday, but we expect that not everyone will be able to attend.

Time Table

10:00

Improving OpenRefine contributor pathways: Roles, Permissions, and Processes
Our ongoing discussions throughout 2023 and early 2024 (https://forum.openrefine.org/t/improving-the-onboarding-process-for-new-contributors/882) have highlighted the need for a more systematic approach to managing our contributors. This session will serve as a platform to share our ideas and discuss how we can formalize the process. We will looking into the following points: 1. Defining Contributor Roles: What are the various contributor roles we should recognize and encourage within our community? How can we ensure that each role is clear and meaningful? 2. Setting Permission Levels: What should the permission levels be for different stages of involvement (e.g., new contributor vs. long-term committer)? How can these levels help in managing community contributions more effectively? 3. Managing Permissions: What processes should we implement for granting and revoking permissions? What criteria should be used to ensure fairness and transparency in these decisions? 4. Content of the different pathways for 4.1 Developer 4.2 Extension Developer 4.3 Designer We plan to use this as an example for the pathway and discuss the Open Source Design Workflow 4.4 Trainer 4.5 User Support 4.6 Translation 4.7 Documentation
Martin Magdinier
Room: main room

11:00

11:15

Using OpenRefine with Wikidata, Wikibase and Wikimedia Commons
A session to look at how users of OpenRefine with Wikibase, Wikidata, and Wikimedia commons use the openRefine, what are the key use cases, key functions and key workflows. Explore what needs improving and where the wiki* use cases overlap and diverge from other types of OpenRefine usage
Owen Stephens
Room: main room

12:15

13:00

Reconciliation in OpenRefine
This session demonstrates the workflow of the reconciliation service in OpenRefine along with the recent improvements (before vs after) in it be it in the the UI or in the error display, this would also be a brief anecdote of my experience in working for OpenRefine both as an Outreachy intern and a contractor along with various improvements that can be done in future for even better reconciliation !
Ayushi
Room: main room

14:00

Approaches to training people to use OpenRefine
I regularly deliver OpenRefine training, specifically to librarians, and I also wrote the original Library Carpentry OpenRefine course and I continue as a maintainer for that course. I'm interested in both sharing my experience and sharing the experience of others as to good approaches to offering training on a tool which has so many possible functions and use cases
Owen Stephens
Room: main room

15:00

15:15

OpenRefine as a service
When you browse GitHub or GitLab you can start a browser based integrated development environment with just one click. You can then start hacking with only a web browser and afterwards commit your results back to the project. What needs to be done to do the same with OpenRefine in the context of datasets? As a user you browse a collection of datasets and with one click you have a dataset loaded as OpenRefine project in your browser. With another click the updated data is sent back to the data provider. As a "data provider" you can start an OpenRefine instance for just a single user/session and populate it with a given dataset. After working on this dataset there is some callback to update the dataset.
Benjamin Rosemann
Room: main room

16:00

Strategizing our Roadmap for user needs
It would be nice to have someone go over the general roadmap of OpenRefine at the start. A final session on last day might be where we summarize the consensus and put into GitHub Project the Roadmap plan (perhaps with milestones). From my personal viewpoint, it seems we just need to get consensus on priorities which seem shifty to our users. We indeed already have some forum posts on Roadmap discussions, but for many users, it feels disconnected from "what is possible" versus "what do users need" versus the actually realized "what can we get funded to actually work on despite our users needs". (a sub-component of this discussion is how best to present dependencies of Roadmap items to users? Many other projects in GitHub use milestone partitioning, instead of Tracks and Tracked by fields. For example: "4.0-first", "4.0-second" "4.0-extensions-first", etc. in order to know that the "first" issues need to be worked first because "second" issues have dependency on the "first".) (another sub-component of this discussion is adding new fields to the GitHub Project tables to enhance Roadmap visibility)
Thad Guidry
Room: main room

17:00

Location