Inviting Benjamin to the GitHub organization

antonin_d · April 8, 2025, 11:25am

I'd like to propose to add @b2m to OpenRefine's GitHub organization, in the Developers team.

Benjamin has been active in the community for a long time, with great contributions on the forum and training work in the German GLAM community:

He also made his first code contribution recently (a far from trivial one):

github.com/OpenRefine/OpenRefine

Enable custom clustering for non-GREL expressions

master ← b2m:issue-7234-custom-clustering

opened 07:49AM - 02 Apr 25 UTC

b2m

+275 -64

Fixes #7234 In #6612 we introduced custom clustering functions. But with no…n-GREL expressions like Jython and Clojure the clustering failed on multiple levels. 1. Several post requests in the new clustering dialogs were missing csrf tokens. 2. Several post requests did only sent the plain expression without the language code. 3. The GREL language code was hard coded in `UserDefinedKeyer.java` and `UserDefinedDistance.java`. 4. The new variables `value1` and `value2` were not made available in Jython and Clojure expressions. The last one is probably the most problematic. In GREL all variables in `bindings` are basically available as globals. But in Jython and Clojure we encapsulate the expressions in functions and only pass certain variables as parameters (`value, cell, cells, row, rowIndex`). This means that in Jython and Clojure expressions we can not access variables like `columnName`. This also means that we somehow have to make the new variables `value1` and `value2` accessible to Jython and Clojure expressions. Without rewriting the whole Jython and Clojure integration it felt most idiomatic to also introduce the new variables as parameters to the Jython and Clojure functions that encapsulate the expressions. But it is still somewhat unsatisfying that we have a different pool of available variables in GREL and (possibly) each other language integration. **Note:** for the custom clustering a separate set of `bindings` is created. This means we basically only have access to `value` and `value1, value2` respectively. Usually available variables like `cell, cells, row, rowIndex, ...` are not available (not even in GREL). As this seems to be a deliberate choice I did not touch this part. But we should also document this behavior e.g. on [Custom clustering methods](https://openrefine.org/docs/manual/cellediting#custom-clustering-methods) to avoid further confusion.

I would normally wait for other code contributions before nominating someone to the GitHub org, but given that Benjamin has a great track record of user support and training contributions before that, I think it would be really useful to have their expertise in PR reviews, and ease his further code contributions.

Adding him to the Developers team would let him label issues, run the CI pipeline on their PRs automatically, and also review other pull requests.

How does that sound?

Rory · April 8, 2025, 1:38pm

As you said, that first code contribution was far from trivial. I think the ability to find and resolve that issue demonstrates a firm grasp of the codebase and a sound technical knowledge. I support adding Benjamin to the GitHub org!

Topic		Replies	Views
User-defined Clustering Project Development & Design	47	291	September 17, 2024
Releasing 3.9.3 Development & Design	8	75	April 17, 2025
Live Coding - Adding Groovy as an expression language Community announcements	3	119	May 24, 2024
Ruby as an expression language Development & Design	1	63	May 26, 2024
Using LLMs in OpenRefine for data wrangling with Hugging Face inference API Support and Helpdesk hints-and-tips	2	68	December 4, 2024

Inviting Benjamin to the GitHub organization

Related topics