Project Maintainer Status

Development & Design
1

This message is primarily for current and recent developers on OpenRefine (@tfmorris @antonin_d @Sunil_Natraj @Rory @abbe98 @Antoine2711 @thadguidry among others)

With @antonin_d planning to become less involved in the project in the coming weeks, I want to understand who will be able to assist with the following tasks, initially identified for the Core Dev Group in the draft governance:

  • Merge pull requests
  • Publish releases
  • Review security vulnerability reports
  • Provide long-term project vision with the community
  • Are responsible for the technical direction of the project
  • Are part of the Admin team for the project on GitHub

Additionally, I would like to discuss how current committers can take on more responsibility within the project if they are interested. How can we make their progression through various roles more predictable?

My overarching question is about the state of the Core Dev Group. Is there interest in formalizing the group, and what are the criteria for becoming a member? If there is no interest in formalizing the group, how will we handle the abovementioned tasks?

2

I think it'd be good to formalize the Core Dev Group. I think these responsibilities will naturally fall to a smaller group within the Committers group, and being explicit about who is and is not part of that smaller group is important.
As for moving people between the phases, I think another responsibility of the Core Dev Group could be providing support for those interested in becoming more active in the project. I think that's implied in the current list of responsibilities, but I don't think it would hurt to have that stated explicitly.
Also, though I can't name a specific example at the moment, I believe I've seen other projects adopt a notion of senior members "sponsoring" individuals interested in becoming more active within a project. I think that could be something worth exploring as another way of formalizing the path from Committer to Core Developer. I will look for an example of this in other open source projects.

As for the responsibilities you mentioned above, I believe the first two items are the most pressing short-term needs for the project and can be fulfilled by committers. I'd like to volunteer to publish releases, and can commit to doing so as part of a regular office hours call for others to observe and participate.

1 Like
3

I also see value in having such a team, and having clear processes for getting in and out of such teams. Thanks for progressing this!

To me, the merging of PRs doesn't necessarily need to be a reserved to this core group, but could also be accessible to a wider range of people (as is currently the case). In other projects, I have been working with a two-tiered model:

  • the first tier giving access to the GitHub org, permissions to triage issues, review and merge PRs (but not your own ones) - corresponding roughly to the "committer" group we have in the existing governance model
  • the second tier corresponding to the core group you are proposing (with "owner" privileges on the GitHub org)

The idea of those two tiers being that it lets you grant access to the first tier very proactively, which is rewarding for people (they are part of the team, they can do more things) without bearing much risk for the project (most things can be easily undone). Granting those first permissions is in my opinion a good way to motivate people to stick around and feel more responsible for the project - which can eventually lead them to the second tier.

I'm keen to stand by to help @Rory review PRs in the coming weeks, with the goal of eventually having him part of the core group.

Another responsibility that I would attribute to the core group is that of proactively inviting contributors to join the tier(s), and facilitating their on/off-boarding.

I am also in the process of introducing a similar governance model in Wikidata-Toolkit, a Java library that OpenRefine depends on, to make myself redundant there too.

1 Like
4

Also, this could be a good opportunity for another attempt to contact @tfmorris, to check on his current intentions with respect to OpenRefine. As far as I can tell, I last heard from him in January.

1 Like
5

Since the last update on this thread @Rory started to take on more responsability by

@Rory is currently not performing the following:

  • Review security vulnerability reports
  • Provide long-term project vision with the community
  • Are responsible for the technical direction of the project
  • Are part of the Admin team for the project on GitHub
6

My apologies for being incommunicado for so long. I am happy to continue my role as a member of the core developer group and will try to get caught up on what has happened in the last few months over the next few days. Although it has been around since (at least) 2017, I think it's a good idea to formalize its description, membership, etc.

I'd like to see us simplify and rationalize our Github organization setup. We currently use a mix of teams, owners, and individual grants to manage things. I think we should move to a setup which is primarily/entirely team-based with privileges granted to teams and then members assigned to those teams.

The current teams are owners (a "virtual" team with 8 members), admins (6 members), Committers (72), and Designers (7). The union of owners + admins is 11 people. I think we need to review and pare back the owners list and add all remaining owners to the admins list for visibility (ie admins should be a superset, or identical to, owners). The openrefine-coredev mailing currently has four members (2 non-technical). This should get aligned/deduplicated as well.

Although from a technical point of view any member of the Committers team can review, approve, and merge a pull request, I think from a social contract point of view it's been a much smaller set of reviewers/approvers, principally Antonin, Albin, and myself I think we should align the teams and responsibilities with our actual practices and set things up so we aren't assuming that Antonin is going to review every merge (even if on a post hoc basis), which I suspect is part of the safety net for the current setup. In my opinion, the list of approvers should only include those who we're comfortable having operate completely unsupervised. Obviously our current list of 72 is much too big for this. Another variable we can play with on this front is how many reviews/approvals we require, but given how small our team is, I'm not sure increasing the number of required reviewers is feasible.

In the last 6 months, we've had 18 contributors (+2 bots), 22 (+2) in 12 months, and 25 (+2) in the last 24 months. The contributors count includes those who've contributed translations, but not code, so code contributors count is lower. I don't know what the timeframe should be, but I don't think developers should retain indefinite commit access if they haven't contributed recently. That's a significant unnecessary security exposure.

As I've mentioned in the past, I don't see issue triage as a technically sensitive responsibility and think we should set up a separate team for issue triage and solicit volunteers to help with this (following whatever guidelines that the project agrees upon).

I think it would be useful to clarify what membership in the OpenRefine organization is intended to convey, independent of team membership. Is it a reward for past contribution? Is it a signal that members speak for the project in some fashion? Should members who are removed from the Committers team retain their organization membership?

I'll see if I can collect data from the Github API to help make some concrete data-based decisions for this stuff.

Tom

ps. For reference the Github roles are:

All-repository read - Grants read access to all repositories in the organization.
All-repository write - Grants write access to all repositories in the organization.
All-repository triage - Grants triage access to all repositories in the organization.
All-repository maintain - Grants maintenance access to all repositories in the organization.
All-repository admin - Grants admin access to all repositories in the organization.
CI/CD Admin - Grants admin access to manage Actions policies, runners, runner groups, network configurations, secrets, variables, and usage metrics for an organization.
Security manager - Grants the ability to manage security policies, security alerts, and security configurations for an organization and all its repositories.

7

I'm only jumping in here to echo and show my support of @tfmorris suggestions and observations. Welcome back by the way!

8

Thank you for the feedback.

I wanted to provide some background information:

  • The openrefine-coredev mailing list has been replaced by GitHub for security disclosures.
  • At one point, we tried using Teams to communicate with multiple users at once

As I previously stated, I will not engage in the organization of the developer community. If you need my support as project manager to gather statistics or implement any changes once a consensus has been reached, please let me know.