| ... | ... | @@ -31,7 +31,7 @@ Accepted bugs go into the Development workflow. |
|
|
|
|
|
|
|
### Development Workflow
|
|
|
|
|
|
|
|
> This is an overview over the process outside our [[Source control policies]] which follow [this branching model](nvie.com/posts/a-successful-git-branching-model/).)
|
|
|
|
> This is an overview over the process outside our [[Source control policies]] which follow [this branching model](nvie.com/posts/a-successful-git-branching-model/).
|
|
|
|
|
|
|
|
For each Accepted bug, the developer identifies the problem and/or *outlines a design* to address the issue. Once a design outline is complete, the developer marks the issue as **Ready for Development** and notifies the team. For simple issues, the developer may be able to outline a design in the issue, and setting the status is mostly a heads up to avoid conflicts. For more substantial issues, the developer is responsible for leading a discussion on mathjax-dev, writing design pages here, and obtaining consensus on the implementation plan. In these cases, setting the status to Ready for Development is a "last call" and denotes the end of the design phase.
|
|
|
|
|
| ... | ... | |
