Page tree
Skip to end of metadata
Go to start of metadata


Please add your thoughts/feedback on the recent wiki migration below (feel free to add +1's if you agree with anything already listed).  Remember to follow the usual guideline for post-mortems i.e. "no blaming or personal attacks"...


  1. A better communication on migration process/steps plus what to expect would have been helpful +1 +1
  2. A Plan B is prepared to handle emergency when the users of community are significantly impacted +1 +1
  3. Was there an "acceptance criteria" after the migration? +1 +1
  4. A call for more volunteers to help with the migration would have been a good idea.  +1
  5. Changes which affect the entire developer community should work through multiple staging steps, to minimise disruption (at least one staging step... like item 8 below +1)

  6.  Requirements (such as "keep old links working") were not gathered before the migration, but raised afterwards when it was difficult to address them +1

  7. Projects like this need to have a workspace, with discussion happening in the community forums, to allow people who are not on the call when the initial call for volunteers goes out to join in afterwards. +1

  8. Changing DNS site  name of old site (like with associate page links renamed prior to migration would have helped have both old and new to allow a cutoff over a few weeks.+1


Planning / Execution

  1. More community visibility into the staging activity as a way of making the process clearer could have helped
  2. A clearer presentation of the final execution plan with detailed steps and likely interruptions may have helped set expectations +1 +1
    1. At a minimum: A walk-through presentation of the stepsto migration at a TSC meeting would have allowed people to raise concerns and slow down the process
    2. A wiki page documenting the move, used as a workspace, would have allowed visibility by people not in the wiki team
  3. Execute it as a project release.
    1. Plan well ahead with a project plan of timeline, milestones, available resources, risk analysis and mitigation.
    2. Have a Plan B to handle emergency cases +1 +1
    3. Communicate with community regarding the project plan and get buy-in from community
    4. If there is insufficient resource to execute or high risk, postponing the execution is better than chaos until resources are sufficient and risks are mitigated +1 +1
    5. Execute Plan B when emergency happens unexpectedly to minimize the impact on community users +1 +1

Generating greater community buy-in to change (in general, how do we avoid having these things be short-handed?)

  1. Use email to mailing lists and wiki pages as primary communication channel to communicate work in progress
  2. Real-time meetings with limited attendance are not a good way to recruit volunteers/reviewers
  • No labels