We should not discourage contributors from submitting merge requests
anytime they want. Our process for reviewing community contributions
no longer depends on the release schedule.
Replace links to the `Merge request description format` section with
up-to-date instructions on using the MR template built into the UI.
The `Merge request description format` section was removed in 2f7e28d1,
but links were left in the table of contents and in the MR description
instructions.
All this does is convert the version sections into headers. The list
items shouldn't really be indented by two spaces, but it makes no
difference to the rendering and this way we retain authorship history
for the actual changes.
Related to https://gitlab.com/gitlab-org/release-tools/merge_requests/29
Add link to article on how to write reliable, asynchronous tests with Capybara
This article has been incredibly useful for all developers. Adding a link to it so more people can refer to it.
See merge request !6312
Added performance guidelines for new MRs
## What does this MR do?
This MR adds a set of guides that should be followed by merge request authors.
## Are there points in the code the reviewer needs to double check?
Spelling, grammar, etc
## Why was this MR needed?
There is no set of guidelines one should follow when submitting merge requests. This leads to developers at times disregarding performance. This in turn results in performance specialists having to clean up the mess, or production engineers being woken up in the middle of the night because the database is on fire.
## Does this MR meet the acceptance criteria?
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @DouweM @rspeicher @pcarranza @dzaporozhets
See merge request !5905
These guidelines cover the performance requirement for newly submitted
merge requests. These guidelines are put in to place to prevent merge
requests from negatively impacting GitLab performance as much as
possible.
Fix link to current design reference in the CONTRIBUTING guide
## What does this MR do?
It fixes an outdated link by replacing it with the up-to-date one.
See merge request !4439
Now that we autoscale runner, we don't need to optimize for their usage
anymore. Abusing of "ci skip", for instance for view changes can lead to
broken specs, so let's just not use it!
Signed-off-by: Rémy Coutable <remy@rymai.me>
feature proposal issue template in contributing guide
This adds a feature proposal template to the contribution guidelines for internal and external use.
Fixes#15448
cc @markpundsack @stanhu @dzaporozhets
See merge request !3967
Link to GitLab code review guide in contributing guidelines
I noticed that the contributing guidelines still link to the thoughtbot
code review guidelines even though we already have our own.
[ci skip]
See merge request !4018
Achilleas Pipinellis
James Edwards-Jones
sytses
Rémy Coutable
Adam Niedzielski
Job van der Voort
Carlos Galarza
Taurie Davis
awhildy
Daniel Axelrod
Robert Speicher
Stan Hu
Mark Fletcher
Yorick Peterse
Dmitriy Zaporozhets
Robert Speicher
Timothy Andrew
Jacob Schatz
Mark Pundsack
Connor Shea
Zeger-Jan van de Weg
Douwe Maan
Karlo Soriano
Jacob Schatz