Fix as per revision

Author: Pietro Grandi

process/merge_requests/README.md

@@ -1,20 +1,19 @@
 # Merge requests
 ## Introduction
 Since introducing GitLab to our workflow, we've been using it as our primary
-tool for reviewing code. 
-While issues still reside in Jira the actual merging, deploying, commenting
-and discussing code is handled through GitLab.
+tool for reviewing code. While issues still reside in JIRA the actual merging,
+deploying, commenting and discussing code is handled through GitLab.
 
 ## Prerequisite
 The following instructions assume you have a working GitLab account. If you
 don't yet have access to the web interface of GitLab, contact Operations.
 
 ## Lifecycle of a merge request
 ### Creation procedure
-Let's assume you've worked on an issue enough to set the status to "Review",
+Let's assume you've worked on an issue enough to set the status to review,
 which would put it into the review's queue.
 
-Before you set the status to "Review", make sure that there's a Merge Request
+Before you set the status to review, make sure that there's a Merge Request
 (henceforth referred to as "MR") available in GitLab.
 
 These are the steps necessary:
@@ -27,49 +26,48 @@ These are the steps necessary:
 5. Click the green "New Merge Request" button, located in the top right part of
    the page.
 6. Here you'll need to provide the **source** branch and the **target** branch.
-   The source branch should be the branch which you wish to have reviewed, while
-   the target branch should be what you want to merge into.  
-   Unless you've been asked to set it to something else, you'll want the target
-   branch to be set to `master`.
+   The source branch should be the branch which you wish to have reviewed,
+   while the target branch should be what you want to merge into.  Unless
+   you've been asked to set it to something else, you'll want the target branch
+   to be set to `master`.
 7. Press the blue "Compare branches" button.
 8. Enter title and description, following the guidelines written in the
    **Title and Description guidelines** section.  
-9. Set label "Ready for review".  
-10. Assign it to another developer.
 9. At this point you can review the MR one final time before pressing the
    "Submit merge request" button.
 
-This should take you to the page with the now created MR.  
-All that is necessary from here is to **add a link to the MR in the Jira ticket**.
+This should take you to the page with the now created MR.
+
+All that is necessary from here is to **add a link to the MR in the JIRA ticket**.
 
 #### Title and Description guidelines
 The title should always look something like this:
 
     #12345: Adjust constant in warpcore configuration to prevent overheating
 
-Notice the issue number at the start, including the # character.
-Following the issue number should be general description of what the MR changes.
+Notice the issue number at the start, including the # character.  Following the
+issue number should be general description of what the MR changes.
 
 The description should include the following:
 
-* A direct link to the Jira ticket, in the form of: `refs [#12345](https://jira.server/12345)`
-* What the MR changes, being a bit more descriptive than the title.
-* If there's something you're unsure of how it should be done, point this out so
+* A direct link to the JIRA ticket, in the form of: `refs [#12345](https://jira.server/12345)`
+* What the MR changes, being a bit more descriptive than the title.  If there's
+* something you're unsure of how it should be done, point this out so
   that the reviewer can help you out.
 * If necessary, include information that would help the reviewer understand
   *why* you made certain changes. This information should already be present in
   the form of [well written commit messages](../../style/git), but it doesn't
   hurt including this in the MR description.
 * If there are parts of the changeset that can be ignored (you added a library
-  to vendor, resulting in thousands of lines of code), you should point this out
-  so the reviewer doesn't waste time sifting through vendor code.
+  to vendor, resulting in thousands of lines of code), you should point this
+  out so the reviewer doesn't waste time sifting through vendor code.
 * If the merge will require some additional deploy instructions, include these
   so that they too can be reviewed.
 
 
 ### Working with merge requests
 #### Git
-The process of working and commiting when working in conjunction with MRs
+The process of working and committing when working in conjunction with MRs
 doesn't differ much from how work has been handled when we only used Redmine,
 but there's one major difference:
 
@@ -81,13 +79,12 @@ What does this mean?
 Let's say you've submitted your MR and the reviewer wants you to change
 something in a previous commit.
 
-If you previously had the habit of creating
-a commit, rebasing and squashing right away: refrain from doing so. The
-preferred way of doing things in this system [is to create fixup commits][fixup]
-that are squashed at the very end of the life cycle of the MR, so pretty much
-when the reviewer approves the MR for merging.
-The rebase process would be done by the author when asked from the reviewer, depending
-on the MR's complexity.
+If you previously had the habit of creating a commit, rebasing and squashing
+right away: refrain from doing so. The preferred way of doing things in this
+system [is to create fixup commits][fixup] that are squashed at the very end of
+the life cycle of the MR, so pretty much when the reviewer approves the MR for
+merging.  The rebase process would be done by the author when asked from the
+reviewer, depending on the MR's complexity.
 
   [fixup]: http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html
 
@@ -97,8 +94,8 @@ If there's no need to rewrite history, for instance if you start adding new
 features after the MR is submitted, just keep working as you always have.
 
 #### The merge request interface
-If you make an adjustment (e.g. to address a comment that was left by
-a reviewer) and push the resulting code, this will immediately be reflected in
+If you make an adjustment (e.g. to address a comment that was left by a
+reviewer) and push the resulting code, this will immediately be reflected in
 the MR. This way, the reviewer will always see the latest version of the branch
 in the MR.
 
@@ -117,17 +114,12 @@ become easier to if you surround it with backticks.
   [GFMD]: http://doc.gitlab.com/ce/markdown/markdown.html
 
 ### Closing a merge request
-When the reviewer considers the code ready to merge, he'll say so, and a label
-with the name `Ready for release` will be applied, indicating that the branch is
-ready to merge and deploy.
-It's up to the reviewer applying the label and unassigning the MR.
-
 Do not close the MR, it will be closed automatically when the branch is merged
 into `next` (or whatever other branch was set as the target branch).
 
 ## Finding merge requests
 As stated at the end of the "Creation procedure" section, if an issue in
-Jira has code that should be reviewed, a link to the corresponding MR in
+JIRA has code that should be reviewed, a link to the corresponding MR in
 GitLab *must* be posted. This link will probably be the easiest way to find the
 MR in GitLab.
 

style/git/README.md

@@ -4,9 +4,9 @@
 ### Content
 The commit message serves to provide a technical description of the change
 introduced by its commit. It should be possible to look at a commit message in
-combination with its diff and quickly understand **what** was changed **where**,
-**how** it was changed and **why**. Simple changes sometimes speak for
-themselves. Complex changes need more explanation.
+combination with its diff and quickly understand **what** was changed
+**where**, **how** it was changed and **why**. Simple changes sometimes speak
+for themselves. Complex changes need more explanation.
 
 * Commits are a form of documentation
 * Time spent writing costs less than the time spent reading
@@ -31,7 +31,7 @@ The commit message body describes the current state (**why**):
 * Use present tense, e.g. "Foo does not work"
 * Avoid past tense, e.g. "Foo did not work"
 
-It describes what the the commit does to change the current state (**what**):
+It describes what the commit does to change the current state (**what**):
 
 * Match the subject and use imperative mood "Fix foo by doing bar"
 * Or use a descriptive tone "This fixes foo by doing bar"
@@ -118,12 +118,12 @@ Furthermore:
    commit.
 
 ## Branches
-1. Branch `next` contains the latest stable release
+1. Branch `master` contains the latest stable release
 2. Integration branches are namespaced `integration/`
 3. Individual words in branch names are separated by hyphen-minus (`-`)
 
 ### Personal branches
-1. Personal branches are namespaced `<name>/` where `<name>` is your firstname
+1. Personal branches are namespaced `<name>/` where `<name>` is your first name
    or known nickname.
 2. It is a good idea to push even unfinished work to your personal namespace
    frequently.