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"...
- A better communication on migration process/steps plus what to expect would have been helpful +1 +1
- A Plan B is prepared to handle emergency when the users of community are significantly impacted +1 +1
- Was there an "acceptance criteria" after the migration? +1 +1
- A call for more volunteers to help with the migration would have been a good idea. +1
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)
Requirements (such as "keep old links working") were not gathered before the migration, but raised afterwards when it was difficult to address them +1
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
Changing DNS site name of old site (like home.opnf.org) 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
- More community visibility into the staging activity as a way of making the process clearer could have helped
- A clearer presentation of the final execution plan with detailed steps and likely interruptions may have helped set expectations +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
- A wiki page documenting the move, used as a workspace, would have allowed visibility by people not in the wiki team
- Execute it as a project release.
- Plan well ahead with a project plan of timeline, milestones, available resources, risk analysis and mitigation.
- Have a Plan B to handle emergency cases +1 +1
- Communicate with community regarding the project plan and get buy-in from community
- 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
- 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?)
- Use email to mailing lists and wiki pages as primary communication channel to communicate work in progress
- Real-time meetings with limited attendance are not a good way to recruit volunteers/reviewers