airavata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r915709 - in /websites/staging/airavata/trunk/content: ./ community/how-to-contribute-code.html
Date Thu, 10 Jul 2014 18:20:55 GMT
Author: buildbot
Date: Thu Jul 10 18:20:55 2014
New Revision: 915709

Log:
Staging update by buildbot for airavata

Modified:
    websites/staging/airavata/trunk/content/   (props changed)
    websites/staging/airavata/trunk/content/community/how-to-contribute-code.html

Propchange: websites/staging/airavata/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jul 10 18:20:55 2014
@@ -1 +1 @@
-1609539
+1609546

Modified: websites/staging/airavata/trunk/content/community/how-to-contribute-code.html
==============================================================================
--- websites/staging/airavata/trunk/content/community/how-to-contribute-code.html (original)
+++ websites/staging/airavata/trunk/content/community/how-to-contribute-code.html Thu Jul
10 18:20:55 2014
@@ -132,38 +132,27 @@
       <div class="span9">
       	<section id="content" class="row">
         	<article class="span9">
-          	<p>Welcome and thank you for your interest in contributing to Apache Airavata!
This guide will take you through the process of making contributions to the airavata code
base.</p>
-<ol>
-<li>Engage with the community</li>
-</ol>
-<p>Identify an issue or documentation that you want to fix or improve. Search <a
href="https://issues.apache.org/jira/browse/airavata">JIRA</a> and the mailing list
to see if it’s already been discussed.</p>
-<ol>
-<li>Create an issue in JIRA</li>
-</ol>
-<p>If it’s a bug or a feature request, open a JIRA issue. Create a sample that
you can use for prototyping the feature or demonstrating the bug. If creating a sample is
time consuming, write steps to reproduce the issue. Attach this sample to the JIRA issue if
it’s representing a bug report.</p>
-<ol>
-<li>Create a pull request in GitHub</li>
-</ol>
+          	<h3 id="apache-airavata-contribution-guide">Apache Airavata Contribution
Guide</h3>
+<p>Welcome and thank you for your interest in contributing to Apache Airavata! This
guide will take you through the process of making contributions to the airavata code base.</p>
+<h4 id="engage-with-the-community">Engage with the community</h4>
+<p>Identify an issue or documentation that you want to fix or improve. Search <a
href="https://issues.apache.org/jira/browse/airavata">JIRA</a> and the mailing list
to see if it’s already been discussed.    </p>
+<h4 id="create-an-issue-in-jira">Create an issue in JIRA</h4>
+<p>If it’s a bug or a feature request, open a JIRA issue. Create a sample that
you can use for prototyping the feature or demonstrating the bug. If creating a sample is
time consuming, write steps to reproduce the issue. Attach this sample to the JIRA issue if
it’s representing a bug report.   </p>
+<h4 id="create-a-pull-request-in-github">Create a pull request in GitHub</h4>
 <p><a href="source.html">Checkout</a> the source code. Create a pull request
(PR) in GitHub for the change you're interested in making. The comment section of the PR must
contain a link to the JIRA issue. Please also reference the issue in the commit message, and
make sure it properly describes the changes that have been made and their purpose.</p>
-<p>Some good references for working with GitHub are below. We ask that you keep your
change rebased to master as much as possible, and we will ask you to rebase again if master
has moved before accepting your patch.</p>
+<p>Some good references for working with GitHub are below. We ask that you keep your
change rebased to master as much as possible, and we will ask you to rebase again if master
has moved before accepting your patch.   </p>
 <ul>
 <li><a href="https://help.github.com/articles/set-up-git">Setting Up Git with
GitHub</a></li>
 <li><a href="https://help.github.com/articles/fork-a-repo">Forking a Repository</a></li>
 <li><a href="https://help.github.com/articles/using-pull-requests">Submitting
Pull Requests</a></li>
-<li>
-<p><a href="https://help.github.com/articles/about-git-rebase">Rebasing your
Branch</a></p>
-</li>
-<li>
-<p>Comment the issue in JIRA</p>
-</li>
+<li><a href="https://help.github.com/articles/about-git-rebase">Rebasing your
Branch</a>    </li>
 </ul>
-<p>Finally, add a comment in the JIRA issue with a link to the pull request so we know
the code is ready to be reviewed.</p>
-<ol>
-<li>The review process</li>
-</ol>
-<p>The airavata community will need to review your pull request before it is merged.
If we are slow to respond, feel free to also email the dev mailing list: dev@airavata.apache.org.
</p>
+<h4 id="comment-the-issue-in-jira">Comment the issue in JIRA</h4>
+<p>Finally, add a comment in the JIRA issue with a link to the pull request so we know
the code is ready to be reviewed.   </p>
+<h4 id="the-review-process">The review process</h4>
+<p>The airavata community will need to review your pull request before it is merged.
If we are slow to respond, feel free to also email the dev mailing list: dev@airavata.apache.org.
   </p>
 <p>During the review process you may be asked to make some changes to your submission.
While working through feedback, it can be beneficial to create new commits so the incremental
change is obvious. This can also lead to a complex set of commits, and having an atomic change
per commit is preferred in the end. Use your best judgement and work with your reviewer as
to when you should revise a commit or create a new one.</p>
-<p>A pull request is considered ready to be merged once it gets at lease one +1 from
a reviewer. Once all the changes have been completed and the pull request is accepted, it
must be rebased to the latest upstream version. It is also a good idea to squash all the commits
into a single one, since this will allow us to generate a clean patch and merge it properly.</p>
+<p>A pull request is considered ready to be merged once it gets at lease one +1 from
a reviewer. Once all the changes have been completed and the pull request is accepted, it
must be rebased to the latest upstream version. It is also a good idea to squash all the commits
into a single one, since this will allow us to generate a clean patch and merge it properly.
  </p>
         	</article>
     	</section>
       </div><!--/span-->



Mime
View raw message