ContributionProcessToUmple

TCLethbridge edited this page Jan 17, 2017 · 10 revisions
Clone this wiki locally

FIXME

Introduction

The following are the key software engineering best practices to be used by all developers contributing to Umple. See this page for information about the current development activities in Umple.

See also a sequential list of steps to follow when contributing

And read the user manual and learn about the Architecture of Umple before attempting to contribute.

You will want to read the instructions for downloading the command line and Eclipse versions of Umple, as well as reading instructions to get set up to develop.

Best Practices

E1. Become an Umple user and learn about using it thoroughly before attempting to contribute. In particular, learn and apply the philosophy and vision as well as the best practices for using Umple

E2. Follow strict test-first development in everything you do. This means:

  • When developing a new feature (or change), first create test cases to demonstrate the absence of the feature (which will initially pass), then create the test cases for how the feature will work (that will initially fail - although will be expected to do so so this won't break the build), then implement the feature in the smallest possible increments, testing and committing as you go without breaking the build.
  • When fixing bugs, follow a similar path, but add a test to test for the absence of that bug.
  • Don't just do unit tests, contribute to our set of testbed systems and build other large systems using your Umple features so they can be system-tested and tried out in practice.

E3. Build and test the entire system locally before committing changes. Check the CheatSheet for hints.

E4. Use Umple in essentially all code you write, not Java.

E5. Document your code. in particular, use proper comment blocks at the beginning of each file, informative comments where necessary in the body, and Readme.txt files in directories.

E6. Update the user manual and the architecture document as you make changes

E7. Add appropriate entries to this Wiki as you need to record important knowledge. Make sure you properly categorize the wiki entries to keep the wiki organized.

E8. Use the umple-dev mailing list for discussion of all changes.

E9. Use proper issue tracking. This includes categorizing all issues properly, closing them out when done, and opening issues or assigning them to yourself before making any changes.

E10. Seek code reviews of pull requests, and review the work of others.

E11. Strive to make the design and code of Umple ever more understandable to others.

Avoiding and Dealing with a mess

To avoid getting messed up, and to recover from a messed up environment, see the following page: Avoiding Mess In Development Environment