kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Improving copy of CONTRIBUTING.md, PROCESS.md, and code_review.md

Browse source 
Signed-off-by: Rémy Coutable <remy@rymai.me>
This commit is contained in:
Rémy Coutable 2017-05-04 09:02:39 +02:00
parent cb87903c6e
commit 38c29f8775
No known key found for this signature in database
GPG key ID: 46DF07E5CD9E96AB
3 changed files with 11 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
CONTRIBUTING.md
View file

@ -136,7 +136,7 @@ and ~"direction".
A number of type labels have a priority assigned to them, which automatically
makes them float to the top, depending on their importance.
Type labels are always lowercase, but can have any color, besides blue (which is
Type labels are always lowercase, and can have any color, besides blue (which is
already reserved for subject labels).
The descriptions on the [labels page][labels-page] explain what falls under each type label.
@ -153,7 +153,7 @@ issue is labelled with a subject label corresponding to your expertise.
Examples of subject labels are ~wiki, ~"container registry", ~ldap, ~api,
~issues, ~"merge requests", ~labels, and ~"container registry".
Subject labels are always colored blue and all-lowercase.
Subject labels are always all-lowercase.
### Team labels (~CI, ~Discussion, ~Edge, ~Frontend, ~Platform, etc.)
@ -167,8 +167,8 @@ The current team labels are ~Build, ~CI, ~Discussion, ~Documentation, ~Edge,
The descriptions on the [labels page][labels-page] explain what falls under the
responsibility of each team.
Team labels are always colored aqua, and are capitalized so that they show up as
the first label for any issue.
Team labels are always capitalized so that they show up as the first label for
any issue.
### Priority labels (~Deliverable and ~Stretch)
@ -255,12 +255,9 @@ every quarter.
The most important thing is making sure valid issues receive feedback from the
development team. Therefore the priority is mentioning developers that can help
on those issues. Please select someone with relevant experience from
[GitLab team][team]. If there is nobody mentioned with that expertise
look in the commit history for the affected files to find someone. Avoid
mentioning the lead developer, this is the person that is least likely to give a
timely response. If the involvement of the lead developer is needed the other
core team members will mention this person.
on those issues. Please select someone with relevant experience from the
[GitLab team][team]. If there is nobody mentioned with that expertise look in
the commit history for the affected files to find someone.
[described in our handbook]: https://about.gitlab.com/handbook/engineering/issues/issue-triage-policies/
[issue bash events]: https://gitlab.com/gitlab-org/gitlab-ce/issues/17815
@ -535,11 +532,11 @@ the feature you contribute through all of these steps.
1. [Unit and system tests][testing] that pass on the CI server
1. Performance/scalability implications have been considered, addressed, and tested
1. [Documented][doc-styleguide] in the `/doc` directory
1. [Changelog entry added][changelog]
1. [Changelog entry added][changelog], if necessary
1. Reviewed and any concerns are addressed
1. Merged by a project maintainer
1. Added to the release blog article if relevant
1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/) if relevant
1. Added to the release blog article, if relevant
1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/), if relevant
1. Community questions answered
1. Answers to questions radiated (in docs/wiki/support etc.)

2
PROCESS.md
View file

@ -1,4 +1,4 @@
## GitLab Core Team & GitLab Inc. Team Contributing Process
## GitLab Core Team & GitLab Inc. Contribution Process
---

3
doc/development/code_review.md
View file

@ -95,8 +95,6 @@ experience, refactors the existing code). Then:
"LGTM :thumbsup:", or "Just a couple things to address."
- Assign the merge request to the author if changes are required following your
review.
- You should try to resolve merge conflicts yourself, using the [merge conflict
resolution][conflict-resolution] tool.
- Set the milestone before merging a merge request.
- Avoid accepting a merge request before the job succeeds. Of course, "Merge
When Pipeline Succeeds" (MWPS) is fine.
@ -105,7 +103,6 @@ experience, refactors the existing code). Then:
- Consider using the [Squash and
merge][squash-and-merge] feature when the merge request has a lot of commits.
[conflict-resolution]: https://docs.gitlab.com/ce/user/project/merge_requests/resolve_conflicts.html#merge-conflict-resolution
[squash-and-merge]: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#squash-and-merge
### The right balance