What are the committers now?
I think we should strongly reconsider the concept of committers.
Before Foundation/Corporation formation the committers were the people who brought a lot of contributions into the project code. This was the rule the team was initially created in 2015(?) and separating of OTC was an option to create 2 levels of involvement, and it also changed in process of formation of the Foundation and the Corporation. Now all committers are equal, at least from the PR approval perspective.
When the Corporation and the Foundation were created, we've got much more contributors and contributions from the people hired in the project. It's the way it should work, at some moment I expect a lot of them should join the committers. I don't understand how it should work. I don't think it should be a decision of Corporation/Foundation. TACs may be a group managing this stuff.
On the other hand, it seems to me that it would be sort of weird if the majority of committers would be regular hires. I think that the committers should represent the current stakeholders and be actually involved in the project (the rule of reviewing several contributions works for this, at least of now). By design committers are specifically technical community, and the members of it are expected to be much more involved in technical details.
Item removed
Dmitry Belyavsky Mon 11 Aug 2025 5:29PM
@Richard Levitte Is the Apache Way described somehow so I could read and understand what you mean better?
Neil Horman Mon 11 Aug 2025 12:13PM
I suppose I would split this into two questions:
1) What are the responsibilities and roles of the committer group?
2) What (if anything in addition to (1)) should those roles and responsibilities be?
I personally take (1) to be defined by the ACL granted by being part of the committer group. That is to say, that being a committer means you have the right (and consequently the obligation) to review and approve pull requests, as well as the operational duty to merge those pull requests once approved
Contrast that to the TAC, which has no such direct operational mandate, which focuses on technical strategy (i.e how we implement various features at an architectural level), rather than day to day operations.
As for the answer to (2), i'm not sure it needs to be anything more than what it is currently. i.e. its a group of people that move the project forward in a day to day fashion by interacting with github to get new code where it needs to be. The only suggestion I would make is that we need more of them. Currently we have 306 open pull requests and about 1700 open issues, some of which are more than 10 years old. Increasing the pool of people that are authorized to review PR's and address issues in a way that we consider actionable (i.e. people whos approval impacts our review state machine) would help us drive down those numbers. As to where they should come from, it should be everywhere we can find them. The more we have, the more likely that we have someone who is a "stakeholder" as you describe regarding a given issue. Pragmatically speaking, creating committers from individuals who are employed by openssl (the corporation or foundation), makes sense, as those individuals can be directed by management changes to prioritize various issues, but yes, they should generally come from the community at large if we can find and recruit them.
Tomas Mraz Mon 11 Aug 2025 12:24PM
I agree with @Neil Horman . IMO the rights and responsibilities of the group are well defined and should stay as they are apart from maybe tightening the rules around regular activity required to keep the committer status. And yes, we need more active committers, not necessarily more committers but infrequently active ones.
As for the process of approving new committers - currently the approvals of new committers are done by Boards of Directors of either Corporation or Foundation as that is where all the responsibilities went from the disbanded OMC and OTC. As TACs are advisory boards they cannot directly approve committers, but it would be a good idea to make the TACs responsible for nominating new committers to the respective boards.
Shane Lontis Tue 12 Aug 2025 12:37AM
I am wondering if we need another category here related to people that could be specific category reviewers as opposed to committers.
A good example of this may be people with assembler knowledge (RISC for example).
Richard Levitte Tue 12 Aug 2025 10:27AM
Not sure reviewers need to be a distinct group. Anyone can review a PR, and we sometimes do have individuals we don't know, or only recognize by their github handle, who perform reviews.
Richard Levitte · Mon 11 Aug 2025 11:19AM
Not sure I see how you want it to be changed. Committers were, and as far as I'm concerned, still are the set of people responsible for approving and committing contributions to the source repository/-ies. In a sense, they are gatekeepers.
Strictly speaking, being a committer doesn't imply making contributions, even though many of us are contributors and committers at the same time.
For reference, I derive my thoughts from the Apache Way, which I hope is sensible, as we've taken quite a bit from there.