* Make a separate branch for each issue or contribution you want to
have, so it's easier to merge changes in. Multiple contributions
should only be in the same branch if the later changes depend one the
first ones. Small, minor changes (such as minor code cleanups) can be
an exception to this.

* Post the branch with your contribution in the appropriate issue
ticket. If there is no issue open, create one, but if it is a large
contribution then it's probably best to post about in the groups
first, to discuss it.

* Focus contributions on product value (stuff that actually improves
DDT for users). No half-done user functionality, unless half is
significantly better than what there before.

* Also, if a contribution changes existing functionality from a user
perspective, in a way that is not an objective improvement, best to
discuss in the groups first, to make sure the UX changes are actually
desirable.

* Be mindful of the costs of reviewing your contribution.
Contributions should be well thought out and well tested (preferably
with automated tests). Writing code carelessly and hoping for the
reviewer to fix mistakes is a bad approach.

* Also, no big, complex refactorings just for the sake of it. If
someone has to review your refactoring changes for them to be
accepted, then refactorings must be tied to some code changes with
value, like bug fixes, or new functionality. Even if no one has to
review your changes, it's generally not a good idea to do complex
refactorings - that can potentially introduce bugs - if you are not
going to make use of that refactoring now or soon after.

Thanks for clarifying things. I will look into how I can split my code base
to separate the unrelated changes from each other. That's bit of a dive in
the gut of git. :) Since I progressed the most on the ANTLR parser recently
that would be the only feature that will worth to keep up with, and I will
isolate it from the rest of the code changes that is not directly relate to
it.

If I may ask, could you post these guidelines in the wiki also, just to
have everything for the development in one place? And only one more thing:
if you could specify some basic rules for the regression/unit testing, that
would help a lot. I'm thinking of things like to place the test code, what
sort of basic patterns are there to follow.

On 13 January 2012 17:23, Bruno Medeiros <bruno.do.medei...@gmail.com>wrote: