[[!meta title="Project management"]] This page describes the lightweight project management process for development of Ick. Participation is voluntary. Iterative development process ============================================================================= Iterative development seems to be the only thing that makes sense in order to produce working software that fills what users actually need. Otherwise, you don't get any feedback until at the end of the development period, when things should already be mostly finished. With iterations, you do a little bit of work, show that to relevant people, get feedback, and incorporate the feedback to future work as seems most sensible. There's a ton of methodologies to do iterative development. Scrum is currently popular. However, Ick needs to be fun, and Scrum seems too heavy-weight for fun. Instead, this nearly informal process is what [[people/liw]] wants to use. * Iterations are a calendar week. * Start iteration with a short planning meeting, where goals are discussed and decided upon, and tasks outlined, and everything's written down. The tasks should be specified with a clear scope, and with enough detail to estimate that they can be done. Large tasks should be split down into small tasks, preferably into tasks less than an hour each. Only allocate enough tasks that they can all be completed with a high likelihood. It's always OK to do more, but it's de-moralising to never complete everything. * End the iteration with a short retrospective meeting, to summarise what was done (from the planned list of tasks or otherwise), and reflecting on the process to improve it, as necessary. * Write down decisions, in a meeting note in the intrawiki blog. * Estimates are done by the person who'll be doing the work. They should not be optimistic. Development workflow ============================================================================= * Work should be done in feature branches, but merged frequently to master. Unfinished features should be disabled, via some sort of feature toggle. Merging branches only after a long time means there's more pain during merge, and it takes longer until there's feedback on the changes in the branch from, say, CI, actual use, or code review. * Work for Heat/Ansible stuff should also be merged frequently, and any affected production systems (`infra-*` stacks) should be deployed after merge is done. The master branch and what actually runs in production should never be far apart. * Merging should ideally involve review. However, as there's only the one actually working on Ick, review would slow things down too much. Thus, we'll probably not have review for the time being. (Hint: contributing reviews would be a useful thing to do.)