Seeking Input on New Developer Role for OpenRefine

[Martin]

I am opening this message on the Development & Design list for greater visibility than the Community. I am mainly seeking feedback from the current active developers on OpenRefine (looking at current top contributors over the last 24 months @tfmorris @antonin_d @abbe98 @thadguidry)

As part of our ongoing efforts to enhance the sustainability and maintenance of OpenRefine, the Advisory Committee is considering the addition of a new developer to OpenRefine (see August 29, 2024, Advisory Committee only). This role will focus primarily on general maintenance tasks, such as managing the GitHub repository, triaging tickets, and reviewing pull requests (see Grant opportunity: Open Technology Fund - #5 by Martin). This person may also maintain the Wikimedia Commons and Wikidata integration (see Grant Opportunity: Wikimedia Community Fund: - #13 by Martin).

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

[thadguidry]

@Martin

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?

1. 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.

2. 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.

@Martin

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?

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.

@Martin

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?

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.

@Martin

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

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.

[Martin]

thanks, @thadguidry, your approach makes sense, and I am aligned.

@thadguidry

I'd like to see Tom, if he is willing , to step right into this role,

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.

@thadguidry

Tom and Antonin are the only ones that have Repo Owner privileges now?

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).

[thadguidry]

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

[thadguidry]

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.

[antonin_d]

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.

@Martin

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.

Yes, that would be ideal.

[tfmorris]

The scope of this is so much bigger than just hiring a developer. During his years of involvement @antonin_d has grown from a junior developer to control almost every aspect of the project from software engineering to web site design to web site content to producing events to mentoring interns to hiring/firing to ... - well, it would be hard to think of an aspect of the project that he's not involved in. If he's really scaling back to zero, that will leave a huge hole to fill.

Hiring someone to do all that is a recipe for burnout (as Antonin can probably attest to). Hiring someone to immediately be a project leader or lead developer is unrealistic too. Better to start someone with a limited remit and grow them if they turn out to be a good fit.

| Martin
September 4 |

• | - |

This role will focus primarily on general maintenance tasks, such as managing the GitHub repository, triaging tickets, and reviewing pull requests

I would have thought that the primary focus would be bug fixing, security updates, and quality improvements. Once they're up to speed, release manager is a thankless role that could be offloaded to them too.
Triaging tickets could be done by a volunteer who is familiar with OpenRefine. It doesn't need to be a developer.
Merging PRs and managing the Github repository isn't going to happen until they've gained commit privileges, although they certainly can participate in PR reviews.

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?

Hiring is very difficult work. Typically a developer would be hired by a development manager who had experience in doing that kind of work (and hopefully a network of contacts which could be leveraged). Who is going to fill that role here?

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?

From the point of view of gaining commit privileges, there's nothing special about who they're employed by. They go through the same process as everyone else. As an aside, commit privileges aren't needed to be able to do useful work.

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?

The current team collaborates in a pretty loose fashion, so I'm not sure anything special is needed, but this person is going to need more than just "contractual aspects" managed. They will require technical oversight and active supervision by someone familiar with their work. I don't know how all this is done currently, so perhaps there's stuff going on behind the scenes that can be applied to the new person.

We want Antonin's replacement to start in 2025.

For the reasons I mentioned at the top, thinking of this as "Antonin's replacement" is a mistake, in my opinion.

Tom

[Martin]

@thadguidry

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.

I would prefer if we take this as an opportunity to read and challenge the new proposed governance.

@tfmorris

For the reasons I mentioned at the top, thinking of this as "Antonin's replacement" is a mistake, in my opinion.

I agree to stop thinking about it as Antonin's replacement and focus more on having sustained developer support. I like how the Django Foundation framed its fellow program.

I agree with @tfmorris approach:

1. Starting with bug fixing and security
2. Going through the regular process to grant more privileges (see draft governance about joining the core dev group). Not being part of the Core Dev group does not prevent the person from making meaningful contributions.

Currently, the Advisory Committee manages the contractual aspect and performs weekly check-ins. All conversations regarding the technical aspects of the project are public, so nothing happens behind the scenes.

@tfmorris

Hiring is very difficult work. Typically a developer would be hired by a development manager who had experience in doing that kind of work (and hopefully a network of contacts which could be leveraged). Who is going to fill that role here?

I can lead the process (job posting, resume triaging, outreach, scheduling, and performing non-technical interviews). For other hired roles, members of the Advisory Committee participated in some interviews. I would be more comfortable if a senior developer was involved in the process to validate technical skills. I can reach out to a developer I trust for that process, but I would prefer it if it is someone from the current committer group. It will also be a better experience for the candidate.

[Martin]

I open Create 2024-10-30-openrefine-developer-role.md by magdmartin · Pull Request #395 · OpenRefine/openrefine.org · GitHub with a first draft of the role description. Feedbacks are welcome directly via Github.

[Martin]

I am coss-posting here for visibility. Last week, I proposed a new version that focuses more on the developer relationship aspect of the position.

As we are already past mid-November, I would like to publish this soon. If there are no objections, I will finalize it and publish it next week.

[thadguidry]

There are a ton of folks that would jump at this opportunity... if we clarified what we mean by part-time:

1. Would you hire someone who has a full-time job already?
2. Would you hire someone that commits verbally to putting 80 hours a month (4 hours per day : 5 days a week ~ 4 weeks a month 80)
3. For some, depending on where you live in the world and culture, the phrase "Part-time" means that we would qualify the time against their quantity of time? or against the total time in a month (i.e. 9 months)?

[Martin]

@thadguidry, those are great questions. I understand part-time at ~20 hours/week, depending on the candidate's compensation and experience.

Since the position involves community management responsibilities, the person is expected to engage regularly to ensure comments, pull requests, and other community inquiries are addressed promptly. To clarify, we are not interested in someone working full-time for 18 weeks and then having no budget left for the rest of the contract.

Yes, I would be interested in someone putting in 80 hours per month with an engagement to keep an eye on their notification (except when the person takes holidays). I worded the job posting by average per month, so I am OK if the person works 10 hours a week and 25 hours the next two to bring the monthly average to 20 hours/week. If it does not reflect it clearly, I would be happy to reword it.