source/get-involved.md

layout: page id: get-involved

  </p>

  <h4>Mailing Lists</h4>
  <p>Your first engagement with the project should be to subscribe to our <a href="mailing-list.html">mailing lists</a>.</p>

  <h4>Decision Making</h4>
  <p>
      The most important thing about engaging with any Apache project is that everyone is equal. All people with an opinion are entitled to express that opinion and, where appropriate, have it considered by the community.
  </p>

  <p>
      To some the idea of having to establish consensus in a large and distributed team sounds inefficient and frustrating. Don't despair though, The Apache Way has a set of simple processes to ensure things proceed at a good pace.
  </p>

  <p>
      In ASF projects we don't like to vote. We reserve that for the few things that need official approval for legal or process reasons (e.g. a release or a new committer). Most of the time we work with the consensus building techniques documented below.
  </p>

  <h4>Lazy Consensus</h4>
  <p>
    <a href="lazy-consensus.html">Lazy consensus</a> is the first, and possibly the most important, consensus building tool we have. Essentially lazy consensus means that you don't need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.
  </p>

  <h4>Consensus Building</h4>
  <p>
    Sometimes lazy consensus is not appropriate. In such cases it is necessary to make a proposal to the mailing list and discuss options. There are mechanisms for quickly showing your support or otherwise for a proposal and <a href="consensusBuilding.html">building consensus</a> amongst the community.
  </p>

  <p>
    Once there is a consensus people can proceed with the work under the <a href="lazy-consensus.html">lazy consensus</a> model.
  </p>

  <h4>Voting</h4>
  <p>
    Occasionally a "feel" for consensus is not enough. Sometimes we need to have a measurable consensus. For example, when voting in new committers or to approve a release.
  </p>



</div>

<div id="how-to-contribute" class="section scrollspy">
  <h2 style="margin-top:50px;" class="header">How to contribute</h2>

    <h4 id="apache-airavata-contribution-guide">Apache Airavata Contribution Guide</h4>
    <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="development.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>
    <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><a href="https://help.github.com/articles/about-git-rebase">Rebasing your Branch</a>    </li>
    </ul>
    <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>
    <h4 id="accepting-contributions">Accepting Contributions</h4>
    <p>Developers with Airavata Commit access should read <a href="http://airavata.staging.apache.org/community/how-to-commit-contributed-code.html">Accepting Contribtions</a> on steps to accept the contributed code</p>

</div>