diff options
author | Lars Wirzenius <liw@liw.fi> | 2018-09-08 13:09:02 +0300 |
---|---|---|
committer | Lars Wirzenius <liw@liw.fi> | 2018-09-08 13:09:02 +0300 |
commit | 18cfb096ce130a6f0b1ee4486e479b72af2b9078 (patch) | |
tree | 3ccc10461fda56eda42596118d9a112e06998731 | |
parent | 5d33aa0122816ab8eaae95c0a8c49d3c75c42614 (diff) | |
download | vmdb2.liw.fi-18cfb096ce130a6f0b1ee4486e479b72af2b9078.tar.gz |
Drop: pm page
-rw-r--r-- | pm.mdwn | 62 | ||||
-rw-r--r-- | project.mdwn | 2 |
2 files changed, 0 insertions, 64 deletions
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]]. |