beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mergebot-r...@apache.org
Subject [beam-site] 01/01: Prepare repository for deployment.
Date Wed, 12 Jul 2017 20:02:56 GMT
This is an automated email from the ASF dual-hosted git repository.

mergebot-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam-site.git

commit f88e604afdcfb9d5b96b5435f3f5209cca787f72
Author: Mergebot <mergebot@apache.org>
AuthorDate: Wed Jul 12 20:02:53 2017 +0000

    Prepare repository for deployment.
---
 content/contribute/contribution-guide/index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/content/contribute/contribution-guide/index.html b/content/contribute/contribution-guide/index.html
index 18c6257..d7e89d2 100644
--- a/content/contribute/contribution-guide/index.html
+++ b/content/contribute/contribution-guide/index.html
@@ -522,7 +522,7 @@ $ tox -e lint
 <p>Once the initial code is complete and the tests pass, it’s time to start the code
review process. We review and discuss all code, no matter who authors it. It’s a great way
to build community, since you can learn from other developers, and they become familiar with
your contribution. It also builds a strong project by encouraging a high quality bar and keeping
code consistent throughout the project.</p>
 
 <h3 id="create-a-pull-request">Create a pull request</h3>
-<p>Organize your commits to make your reviewer’s job easier. Reviewers normally prefer
multiple small pull requests, instead of a single large pull request. Within a pull request,
a relatively small number of commits that break the problem into logical steps is preferred.
For most pull requests, you’ll squash your changes down to 1 commit. You can use the following
command to re-order, squash, edit, or change description of individual commits.</p>
+<p>Organize your commits to make a committer’s job easier when reviewing. Committers
normally prefer multiple small pull requests, instead of a single large pull request. Within
a pull request, a relatively small number of commits that break the problem into logical steps
is preferred. For most pull requests, you’ll squash your changes down to 1 commit. You can
use the following command to re-order, squash, edit, or change description of individual commits.</p>
 
 <div class="highlighter-rouge"><pre class="highlight"><code>$ git rebase
-i origin/master
 </code></pre>
@@ -536,25 +536,25 @@ $ tox -e lint
 </code></pre>
 </div>
 
-<p>Please include a descriptive pull request message to help make the reviewer’s
job easier. It’s fine to refer to existing design docs or the contents of the associated
JIRA as appropriate.</p>
+<p>Please include a descriptive pull request message to help make the comitter’s
job easier when reviewing. It’s fine to refer to existing design docs or the contents of
the associated JIRA as appropriate.</p>
 
 <p>If you know a good committer to review your pull request, please make a comment
like the following. If not, don’t worry – a committer will pick it up.</p>
 
-<div class="highlighter-rouge"><pre class="highlight"><code>Hi @&lt;GitHub-reviewer-username&gt;,
can you please take a look?
+<div class="highlighter-rouge"><pre class="highlight"><code>Hi @&lt;GitHub-committer-username&gt;,
can you please take a look?
 </code></pre>
 </div>
 
-<p>When choosing a reviewer, think about who is the expert on the relevant code, who
the stakeholders are for this change, and who else would benefit from becoming familiar with
the code. If you’d appreciate comments from additional folks but already have a main reviewer,
you can explicitly cc them using <code class="highlighter-rouge">@&lt;GitHub-reviewer-username&gt;</code>.</p>
+<p>When choosing a committer to review, think about who is the expert on the relevant
code, who the stakeholders are for this change, and who else would benefit from becoming familiar
with the code. If you’d appreciate comments from additional folks but already have a main
committer, you can explicitly cc them using <code class="highlighter-rouge">@&lt;GitHub-committer-username&gt;</code>.</p>
 
 <h3 id="code-review-and-revision">Code Review and Revision</h3>
-<p>During the code review process, don’t rebase your branch or otherwise modify published
commits, since this can remove existing comment history and be confusing to the reviewer.
When you make a revision, always push it in a new commit.</p>
+<p>During the code review process, don’t rebase your branch or otherwise modify published
commits, since this can remove existing comment history and be confusing to the committer
when reviewing. When you make a revision, always push it in a new commit.</p>
 
 <p>Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins.
Please make sure those tests pass; the contribution cannot be merged otherwise.</p>
 
 <h3 id="lgtm">LGTM</h3>
-<p>Once the reviewer is happy with the change, they’ll respond with an LGTM (“<em>looks
good to me!</em>”). At this point, the committer will take over, possibly make some
additional touch ups, and merge your changes into the codebase.</p>
+<p>Once the committer is happy with the change, they’ll respond with an LGTM (“<em>looks
good to me!</em>”). At this point, the committer will take over, possibly make some
additional touch ups, and merge your changes into the codebase.</p>
 
-<p>In the case both the author and the reviewer are committers, either can merge the
pull request. Just be sure to communicate clearly whose responsibility it is in this particular
case.</p>
+<p>In the case the author is also a committer, either can merge the pull request. Just
be sure to communicate clearly whose responsibility it is in this particular case.</p>
 
 <p>Thank you for your contribution to Beam!</p>
 
@@ -570,7 +570,7 @@ $ git push &lt;GitHub_user&gt; --delete &lt;my-branch&gt;
 </div>
 
 <h2 id="commit-committers-only">Commit (committers only)</h2>
-<p>Once the code has been peer reviewed by a committer, the next step is for the committer
to merge it into the <a href="https://git-wip-us.apache.org/repos/asf/beam.git">authoritative
Apache repository</a>, not the read-only GitHub mirror. (In the case that the author
is also a committer, it is acceptable for either the author or reviewer to do the merge. Just
be explicit about whose job it is!)</p>
+<p>Once the code has been peer reviewed by a committer, the next step is for the committer
to merge it into the <a href="https://git-wip-us.apache.org/repos/asf/beam.git">authoritative
Apache repository</a>, not the read-only GitHub mirror. (In the case that the author
is also a committer, it is acceptable for either the author of the change or committer who
reviewed the change to do the merge. Just be explicit about whose job it is!)</p>
 
 <p>Pull requests should not be merged before the review has received an explicit LGTM
from another committer. Exceptions to this rule may be made rarely, on a case-by-case basis
only, in the committer’s discretion for situations such as build breakages.</p>
 

-- 
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <commits@beam.apache.org>.

Mime
View raw message