Postmortem notes

We held our first development post-mortem in-office. Here are identified problems and actionable items.

Problem: merges from mdc integration branches always led to instabilities

• Do frequent merges - for major branches, do a merge every week to keep the merges smaller.

• Have testers perform full regression testing after a branch has been merged into trunk.

Problem: minor features tend to be lost when it comes time to do release notes
Use Mantis' "Feature" severity categorization when a minor feature is added. This will help the release manager aggregate all feature changes at the end of each release.

Problem: we don't clearly define the scope of features, nor do we communicate changes effectively

• Create spec pages for each feature, and tag it to each release. Update this spec page when the feature gets updated. This will allow us to automatically aggregate this for releases.
• Write blog posts more often, with posts twice a week from somebody in engineering.

Problem: there's lots of //todos in the src code
Each todo should be associated with a bug report, so we have tracking items for getting them resolved.

Problem: Russian testers had broken API, and did not know
A checklist of things to look for after updateWiki.sh will give the Russians an idea that their host has successfully updated.

Problem: we can improve the release process; we set haphazard dates and oftentimes miss important steps
Write a formal release checklist which documents the steps (not just in engineering, but everywhere else) which allow us to release more consistently. This also goes hand-in-hand with our soft releases with release candidates weeks before the actual release. This helps iron out issues on non-standard systems and gives translators a chance to catch up before the release.

Problem: improve testing process
TBD, but we need to tie Daniil more closely to the QA process; Max suggested we run an automated build bot which will allow us to make sure the build is good, and that all unit tests are passing. Steve suggested having Daniil scan changes to the API documentation, to know when a feature has changed and requires updated test cases.

Problem: server changes need to be communicated - the /@gui/ problem
When making changes to Apache's rewrite rules, we should (a) communicate the changes more clearly, (b) update all install docs so fresh installs pick up the changes and (c) add software checks.

Problem: specific problem with UI cache
Send in version number, which will automatically invalidate [the cache] for us.

Problem: code cleanup/refactoring should be a consistent task
We should reexamine code and polish it occasionally when we learn how to do something better. For the API, code should be refactored to fit the SOA model more.