[tor-commits] [sbws/maint-1.1] fix: doc: Replace Github review process to Gitlab

[juga at torproject.org]

commit f26e4bc58d80717f2d8893a9f72003cfc84da014
Author: juga0 <juga at riseup.net>
Date:   Fri Jun 26 07:42:33 2020 +0000

    fix: doc: Replace Github review process to Gitlab
    
    Replace also Github terminology to Gitlab.
---
 docs/source/contributing.rst | 57 +++++++++++++++++++++++++++-----------------
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/docs/source/contributing.rst b/docs/source/contributing.rst
index 161f971..658cf80 100644
--- a/docs/source/contributing.rst
+++ b/docs/source/contributing.rst
@@ -24,8 +24,9 @@ Code/documentation patches
 ---------------------------
 
 The sbws canonical repository is https://gitweb.torproject.org/sbws.git,
-but we review patches using the Github canonical repository
-(https://github.com/torproject/sbws) Pull Requests (PR).
+but we review patches using the Gitlab repository
+(https://gitlab.torproject.org/tpo/network-health/sbws/-/merge_requests)
+Merge Requests (MR).
 
 To know more about ``sbws`` code,
 
@@ -39,12 +40,12 @@ To know more about ``sbws`` code,
 
 The following are guidelines we aim to follow.
 
-Steps to create a PR
+Steps to create a MR
 ~~~~~~~~~~~~~~~~~~~~~
 
 1. Create a issue in Tor Project Gitlab (:ref:`Open issue <ticket-ref>`)
-2. Clone ``sbws`` via the Github web interface
-   https://github.com/torproject/sbws
+2. Fork ``sbws`` via the Gitlab web interface:
+   https://gitlab.torproject.org/tpo/network-health/sbws
 3. Clone the repository locally
 4. Install ``sbws`` as explained in ./INSTALL.rst and ./TESTING.rst
    Use ``pip install -e <>``
@@ -56,11 +57,23 @@ Steps to create a PR
 7. Write code (:ref:`codestyle-ref`), tests, documentation,
    extra files (:ref:`extrafiles-ref`), commit (:ref:`commits-ref`), etc.
 8. Ensure tests pass (./TESTING.rst).
-9. Push your branch to your repository. If you have an account in Travis,
-   you can see whether it pass the tests in Github and in
-   https://travis-ci.org/youruser/sbws/
-10. Create a PR from your branch to https://github.com/torproject/sbws
-11. Change the Trac ticket status to ``needs_review``
+9. Push your branch to your Gitlab repository.
+
+We are temporally using Github Travis to ensure tests pass. For this:
+
+10. Clone ``sbws`` via the Github web interface:
+    https://github.com/torproject/sbws
+11. Push your branch to your Github repository.
+
+12. If you have an account in Travis, you can see whether it pass the tests in
+    Github and at https://travis-ci.org/youruser/sbws/
+
+Finally:
+
+13. Create a MR from your branch at
+    https://gitlab.torproject.org/tpo/network-health/sbws
+
+
 
 .. _codestyle-ref:
 
@@ -154,27 +167,27 @@ Template originally written by `Tim Pope`_: :ref:`example commit <commit-msg>`
 Code being reviewed workflow
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When a PR is being reviewed, new changes might be needed:
+When a MR is being reviewed, new changes might be needed:
 
 - If the change does not modify a previous change, create new commits and push.
 - If the change modifies a previous change and it's small,
   `git commit fixup <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupltcommitgt>`_
-  should be used. When it is agreed that the PR is ready, create a new branch
+  should be used. When it is agreed that the MR is ready, create a new branch
   named ``mybranch_02`` and run:
 
   .. code-block:: bash
 
     rebase --autosquash
 
-  push, create new PR and close old PR mentioning the number of the new PR.
-- If the review takes long and when it's ready code related to the PR has changed
+  push, create new MR and close old MR mentioning the number of the new MR.
+- If the review takes long and when it's ready code related to the MR has changed
   in master, create a new branch named ``mybranch_02`` and run:
 
   .. code-block:: bash
 
     rebase master
 
-  push, create new PR and close old PR mentioning the number of the new PR.
+  push, create new MR and close old MR mentioning the number of the new MR.
 
 [MERG]_
 
@@ -196,23 +209,23 @@ Reviewers:
 - Should let the contributor know what to improve/change.
 - Should not push code to the contributor's branch.
 - Should wait for contributor's changes or feedback after changes are requested,
-  before merging or closing a PR.
-- Should merge (not rebase) the PR.
+  before merging or closing a MR.
+- Should merge (not rebase) the MR.
 - If rebase is needed due to changes in master, the contributor should create
   a new branch named `xxx_rebased` based on the reviewed branch, rebase and
-  create a new PR from it, as explained above.
+  create a new MR from it, as explained above.
 - If new changes are needed when the contributor's branch is ready to merge,
   the reviewer can create a new branch based on the contributor's branch,
-  push the changes and merge that PR.
+  push the changes and merge that MR.
   The contributor should be notified about it.
-- If the reviewer realize that new changes are needed after the PR has been
+- If the reviewer realize that new changes are needed after the MR has been
   merged, the reviewer can push to master, notifying the contributor about the
   changes.
 - Because currently there are not many reviewers, reviewers can merge their own
-  PR if there was not any feedback after a week.
+  MR if there was not any feedback after a week.
 - Should not push directly to master, unless changes are trivial (typos,
   extra spaces, etc.)
-- Should not push to master new features while there are open PRs to review.
+- Should not push to master new features while there are open MRs to review.
 
 Currently, the reviewers are the persons that have contributed to the code:
 pastly, teor, juga.