Electing "Speciality" committers
The Eclipse Foundation Development Process does not make any requirements regarding the nature of the contributions that can be used to demonstrate merit in a committer election. Many (perhaps most or all) of the "good" examples of nomination statements that we cite, however, very specifically use the nominee's commit record as the basis for election. Overall, we've evolved a practice of valuing Git commits above all, and through that practice have reinforced Git commits as the only valid means of generating pattern of contribution.
For most of our committers, this is completely fine. Most of our committers' work is concerned with creating content for their project, and it is relatively easy to contribute content via merge or pull requests to publicly build a reputation with the project.
For what I've labelled as "speciality" committers, this is not as easy. It may be unnatural for a build engineer who is concerned with managing a Jenkins build to contribute content to a project via Git. Likewise, it may be difficult for a security expert who is concerned with creating security advisories and filing CVEs on behalf of the project team to contribute content in a public manner. It may also be the case that a security expert's role in a project is transient (but let's defer this scenario for now). With some imagination, we can come up with a list of other potential roles.
The Eclipse Foundation Development Process says this, in part, about committers:
Contributors who have the trust of the Project’s Committers can, through election, be promoted Committer for that Project. The breadth of a Committer’s influence corresponds to the breadth of their contribution. A development team’s Contributors and Committers may (and should) come from a diverse set of organizations. A Committer gains voting rights allowing them to affect the future of the Project. Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse member company or any company employing existing Committers.
Again, there is no mention of Git commits.
The EDP defines a committers as a "software developer who has the necessary rights to make decisions regarding a Project" (the inclusion of the adjective "software" may be problematic). It's tempting to think of the role of committer as being focused exclusively on creating content, that committer status need only be granted to those developers who require write access to Git, and that specialities are actually distinct roles. We may well decide that specialities are distinct roles at some point in the future, but this is not the case today.
Even if speciality roles become a separate concept, the fundamental principles of openness, transparency, and meritocracy that are described in the Eclipse Foundation Development Process will still apply, meaning that some public record of contribution will still be necessary to assign roles that have real influence over the project. That is, even if we do decide to split out additional roles, the fundamental problem persists.
Contribution can come in multiple forms. Engagement on project channels (e.g., issues, forums, mailing lists) to provide guidance to the team and assist members of the community should be considered contributions.
I believe that there may be basis to assert that a public record of providing a specific sort of service for one project could be used as a record of contribution to provide similar services for a related project.
There is also precedent for using a developers expert status in a related community as a record of contribution.
What I would like to do with this issue is provide a means by which the Architecture Council and entire Eclipse community can capture specific scenarios in which we've had a challenge in getting committer status for developer with speciality skills, and capture practices that have worked in the past as a basis for providing guidance to Eclipse project teams.