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
- our website Other distributions | OpenRefine
- the contributing.md file