Sketch out anything in the Wiki and prepare for making it
something people can look at. Put it on the proposals page: http://docs.codehaus.org/display/MAVEN/All+Proposals Put the proposal up for a vote to see if people agree. All these
can be vetoed as it's a technical decisions. You're good to go,so you can start the process of implementing
your changes. Create a feature/change branch and start working on your code.
Putting a link to your work in progress in the Wiki. The goal is to
never destabilize the main line be that the trunk of version branch.
Ok, so the new features start on trunk but the new feature is a
branch of trunk. The point being feature additions don't destabilize
the trunk. The series of branches associated with issues also
provides a clear path of what happened, branches named with something
like MNG-123-AndMaybeSomeQuickDescription make it easy to know what
it is and to look up the issue. For dead simple fixes things can go
into the trunk but anything requiring more then a few hours of work
should go into a feature branch of trunk. When it's merged back into
trunk, if it's possible it is then merged back into any version
branches (like 2.0.x). You now document the new features or changes that you have
implemented and detail and compatibility issues. You must have at
least one other core committer review your changes to be deemed
as complete. You move your proposal to the approved proposals section of the
Wiki and it becomes a record of the evolution of Maven. | 