March 14th, 2024, Advisory Committee Only

Community Day-to-day project operations
1

Attendees

  • Esther Jackson - Advisory Committee
  • Jan Aneli - Advisory Committee
  • Antonin Delpeuch - Advisory Committee
  • Martin Magdinier - Project Manager

Discussion

WMSE Contract

We want to extend the final report date of the 2023 Wikimedia Foundation grant to allow WMSE to have more time. We plan to ask for an extension only for the development part of the grant. We will publish the final report for the training by June 2023.

We are waiting for WMSE to propose a report date.

Consultant Selection

After Julie, Jan, and Martin interviewed Bocoup, SuperBloom, The Hum, and April Johnson and reviewed Bocoup and SuperBloom's updated proposal, the Advisory Committee decided to work with Bocoup on the project.

Martin will coordinate the next step with Bocoup.

Accessibility Audit

Details are available in:

BarCamp

We confirm we are ok going with the platform barcamp.eu

OpenRefine communication culture

The conversation moved toward the communication culture in the project. We discussed the difficulties for external developers to bring new large changes to OpenRefine. The community often pushes back, pointing at the complexity and difficulty of implementing the feature rather than welcoming it (as described in User Interviews Results Part 3: Cultivating a Thriving Developer and Trainer Community)

The group discussed how we can improve it by

  • Providing a better roadmap so external developers can anticipate what we want to collaborate
  • Offer a template for large enhancement proposals so they can engage early with the community.
  • As stated on our documentation and website, we should stop explicitly inviting people to fork OpenRefine. Contributing back to upstream is complex and time-consuming. We would rather find a way to work together than see a fork in the project.

GSoC

Following email back and forth with Google we confirm that all mentor helping students should be registered on GSoC platform. Google is expecting at least two mentors and two org admin.

Antoine is volunteering as backup mento. We should make it clear to the student who is the primary and backup mentor

2

Hi Martin,

Thanks for continuing to post the meeting minutes. I'm not sure what others think, but I'd find them more useful if they came out a little bit closer to the actual meeting that they're recording. As it is now, things (like grant deadlines) which are mentioned in the future tense can have already passed by the time we read about them.

the Advisory Committee decided to work with Bocoup on the project.

Martin will coordinate the next step with Bocoup.

Very cool. Are you working with Boaz or someone else? He has a long history in front end technologies in Boston and Irene Ros was a data vis pioneer when she worked for them.

We discussed the difficulties for external developers to bring new large changes to OpenRefine.

Large changes are difficult whether they come from within or without.

The community often pushes back, pointing at the complexity and difficulty of implementing the feature rather than welcoming it (as described in User Interviews Results Part 3: Cultivating a Thriving Developer and Trainer Community)

I don't see any details in the linked document. Do you have some examples of proposed large changes that were shut down? The only large change that I'm aware of was internally generated (Antonin's work).

we should stop explicitly inviting people to fork OpenRefine. Contributing back to upstream is complex and time-consuming.

Absolutely! A hard fork is a sign of failure (or short sightedness). While quickly hacking on a fork can seem to be lower cost, it's almost always more expensive in the long run and the forks end up being stranded in dead ends without access to new features, security updates, etc. It just ends up causing everyone to duplicate work.

If, for example, someone wants to create a re-themed OpenRefine fork, what they should do, in my opinion, is add support for themes to OpenRefine, including porting the existing OpenRefine theme to the new mechanism as the standard theme, and propose that as a PR. If it's well designed and doesn't negatively impact the core or other integrators, I don't see any reason it would have difficulty getting merged. I haven't seen anyone propose anything like this, but I easily could have missed it, so if you have pointers to relevant PRs, I can go back and look.

Tom

3

Thanks for your feedback @tfmorris

I'm not sure what others think, but I'd find them more useful if they came out a little bit closer to the actual meeting that they're recording. As it is now, things (like grant deadlines) which are mentioned in the future tense can have already passed by the time we read about them.

I am trying to ensure that the minutes are published within a week of the meeting. The delay of the March minutes was due to an oversight on my part.

the Advisory Committee decided to work with Bocoup on the project.

Martin will coordinate the next step with Bocoup.

Very cool. Are you working with Boaz or someone else? He has a long history in front end technologies in Boston and Irene Ros was a data vis pioneer when she worked for them.

It is great you already know them. We are working with Sheila Moussavi. I will meet the rest of the team today. I just published the official announcement here.

The community often pushes back, pointing at the complexity and difficulty of implementing the feature rather than welcoming it (as described in User Interviews Results Part 3: Cultivating a Thriving Developer and Trainer Community)

I don't see any details in the linked document. Do you have some examples of proposed large changes that were shut down? The only large change that I'm aware of was internally generated (Antonin's work).

I don't want to speak in the name of the people I interviewed since I didn't validate with them if I could use their example publicly. Their ideas were not directly shut down; rather, the development team or developer did not feel comfortable contributing upstream for fear of pushback.

An example would be hosting and multi-user support. Several organizations worked on containerizing OpenRefine or integrating it with Jupyterhub to support multiple users. While I am aware of the engineering challenges and effort behind this change, I don't think we ever show a willingness to support it. As a result, we have organizations running large-scale deployments with little support from the community. Maybe with a different approach, we could have turned them into contributors. More generally speaking, we can ask ourselves why we have so many other forks?

I hope that the work with Bocoup will help us set a framework for how we manage our roadmap and welcome new contributors.

we should stop explicitly inviting people to fork OpenRefine. Contributing back to upstream is complex and time-consuming.

Absolutely! A hard fork is a sign of failure (or short sightedness). While quickly hacking on a fork can seem to be lower cost, it's almost always more expensive in the long run and the forks end up being stranded in dead ends without access to new features, security updates, etc. It just ends up causing everyone to duplicate work.

Glad we are in agreement. In that case I will prepare PR to update

4

I created to track the change