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