Changed meaning of the QA column (#92)

* Changed meaning of the QA column

Issues will now be closed when moved to QA. This will allow us to make more efficient use of GitHub's built in automation.

* Fix typo

about/process/issue-tracking.rst

@@ -14,7 +14,7 @@ distributed as with the system-image are tracked in the
 exception of this are click-apps that can be updated independently through
 the OpenStore.
 
-Most other repositories track isues locally. If you're unsure whether a
+Most other repositories track issues locally. If you're unsure whether a
 repository uses its own tracker or not, consult the README.md file.
 Repositories that don't track issues locally have their bugtracker disabled.
 
@@ -38,9 +38,9 @@ These are the standard columns:
 * **None (awaiting triage)**: The issue has been approved by a member of the qa team and is awaiting review from the responsible development team. if the issue is a bug, instructions to reproduce are included in the issue description. if the issue is a feature request, it has passed a primary sanity check by the qa-team but has not yet been accepted by the responsible development-team.
 * **Accepted**: The issue has been accepted by the responsible development-team. If the issue is a bugreport, the team has decided that it should be fixable and accepts the responsibility. If the issue is a featrue request, the team thinks it should be implemented as described.
 * **In Development**: A patch is in development. Usually means that a developer is assigned to the issue.
-* **Quality Assurance**: The patch is completed and has passed initial testing. The QA team will now review it on all devices and provide feedback. If problems are found, the issue is moved back to “In Development”.
+* **Quality Assurance**: The patch is completed and has passed initial testing. The QA team will now review it and provide feedback. If problems are found, the issue is moved back to “Accepted”.
 * **Release Candidate**: The patch has passed QA and is ready for release. In case of deb-packages that are included in the system-image, the patch will be included in the next over-the-air update on the rc channel, and, if everything goes well, in the next release of the stable channel.
-* **None (removed from the project)**: A patch has been released (issue closed with a message linking to the patch) or the issue has been rejected (issue closed and labeled “wontfix”).
+* **None (removed from the project)**: If the issue is open and labeled "help wanted", community contributions are required to resolve the issue. If it's closed, that means that either a patch has been released on the stable channel (a comment on the issue should link to the patch) or the issue has been rejected (labeled “wontfix”).
 
 Labels
 ------
@@ -102,7 +102,7 @@ To make it transparent who's working on an issue, the developer should
 be assigned. This also allows the use of GitHub's global filtering as a
 type of TODO list. For example, `this is everything assigned to mariogrip in @ubports <https://github.com/search?utf8=%E2%9C%93&q=is%3Aopen+org%3Aubports+assignee%3Amariogrip&type=>`_.
 
-Developers are asked to keep their list short and to keep the status of their issues up-to-date.
+Developers are encouraged to keep their list short and update the status of their issues.
 
 Examples
 --------
@@ -117,7 +117,7 @@ Bug Lifecycle
 
 - A *User* files a new bug using the issue-template.
 - The *QA-Team* adds the label **needs confirmation** and tries to work with the user to confirm the bug and add potentially missing information to the report. Once the report is complete a **team-label** will be added to the issue, the issue will be put on the **awaiting-triage-list** of the project and the label needs confirmation will be replaced with **bug**.
-- The affected *Team* will triage the issue and either reject (label **wontfix**, close and remove from the project) or accept (move to “Accepted”) the issue. If no team member can be assigned and the issue can be handled by the community, it is labeled **help wanted**. If possible, the team will provide hints on how to resolve the issue and further details on the how the fix should be implemented. For non-critical issues that are trivial to fix, the label **good first issue** can be added as well.
-- Once a *developer* is assigned and starts working on the issue, it is moved to “In Development”. As soon as he has something to show for, the issue is moved to “Quality Assurance” for feedback. If neccessary, the developer should provide hints on how to test his patch in a comment on the issue.
-- The *QA-Team* tests the fix on all devices and provides feedback to the developer. If problems are found, the issue goes back to “In Development”, else it’s closed and moved to “Release Candidate” to be included in the next release.
-- Once the fix is included in the rc image, the issue is closed and (if not done already) added to a milestone. Once the milestone is released, the issue is removed from the project.
+- The affected *Team* will triage the issue and either reject (label **wontfix**, close and remove from the project) or accept the issue. The team decides if it they will fix the issue in-house (move to "Accepted" and assign a team member) or wait for a community developer to pick it up (Label **help wanted**, remove from the project board and provide hints on how to resolve the issue and further details on the how the fix should be implemented if necessary). For non-critical issues that are trivial to fix, the label **good first issue** can be added as well.
+- Once a *developer* is assigned and starts working on the issue, it is moved to “In Development”. As soon as they have something to show for, the issue is closed and automatically moved to “Quality Assurance” for feedback from the QA team. If neccessary, the developer will provide hints on how to test his patch in a comment on the issue.
+- The *QA-Team* tests the fix on all devices and provides feedback to the developer. If problems are found, the issue is re-opened and goes back to “Accepted”, else it’s moved to “Release Candidate” to be included in the next release.
+- If not done already, the issue is added to the next milestone. Once the milestone is released, the issue is removed from the project board.