- Broken link to "How to work with the distribution team"

Nick Thomas authored 5 years ago and Evan Read committed 5 years ago

This is overdue, and some of the suggestions are embarrassing, but
this is how we actually develop Danger today.

We have a fairly good guide to Code Reviews, but can be improved
by adding a few examples of what a good code review looks like
at GitLab, specifically ones where there is a bit of back and
forth, "nit-picking," etc. This would:

+ help set expectations of newly hired engineers around what our
process looks like when it is functioning what level of scrutiny
their code will be under

+ how we have technical conversations

+ show by example how after you're done crafting a solution, there
can still be extra work done either tidying up code and/or managing
the communication and conversations about your proposed MR

Toon Claes authored 5 years ago and Nick Thomas committed 5 years ago

See https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6069

Marcel Amirault authored 5 years ago and Evan Read committed 5 years ago

Ensure that all numbered lists use only 1. and no other numbers.
Also ensure that numbered lists use proper spacing.

Marcel Amirault authored 5 years ago and Evan Read committed 5 years ago

Correct the spacing of unordered markdown lists
in docs, to maintain standards of documentation.

The installation link has changed from /installation/ to /install/. This
commit will update all the remaining links that are missing.

This is part of https://gitlab.com/gitlab-org/gitlab-ce/issues/61945

Make danger pick reviewers and maintainers at random, for feontend,
backend, database, etc, changes, whenever files belonging to those
teams get changed.

By setting expectations both the contributor and reviewer have more
certainty on what gets reviewed when, and at what speed changes could be
merged.

closes #8608