Draft a release process

We need to find a good solution/process for new releases of MathCAT. We will use this issue to discuss and to start drafting a release process. Below are the key points from the discussion in the working group meeting on June 17.

Questions for discussion:

- How often should we do a release?
- What should be the process around a release? A beta version for AT to test? User testing?

A few points from the discussion:

- Ask the companies using MathCAT what they would like. This could be part of the "outreach to companies" work. Develop a list of what companies to notify.
- A release candidate and period where people can test, catch up with localizations etc. Companies using MathCAT could have a short period where they can test a new release, to make sure nothing breaks. Companies are depending on things to work, and they often do extensive testing before implementing something.
- How many big releases should we have during a year? Testing with real users takes time. User testing is important, but we don’t want it to slow things down. With a fast cadence, if there's a problem, we can fix it right away. The tests in MathCAT make sure the translations don’t break.

@NSoiffer , @ways2read , @avneeshsingh

No files, tests, or entry points are named; start by reading the discussion and the June 17 working-group notes in this issue. Clarify release cadence, beta or release-candidate testing, localization timing, user testing, and company notifications. Done means the agreed release process is documented and the open questions have decisions.

Written by the indexing model from the issue text.