From 18cfb096ce130a6f0b1ee4486e479b72af2b9078 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sat, 8 Sep 2018 13:09:02 +0300 Subject: Drop: pm page --- pm.mdwn | 62 ------------------------------------------------------------ project.mdwn | 2 -- 2 files changed, 64 deletions(-) delete mode 100644 pm.mdwn diff --git a/pm.mdwn b/pm.mdwn deleted file mode 100644 index 98cc24f..0000000 --- a/pm.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -[[!meta title="Project management"]] - -This page describes the lightweight project management process for -development of vmdb2. 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, vmdb2 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 vmdb2, 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.) diff --git a/project.mdwn b/project.mdwn index 4fa140c..f9b0c3a 100644 --- a/project.mdwn +++ b/project.mdwn @@ -8,8 +8,6 @@ interested: * Project [[governance]]. * [[Code of conduct|conduct]] -* [[Process description|pm]] - * [[Current and past projects|projects]] * [[Development blog|blog]] (see [[feeds|blog_feed]] also). * [[consensus decisions|tag/consensus-decision]]. * [[formal decisions|tag/formal-decision]]. -- cgit v1.2.1