The Advisory Committee seeks the active participation of the current developer team in shaping this process. We value your experience and insights and aim to ensure that any additions to the team support your work and are not disruptive.
Recruitment Process: How can we best involve you in the recruitment process to ensure the new developer aligns well with our project culture and technical expectations? Do you have any experiences or suggestions from other open-source projects that could guide this recruitment? How can we ensure the person is technically competent and understands OpenRefineās technical direction?
Authority and Decision Making: The new role will involve critical tasks such as merging pull requests and making technical decisions. How can we ensure these permissions are granted appropriately to a newcomer? What steps should be taken to help this individual gain your trust? Should this person go through a formal vote as drafted in the new governance?
Reporting Structure: Although the Advisory Committee will manage the contractual aspects of this role, effective collaboration with other developers is crucial. How do you envision this reporting and collaboration structure functioning best within the team dynamics? What are your suggestions for onboarding this person into the project?
We want Antonin's replacement to start in 2025. Finding the right person may take a few months. Instead of waiting for the governance to be revised, we'd like to move forward with your consensus and support to avoid delays in the process.
We look forward to hearing your thoughts and ideas.
Martin
I think video meetups would be ideal and necessary. OpenRefine is a big project and asynchronous knowledge transfer can happen after first video meetings, quite likely.
As far as knowledge and skills requirements for PR reviews:
Git
Java
Javascript
HTML/CSS
The rest (CI/CD, architecture, etc.) will have to be collaborative knowledge sharing, just as we did when Antonin first began looking at our project many years ago and he slowly came to grips with the codebase and our history and architecture. Personally, I have many hours available during any given week and so I'd be happy to share knowledge and answer questions and video meetup with the developer including after their contract begins.
Tom and Antonin are the only ones that have Repo Owner privileges now? and would add the new developer to a role where they are able to merge into our protected master branch. I think a formal vote is necessary, yes. If there is not consensus and some confidence in their ability/skills at the onset then everything after just breaks down. I think hearing and seeing them git checkout and verbally walk through PR's and impacts to our architecture, during a meeting would give me confidence in their ability. No matter what, unless they are already an OpenRefine user, and previous contributor, there's going to be learning and knowledge sharing from us to them, undoubtedly. We just need to ensure that we are not having to teach Git, GitHub, PR reviews, Java, Javascript, Maven, IDE setup. Our architecture and project setup can be taught. In my ideal world? - I'd like to see Tom, if he is willing , to step right into this role, but that's probably too much to ask of him, but still it could be parttime for him and not necessarily fully 40 hours a week, but even 5-10 hours a week is quite an ask from anyone who isn't fully interested.
Initial first video meetings, and then collaboration using the Development & Design forum and GitHub Issues & PRs. Already answered the general onboarding I would expect in previous comments.
No worries, I also expect it will take time to find someone interested, which is really the key and how Antonin initially got involved - he wanted to learn more.
thanks, @thadguidry, your approach makes sense, and I am aligned.
Obviously, if the hired person is already an OpenRefine contributor, the project would be smoother. I would love to see applications coming from within the current developer group.
Here is the current admin team. This needs to be updated but I don't want to side-track this conversation.
Overall, I want to understand from current team what's the process for the person to become a committer (if the person is from outside the current developer community).
Well, the current process is that they self nominate themselves by asking in the Development & Design channel, or current contributors identify and notice someone contributing who might want to make larger changes and would like to have a direct branch to work on in our repo, as well as help with reviewing and merging PR's.
Below, from our Goverence.md (and I think I'd keep this as is) for the following reasons
I'd be unlikely to add wording about any timing or schedule into it; like saying "Every 6 months, we meet to identify new nominations" because someone could become actively involved in just 1 month or less, and show robust skills and want to help much more.
How to become a Committer?
Be a contributor and be nominated as a Committer. Current Committers select and elect new Committers. You may nominate yourself. Nomination should be sent to the developer discussion list
The largest amount of trust is placed on the repo Merge rights, because this has the widest risk to unsettling our codebase (and I'm guilty of doing quite a bit of unsettling in the past myself.) So that privilege or right would only be given to someone who has been part of doing PR reviews and giving useful feedback and has demonstrated clear understanding of our architecture and codebase.
For new branches on the repo, well, that's actually very low risk, and doesn't hurt really anything. We should actually be happy and willing at anytime to create new branches for anyone that wants to work on something special, directly. But when it comes to finally merging that branch, see above paragraph.
But honestly, GitHub Forks are really the best thing, because it serves the same purpose as direct branches and doesn't have to involve the team at all until PR time.
So... hmm, I'd probably remove the mention of direct branches in the governance, but let's hear from others on that note.
Thanks for starting the discussion on this! Many important questions, and personally I am really not sure about answers.
Overall, I have learned not to trust my own intuitions about hiring, because of various misjudgments I made in the past, so I would be very cautious about giving any sort of directions again. I think this isn't an easy role to hire for, because we're looking for someone to take responsibility in the project on the long term rather than a short-term gig.
I agree with the scope outlined above. Over the past few months, I have reduced my involvement in reviewing PRs, addressing vulnerability reports and making releases. While @tfmorris is making a really noticeable effort to step in, I think there is still a significant impact on those areas, with people needing to wait longer to get their PRs reviewed / merged, and for vulnerabilities to be addressed. Intuitively it makes sense to strengthen our capacity there.
, to step right into this role, but that's probably too much to ask of him, but still it could be parttime for him and not necessarily fully 40 hours a week, but even 5-10 hours a week is quite an ask from anyone who isn't fully interested.