CommitterResponsibilities

Introduction

In Umple, we follow a policy of making graduate students and a few other into committers once they have a history of successfully contributing. That means you can merge pull requests.

Currently the project owners (primarily Dr. Lethbridge) choose who will be made committers. Once made a committer you are left in that state unless you request to have the status revoked, or you foul up a commit in a significant way (break the build or commit poor quality code) and don't immediately repair the damage, or are not active in Umple for over a year. However people who have made major contributions will normally remain permanently.

When first made a committer

When first made a committer, you will need to read the responsibilities below and remember to follow them from now on.

As a committer you must still contribute through pull requests. Unless urgent, have someone else review them. And always wait for a Travis build do complete before merging.

Responsibilities

Your responsibilities are:

1. To participate in project discussions on umple-dev where you have ideas, information or contributions that others have not mentioned, and to participate in any votes when asked (e.g. to admit new committers, or for making important architectural or process changes).
2. To consult with Dr Lethbridge and those on the umple-dev mailing list about design issues if you have any doubts about changes you are planning to make.
3. To help review the pull requests of others. We may ask you to review and commit specific pull requests.
4. To ensure you have the right to contribute any code you are adding to Umple (e.g. you wrote the code, or the code has a license that is compatible with that of Umple -- No GPL-licensed code in particular can be added).
5. To do git pull and resolve conficts before starting work each day, before commits and whenever anybody announces a change has been pushed to master.
6. To keep your pull requests as small (agile) as reasonable.
7. To ensure you follow the test-driven development process; and to include tests at all needed levels in any commit.
8. To write efficient, well commented code that considers all necessary cases.
9. To do a full build (ant -Dmyenv=local) before making any pull request or merging any pull request to master, in order to be absolutely certain that it will work, then to do a) Check the qa page (dist/qa/ ) to ensure all tests have passed, and b) git status to ensure you know you are contributing the correct files.
10. To do a manual test of your code before creating a pull request or pulling into master (not just to rely on the automated tests because they may be absent, commented out, etc.). You can do this using the command line version of the compiler you build that is found in the dist directory, or else using a local version of UmpleOnline (but in the latter case you need to deploy your changes to it)
11. To include all necessary files in the pull request (but not any generated code that would be replaced in any build).
12. When you pull into master, to closely watch the build machines at Jenkins and Appveyor and make sure the build passes. Builds are triggered a few minutes after each push. If it goes 'red' (fails) you have to solve the problem (with another pull) before moving on to any other task. Often the matter is that you forgot to include a file.
13. Once the build on the server passes for a significant change, announce the change to everybody at umple-dev, update the issue with a comment mentioning the revision number and status mostly-done, etc.. Don't mark the issue as 'verified' however. It is only project owners that do that after sufficient code review.

It is also suggested that if you have any doubt about a change, ask others to review your pull request