... | ... | @@ -37,7 +37,7 @@ When development begins, the issue is moved to **In Development**. |
|
|
|
|
|
When development is complete, the developer prepares a **testing branch** (see the [[source control plan]]) and again notifies the team and tags the issue as **Ready for Review**. A typical way of handling this in open source projects is that at least one senior project developer has to review and sign off on all new work. The code is also tested in the testing branch. If problems arise, they may spawn new issues, or merely send the original issue back to **In Development**. Ideally, at least one automated test should be written to check the issue and in that case the QA flag is changed to **In Testsuite**. If that's too difficult or not necessary, the QA flag may be changed to **Do Not Write Automated Test** and the issue is then only tested manually.
|
|
|
|
|
|
Once the issue is tested, it goes to **Ready For Release**. Issues in this state are complete, but have not been merged into the master or release line for which they are destined yet. For now, [Davide](https://github.com/dpvc) will be responsible for making all merged of Ready For Release issues into the MathJax repo.
|
|
|
Once the issue is tested, it goes to **Ready For Release**. Issues in this state are complete, but have not been merged into the master or release line for which they are destined yet. For now, [Davide](https://github.com/dpvc) will be responsible for making all merges of **Ready For Release** issues into the MathJax repo.
|
|
|
|
|
|
Once an issue has been merged, it will get the **Fixed** tag, and **Closed**.
|
|
|
|
... | ... | |