PMC project guidelines

This page is used to document project standards and guidelines.

Issues

With the move to Github the usage of issues and pull requests became relatively similar. PR and issues can both be commented on, referred to and linked to.

Hence the PMC decided that you do not need to create an issue for functional changes in case you can directly publish the code change as PR. Issues are still valuable for users to report issues or for changes which you plan to do in the future or at multiple steps etc. PR should be preferred in case you can, so that the discussion involves both the code change and the design.

We hope that this will reduce the noise the project members receive and remove additional steps in the process which do not add value. Most of the documentation of a final change should be in the commit message and the surrounding discussion can be captured either in the issue or the pull request.

Subprojects are free to require a separate issue for each PR if they agree that that is the best workflow for their area.

Commit messages

Each commit should be well documented via the commit message, the commit body should give an explanation why you are doing this change.

It is not sufficient to describe that in the PR or issue, it should be part of the commit message.

To be filled with guidelines regarding the UI updates removal of unmaintained functionality and other topics.

Code of conduct

Community Code of Conduct

Committer disagreement resolution

In the case committers disagree on a code change or another change they should:

Ask a Project Lead(s) for resolution on the topic.
Project Lead(s) should clearly state their resolution is as Project Lead to eliminate chances that people are not aware of hierarchy.
In case of disagreement with a Project Lead issue, the issue can be brought to the Eclipse PMC for decision by the disagreeing party.
The Eclipse PMC decision may be overridden via a project-wide vote on the issue.
A disagreement with the PMC may be escalated to the EMO and beyond as described in the Eclipse Foundation Project Handbook's grievances section.
At any point a committer may decide to ask for majority vote on an issue. It MUST BE held on the project development list and must be clearly marked as such e.g. by prefixing mail subject with [VOTE]. This will only be valid if a majority supports one of the proposed solutions.

Committing changes in case of pending concerns from committers without the above process should not happen. If they are committed by accident or because of a misunderstanding, these changes should be reverted and a new change with the original changes re-created so that the discussion can continue.

If changes are merged and someone finds later an issue with these, they should not be reverted without following the above guidelines, i.e. the person who did the change should have to opportunity to comment.