Hey Eclipse Automotive PMC.
The criteria that you provided to demonstrate reputation in committer elections in your
December 16 2025 message is, IMHO, excellent. Your criteria provides a very concrete set of examples that I feel that everybody in our community can benefit from. Thank you for capturing that.
I would like to explore how we can apply it specifically to committer elections that are tied to a significant single contribution. By way of background, the practice of onboarding committers when accepting a significant single contribution (citing the contribution
itself as evidence) is well-established, but occurs relatively infrequently, As
such, we haven't captured very much advice to help project teams do this
successfully. We've tried to provide some advice in the
handbook and in a
blog post, but I feel that these resources fall short.
Since this appears to be a scenario that we're encountering relatively frequently in the Eclipse Automotive projects, I'd like to work with you and the Eclipse Technical Advisory Committee (formerly the Eclipse Architecture Council) to establish some concrete advice for committers.
Here are some of my thoughts:
The process of offering and accepting a significant single contribution of content should itself be open and transparent. Tracking the contribution via an issue is an obvious way to operate transparently. The key is that the discussion between the contributors and the existing committers should be on a durable public channel.
URLs pointing to the discussion and the actual contribution (e.g., repository or pull request) should be included in any nomination statement.
A significant contribution may not include a complete history. The contributor may need to flatten the history for a variety of reasons. This would hide the activity of specific individuals, making it impossible to cite specific individual contributions.
I believe that it is natural to nominate the individual who offers the contribution, affirms that they are an established author of the content, and discusses the contribution with the project team on public channels as a committer. That is, I believe that it is reasonable to assert that by participating in the contribution process, the contributor demonstrates trust.
In the general case, we really want/need the established developers of the content in a contribution to join the project team and continue their work. Making individuals jump through hoops to prove that they understand content that they developed is wrong (having a committer accept pull requests from an individual who understands the content better than they do seems silly and pointless).
I like how you've listed "define trust" at the top of the criteria. I'd like to provide some advice for how a committer can assure the project team and the community that they can trust the developers of a significant single contribution.
Do you have a meeting coming up that I can join to discuss this? If it makes more sense, I can schedule a dedicated meeting to discuss.
Thanks,
Wayne
-- Wayne Beaton (he/him)
Director, Open Source Projects | Eclipse Foundation
