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.