diff options
author | Mark Pundsack <mpundsack@gitlab.com> | 2016-04-21 04:11:22 +0000 |
---|---|---|
committer | Mark Pundsack <mpundsack@gitlab.com> | 2016-04-21 04:11:22 +0000 |
commit | 4a61c0525dd1dc831dc7baec5c5b710d536c5cc5 (patch) | |
tree | dae23daec53f4fbcbc62aa445fda60b20a9bd1a0 | |
parent | 2ade37e2534108c72d28605cb131dacf771d27d3 (diff) | |
download | gitlab-ce-4a61c0525dd1dc831dc7baec5c5b710d536c5cc5.tar.gz |
Update PROCESS.md
Fix grammar by adding missing "we"
Add extra newline so example isn't part of list.
-rw-r--r-- | PROCESS.md | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/PROCESS.md b/PROCESS.md index cad45d23df9..44413ea0532 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -59,7 +59,7 @@ core team members will mention this person. Workflow labels are purposely not very detailed since that would be hard to keep updated as you would need to re-evaluate them after every comment. We optionally -use functional labels on demand when want to group related issues to get an +use functional labels on demand when we want to group related issues to get an overview (for example all issues related to RVM, to tackle them in one go) and to add details to the issue. @@ -73,6 +73,7 @@ in support or comment for further detail. Do not use `feature request`. - ~bug is an issue reporting undesirable or incorrect behavior. - ~customer is an issue reported by enterprise subscribers. This label should be accompanied by *bug* or *feature proposal* labels. + Example workflow: when a UX designer provided a design but it needs frontend work they remove the UX label and add the frontend label. ## Functional labels |