Drop: pm page

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]].