I don't recall exactly how I found
this (somehow via more feeds, pythonic, twisted, ...). It describes
a development method that relies on tickets and branches. For each ticket there is (was) a branch, dealing with this ticket.
The briefest summary of the requirements for UQDS is that every task has 3 absolutely required steps.
- A task is created in an issue tracker and assigned to a worker.
- The worker does work, and creates a change-set to be applied to the mainline revision control system. (This can be represented as either a branch or a patch file.)
- A reviewer reviews the completed work, and provides feedback: at least one good thing about the work, at least one area that needs improvement, and a judgement as to whether the good qualities ultimately outweigh the bad, i.e. whether the branch should be merged.
It seems like a very formal way. But I have seen worse, involving paper forms, weekly meetings and such. For me this UQDS sounds very intriguing and I want to try it in our company. This kind of development system goes very well with my personality.
As far as the overhead goes, I'd rather have overhead that results in better code than have an "afterhead" when having to deal with the results of bad code.
