Topic: Tracking MultiBit work via github issues list. Milestones. (Read 1974 times)

As MultiBit is getting used by more people I have started using the github issue tracking / milestones feature more.

If you look at the MultiBit issue tracking:
https://github.com/jim618/multibit/issues?labels=&milestone=&page=1&state=open

You can see that I have started:

+ labelling issues by their type/ seriousness
+ there is now a Milestone for the next release (0.5.13).
+ Issues are assigned to the release - it is basically saying "These are the issues I plan to work on for the next release".
+ I have also put in a 3 week deadline for the release (as with all open source work this is a guessimate but it gives an idea of progress).


The way the master-develop branching strategy works is that you can also go from the github issue to the actual code changes that were implemented for that issue. Basically:

+ For each issue I create a git branch, say, "issue-180".
+ Work for that issue gets done in that branch.
+ When it works the code gets merged into the "develop" branch.
+ When the issues for the release milestone are all in the "develop" branch, a release branch gets created - say "release-0.5.13".
+ Once the "release-0.5.13" branch is all solid, it gets merged into the "master" branch and actually gets built, release tested and released. The release testing is recorded on the checklists I photo and upload.

At the moment this is slight overkill as it is mainly me doing the updates and merging (with Gary and Tim helping out). But it adds visibility to what is going on and can scale to more developers. It's basically what you do in companies to run your commercial software teams.