Hello,

me and David assigned reviews today and here is the procedure we came up with. Unfortunately, because we dont use merge requests in gitlab yet, we cannot use the natural procedure of gitlab when it comes to code reviews, so we had to hack something up with labels for now.

== Marking something for review ==

When you write code and you want to mark it for review, please add the "Needs Review" label.

== Assigning reviews ==

When me and David assign reviews, we use the "Reviewer" label and then assign the ticket to the right reviewer.

== Finding your reviews ==

To find your reviews you use this query:

ahf: https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...

nickm: https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...

asn: https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...

dgoulet: https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...

== Reviewing your reviews (happy path) ==

When you do your reviews, the happy path is that the patch was good and you merge it and you move forward.

Because ahf can't commit yet, when ahf reviews code, he can add the label "Merge Ready" and then its our responsibility to merge it. Hopefully ahf will start committing next week and we won't need to do that.

== Reviewing your reviews (sad path) ==

If the patch was not good, you need to put it in needs revision. This is crammy in our workflow (because of lack of MRs) but we suggest the following procedure: - You add the "Needs Revision" label. - You don't change any other label.

It's now the responsibility of the code author to notice this label, and revision the code. It's also the responsibility of the reviewer to poke the code author if they haven't done this in a reasonable amount of time.

== TODO ==

How to handle backports? Transition to MR workflow which will greatly improve the sad path above.