diff options
Diffstat (limited to 'doc/development/contributing')
| -rw-r--r-- | doc/development/contributing/design.md | 2 | ||||
| -rw-r--r-- | doc/development/contributing/index.md | 20 | ||||
| -rw-r--r-- | doc/development/contributing/issue_workflow.md | 32 | ||||
| -rw-r--r-- | doc/development/contributing/merge_request_workflow.md | 10 |
4 files changed, 34 insertions, 30 deletions
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md index 79750878aac..9796e195f86 100644 --- a/doc/development/contributing/design.md +++ b/doc/development/contributing/design.md @@ -5,7 +5,7 @@ For guidance on UX implementation at GitLab, please refer to our [Design System] The UX team uses labels to manage their workflow. The ~"UX" label on an issue is a signal to the UX team that it will need UX attention. -To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux) of the handbook. +To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux/) of the handbook. Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue. diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index 694f8d2cb45..92dd040a2bd 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -15,7 +15,7 @@ abbreviation. To get an overview of GitLab community membership including those that would be reviewing or merging your contributions, please visit [the community roles page](community_roles.md). -If you want to know how the GitLab [core team] +If you want to know how the GitLab [core team](https://about.gitlab.com/community/core-team/) operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md). [GitLab Inc engineers should refer to the engineering workflow document](https://about.gitlab.com/handbook/engineering/workflow/) @@ -24,7 +24,7 @@ operates please see [the GitLab contributing process](https://gitlab.com/gitlab- Please report suspected security vulnerabilities in private to `support@gitlab.com`, also see the -[disclosure section on the GitLab.com website](https://about.gitlab.com/disclosure/). +[disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/). Please do **NOT** create publicly viewable issues for suspected security vulnerabilities. @@ -48,7 +48,7 @@ for audiences of all ages. If a contributor is no longer actively working on a submitted merge request we can decide that the merge request will be finished by one of our -[Merge request coaches][team] or close the merge request. We make this decision +[Merge request coaches](https://about.gitlab.com/company/team/) or close the merge request. We make this decision based on how important the change is for our product vision. If a merge request coach is going to finish the merge request we assign the ~"coach will finish" label. When a team member picks up a community contribution, @@ -59,18 +59,17 @@ within the MR. ## Helping others Please help other GitLab users when you can. -The methods people will use to seek help can be found on the [getting help page][getting-help]. +The methods people will use to seek help can be found on the [getting help page](https://about.gitlab.com/get-help/). Sign up for the mailing list, answer GitLab questions on StackOverflow or -respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with -the remaining issues on the GitHub issue tracker. +respond in the IRC channel. ## I want to contribute If you want to contribute to GitLab, [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors) are a great place to start. -If you have any questions or need help visit [Getting Help](https://about.gitlab.com/getting-help/#discussion) to +If you have any questions or need help visit [Getting Help](https://about.gitlab.com/get-help/) to learn how to communicate with GitLab. If you're looking for a Gitter or Slack channel please consider we favor [asynchronous communication](https://about.gitlab.com/handbook/communication/#internal-communication) over real time communication. Thanks for your contribution! @@ -85,7 +84,7 @@ When maintainers are reading through a merge request they may request guidance f Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance. The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future. -GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request. For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches. +GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request. For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches. GitLab receives a lot of community contributions, so if your code has not been reviewed within two days (excluding weekend and public holidays) of its initial submission feel free to re-mention the appropriate merge request coach. @@ -122,8 +121,3 @@ This [documentation](style_guides.md) outlines the current style guidelines. --- [Return to Development documentation](../README.md) - -[core team]: https://about.gitlab.com/core-team/ -[team]: https://about.gitlab.com/company/team/ -[getting-help]: https://about.gitlab.com/getting-help/ -[codetriage]: http://www.codetriage.com/gitlabhq/gitlabhq diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 810d03e82c5..349bb371835 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -22,14 +22,15 @@ once 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 the -[GitLab team](https://about.gitlab.com/team/). +[GitLab team](https://about.gitlab.com/company/team/). If there is nobody mentioned with that expertise look in the commit history for the affected files to find someone. -We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to -automate some triaging policies. This is currently set up as a -[scheduled pipeline](https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit) -running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) project. +We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate +some triaging policies. This is currently set up as a scheduled pipeline +(`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`, +must have at least developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) +project. ## Labels @@ -45,8 +46,8 @@ Most issues will have labels for at least one of the following: - Category: ~"Category:Code Analytics", ~"Category:DevOps Score", ~"Category:Templates", etc. - Feature: ~wiki, ~ldap, ~api, ~issues, ~"merge requests", etc. - Department: ~UX, ~Quality -- Team: ~Documentation, ~Delivery -- Specialization: ~frontend, ~backend +- Team: ~"Technical Writing", ~Delivery +- Specialization: ~frontend, ~backend, ~documentation - Release Scoping: ~Deliverable, ~Stretch, ~"Next Patch Release" - Priority: ~P1, ~P2, ~P3, ~P4 - Severity: ~S1, ~S2, ~S3, ~S4 @@ -96,6 +97,7 @@ Following is a non-exhaustive list of facet labels: - ~security: A security issue could describe a ~bug or a ~feature. - ~database: A database issue could describe a ~bug or a ~feature. - ~customer: This relates to an issue that was created by a customer, or that is of interest for a customer. +- ~"UI text": Issues that add or modify any text within the UI such as user-assistance microcopy, button/menu labels, or error messages. ### Stage labels @@ -148,10 +150,15 @@ You can find the groups listed in the [Product Stages, Groups, and Categories](h We use the term group to map down product requirements from our product stages. As a team needs some way to collect the work their members are planning to be assigned to, we use the `~group::` labels to do so. -Normally there is a 1:1 relationship between Stage labels and Group labels. In the spirit of "Everyone can contribute", -any issue can be picked up by any group, depending on current priorities. For example, an issue labeled ~"devops::create" may be picked up by the ~"group::access" group. +Normally there is a 1:1 relationship between Stage labels and Group labels. In +the spirit of "Everyone can contribute", any issue can be picked up by any group, +depending on current priorities. When picking up an issue belonging to a different +group, it should be relabelled. For example, if an issue labelled ~"devops::create" +and ~"group::knowledge" is picked up by someone in the Access group of the Plan stage, +the issue should be relabelled as ~"group::access" while keeping the original +~"devops::create" unchanged. -We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput). +We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/). Please read [Stage and Group labels in Throughtput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context. ### Category labels @@ -228,7 +235,7 @@ people. The current team labels are: - ~Delivery -- ~Documentation +- ~"Technical Writing" #### Naming and color convention @@ -241,6 +248,7 @@ These labels narrow the [specialization](https://about.gitlab.com/company/team/s - ~frontend - ~backend +- ~documentation ### Release scoping labels @@ -334,7 +342,7 @@ know how difficult the issue is. Additionally: - We advertise [`Accepting merge requests` issues with weight < 5](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight) as suitable for people that have never contributed to GitLab before on the - [Up For Grabs campaign](http://up-for-grabs.net) + [Up For Grabs campaign](https://up-for-grabs.net/#/) - We encourage people that have never contributed to any open source project to look for [`Accepting merge requests` issues with a weight of 1](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight&weight=1) diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md index 1931dda7151..86f17f4ecdb 100644 --- a/doc/development/contributing/merge_request_workflow.md +++ b/doc/development/contributing/merge_request_workflow.md @@ -89,7 +89,7 @@ request is as follows: 1. Write tests for more complex migrations. 1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md). 1. For tests that use Capybara, read - [how to write reliable, asynchronous integration tests](https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara). + [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara). 1. If your merge request introduces changes that require additional steps when installing GitLab from source, add them to `doc/install/installation.md` in the same merge request. @@ -101,7 +101,7 @@ request is as follows: If you would like quick feedback on your merge request feel free to mention someone from the [core team](https://about.gitlab.com/community/core-team/) or one of the -[merge request coaches](https://about.gitlab.com/team/). When having your code reviewed +[merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed and when reviewing merge requests, please keep the [code review guidelines](../code_review.md) in mind. And if your code also makes changes to the database, or does expensive queries, check the [database review guidelines](../database_review.md). @@ -140,7 +140,7 @@ When writing commit messages, please follow the guidelines below: - The merge request must not contain more than 10 commit messages. If the guidelines are not met, the MR will not pass the -[Danger checks](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/danger/commit_messages/Dangerfile). +[Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile). For more information see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/). Example commit message template that can be used on your machine that embodies the above (guide for [how to apply template](https://codeinthehole.com/tips/a-useful-template-for-commit-messages/)): @@ -220,6 +220,8 @@ requirements. 1. Working and clean code that is commented where needed. 1. [Unit, integration, and system tests](../testing_guide/index.md) that all pass on the CI server. +1. Regressions and bugs are covered with tests that reduce the risk of the issue happening + again. 1. Performance/scalability implications have been considered, addressed, and tested. 1. [Documented](../documentation/index.md) in the `/doc` directory. 1. [Changelog entry added](../changelog.md), if necessary. @@ -244,5 +246,5 @@ request: 1. [The upgrade guide](../../update/upgrading_from_source.md). 1. The [GitLab Installation Guide](../../install/installation.md#1-packages-and-dependencies). 1. The [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit). -1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/scripts/prepare_build.sh). +1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/prepare_build.sh). 1. The [Omnibus package creator](https://gitlab.com/gitlab-org/omnibus-gitlab). |