Filip,
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 opinions.
Regards,
Ed
On 02.12.2019 23:18, Filip Jeremic wrote:
Hi everyone,
I'm a committer on the Eclipse OMR project [1]. 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 [2], 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
are counted.
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 [3])?
- If so how is such a Charter initially established?
[1] https://projects.eclipse.org/projects/technology.omr
[2]
https://www.eclipse.org/projects/handbook/#4_7_Committers_and_Contributors
[3] https://www.eclipse.org/eclipse/eclipse-charter.php
Regards,
Filip Jeremic
_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/incubation
_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/incubation
