clean up notes from the pad
Rory shared a dashboard summarizing contribution activity in the OpenRefine repository, including metrics such as the number of issue openers per year and pull requests submitted.
Some metrics of interest that were discussed:
- whether pull requests were merged
- time taken to merge pull requests
- distinguishing translation contributions (via Weblate) from code contributions
The metric focuses on the main OpenRefine repository and does not include contributions to the website, where documentation work takes place.
Issue discussions and contribution pathways
Participants discussed the effort required to move conversations from community spaces (such as the forum or Wikimedia-related Telegram channels) into GitHub issues.
Forum and Telegram discussions have a lower barrier to entry, and users often start discussions there because they are unsure whether they have encountered a bug or simply something they do not yet understand.
This raised the question of whether the project should provide guidance on how to open issues.
- Nicolas suggested creating a reference document describing what makes a good issue or support question.
- This could reuse or adapt templates already used in the forum support section.
Interest in regular contributor calls
The possibility of organizing regular contributor calls was discussed.
- Tom noted that many developers prefer asynchronous communication rather than meetings.
- Nicolas also mentioned already having many meetings and limited availability for additional calls.
Recognizing translators
Participants discussed whether translators should be highlighted more prominently in release notes.
Suggestions included:
- Acknowledging translators explicitly in releases
- Using releases to help distribute updated translations to the community
Because OpenRefine releases updates frequently, translations are usually updated quickly. This is not the case for extensions that release less often.
A translation dashboard showing the current translation backlog could also be useful.
Wikidata Lexemes example
A participant raised the example of Wikidata Lexemes integration. They expressed interest in contributing but noted that they are not a developer and the topic is relatively niche.
The suggestion was that preparing a requirements document would help clarify the scope and enable a technical assessment, as such work could involve multiple projects (including Wikidata tooling and OpenRefine).
Translation and documentation
The discussion also touched on how documentation should be organized and translated.
- Srihari suggested that documentation should primarily live on the OpenRefine website, since that is where most users expect to find it.
- Guides and tutorials should also be hosted there.
- The GitHub wiki is less visible and not widely known by users.
Tom and Rory supported this view.
Some existing wiki pages could be archived or removed, with their content migrated to the website. Producing guidelines for migrating documentation pages was proposed as a possible community project. See #551