My sense is that any changes to a Project's source code is
something that can be reviewed/handled following "normal Project
development practices". Where broader opinions on significant
changes are desired by the Project lead(s), the Project lead(s)
should solicit those opinions from their committers/community in a
way that will generally get the attention of the appropriate
audience, e.g., post a link to the Project's dev-mailing-list with
a reference to a Bugzilla, a poll, or a Gerrit review. In the
end, the Project lead(s) are responsible and empowered to decide
what is best for the Project. It's very nice when the Project
lead(s) consider the the input from the Project's
committers/community, but that's not strictly required. So I
don't think you should look for a formalized way of collecting
On 02.12.2019 23:18, Filip Jeremic
I'm a committer on the Eclipse OMR project .
The committers along with the community have discussed (with
general agreement) reformatting the entire source code
repository using clang-format automation. Given such a change
will affect everyone working on the project it falls in the
realm of adhering to an official committer vote. We are having
trouble finding concrete information of how to properly
conduct such a vote.
The Eclipse Project Handbook , along with the
Eclipse Development Process section 4.7 are the relevant notes
we were able to find which say:
> Committers are required to track,
participate in, and vote on, relevant discussions in their
associated Projects. There are three voting responses: +1
(yes), -1 (no, or veto), and 0 (abstain).
Voting on new committers via the Committer
Election process is explicitly stated. However this formatting
change we are going to propose is not a Committer Election, so
we are not sure how to properly count the committer votes.
Does votting on such a matter adhere to the same rules as a
Comitter Election? Depending on votes on such a proposal are
counted will influence the scope of the proposal itself as one
may choose to propose smaller or larger scope changes which
may have a higher chance of succeeding, depending on how votes
Some explicit questions:
1. Does anyone have a reference to some guidance
or examples on how such votes should be conducted?
2. Do individual projects have the freedom of
establishing a Project Charter which explicitly defines how
such votes are to be conducted (similar to the Eclipse IDE
Project Charter )?
- If so how is such a Charter initially
incubation mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit