[#10626] Update docs post organisation review (#10628)

docs/issues.md

@@ -17,18 +17,18 @@ Colors indicate which roles are involved in which states/transitions.
 This portion will only describe the purpose of each *label group* briefly.
 The full description of each individual label can be viewed under the [labels page](https://github.com/TEAMMATES/teammates/labels).
 
-* **Status (`s.*`)**: Classifies issues and PRs based on **status**
-  * No `s.*` label and no other labels in issue: issue is yet to be triaged
-  * No `s.*` label and other labels present in issue: issue is accepted
+Grouped Labels
+* **Status (`s.*`)**: Classifies PRs based on **status**
+  * No `s.*` label: PR is yet to be triaged
 * **Category (`c.*`)**: Classifies issues and PRs based on **type of work done**
 * **Priority (`p.*`)**: Classifies issues based on **importance**, as determined by the project maintainers
-* **Difficulty Level (`d.*`)**: Classifies issues based on **difficulty level**
-  * No `d.*` label: variable difficulty level, typically between `d.Contributors` and `d.Committers` level
-* **Aspect (`a-*`)**: Classifies issues based on the **non-functional aspect**
+* **Aspect (`a-*`)**: Classifies issues based on the **aspect**
   * No `a-*` label: no specific aspect tackled, usually the case for enhancements or new features
-* **Feature (`f-*`)**: Classifies issues based on the **functional aspect**
-  * No `f-*` label: no specific feature tackled, usually the case for refactoring
 * **Technology (`t-*`)**: Classifies issues based on the **technology/tool stack** involved
   * No `t-*` label: usually documentation update, or mixture of many languages
-* **Effort Estimate (`e.*`)**: Indicates the **estimated number of hours** needed to work on the issue
-  * `e.n`: `n` hours estimated effort, e.g. `e.1` is 1 hour, `e.2` is 2 hours, etc.
+
+Standalone Labels
+* `enhancement`: Indicates new feature requests that have been accepted
+* `good first issue`: Indicates a good issue for first-time contributors
+* `help wanted`: Issues that should be tackled by project contributors
+* `committers only`: Issues that should only be tackled by committers

docs/overview.md

@@ -6,7 +6,9 @@
    Biggest = many contributors, many users, relatively large code base (150k-200k LoC), evolving over a long period.<br>
    "Biggest" above also implies an exceptionally high quality standard because high quality is a necessity for the long-term survival of a big student project.
 
-1. To become **a model and a training ground for Software Engineering students** who want to learn SE skills in the context of a non-trivial real software product.
+2. To become **a model training ground for Software Engineering students** who want to learn SE skills in the context of a non-trivial real software product.
+
+3. To become the most flexible free peer feedback tool on the web.
 
 ## Challenges
 
@@ -24,7 +26,7 @@ The project differs from typical student projects in the following areas, which
 ## Principles
 
 We apply these principles to meet the challenges stated above.
-+ **We keep moving forward, always**: We release frequently, in weekly [time-boxed iterations](http://en.wikipedia.org/wiki/Timeboxing). Every week, our product becomes better than the previous week. This means "go back and rewrite from scratch" is only a last resort.
++ **We keep moving forward, always**: We release frequently, in [time-boxed iterations](http://en.wikipedia.org/wiki/Timeboxing). Every iteration, our product becomes better. This means "go back and rewrite from scratch" is only a last resort.
 + **We are agile**: We are able to change the system quickly and easily to match emerging requirements. We aim for **minimal yet sufficient documentation**.
 + **We defend our code with tests, fiercely**: Since we practice [collective code ownership](http://www.extremeprogramming.org/rules/collective.html), we have to make sure the code is not accidentally broken by others. We use fully automated regression testing. The testing automation level of this project is probably higher than 99% of the projects out there.
 + **We are "Gods" of the few tools we use**: We stick to a minimal toolset. Adding third-party tools and libraries to the project is done only if there is a STRONG justification. Only mature, stable, and well-supported tools are considered. Once selected, we should know the tool very well to get the best out of it.