github.com/muhammedhassanm/blockchain@v0.0.0-20200120143007-697261defd4d/sawtooth-core-master/docs/source/community/contributing.rst (about)

     1  ------------
     2  Contributing
     3  ------------
     4  
     5  ==========================================
     6  Ways to Contribute to Hyperledger Sawtooth
     7  ==========================================
     8  
     9  Contributions from the development community help improve the capabilities of
    10  Hyperledger Sawtooth. These contributions are the most effective way to
    11  make a positive impact on the project.
    12  
    13  Ways you can contribute:
    14  
    15  * Bugs or issues: Report problems or defects found when working with Sawtooth
    16  * Core features and enhancements: Provide expanded capabilities or optimizations
    17  * Documentation: Improve existing documentation or create new information
    18  * Tests for events and results: Add functional, performance, or scalability
    19    tests
    20  
    21  Hyperledger Sawtooth issues can be found in :ref:`jira`.  Any unassigned items
    22  are probably still open. When in doubt, ask on RocketChat about
    23  a specific JIRA issue (see :doc:`join_the_discussion`).
    24  
    25  ==================
    26  The Commit Process
    27  ==================
    28  
    29  Hyperledger Sawtooth is Apache 2.0 licensed and accepts contributions
    30  via `GitHub <https://github.com/hyperledger/sawtooth-core>`_
    31  pull requests. When contributing code, please follow these guidelines:
    32  
    33  * Fork the repository and make your changes in a feature branch
    34  * Include unit and integration tests for any new features and updates
    35    to existing tests
    36  * Ensure that the unit and integration tests run successfully. Run both
    37    of these tests with ``./bin/run_tests``
    38  * Check that the lint tests pass by running ``./bin/run_lint -s master``.
    39  
    40  **Pull Request Guidelines**
    41  
    42  A pull request can contain a single commit or multiple commits. The most
    43  important guideline is that a single commit should map to a single fix or
    44  enhancement. Here are some example scenarios:
    45  
    46  * If a pull request adds a feature but also fixes two bugs, the pull
    47    request should have three commits: one commit for the feature change and
    48    two commits for the bug fixes.
    49  * If a PR is opened with five commits that contain changes to fix a single
    50    issue, the PR should be rebased to a single commit.
    51  * If a PR is opened with several commits, where the first commit fixes one issue
    52    and the rest fix a separate issue, the PR should be rebased to two
    53    commits (one for each issue).
    54  
    55  **Important:**
    56    Your pull request should be rebased against the current master branch. Do
    57    not merge the current master branch in with your topic branch. Do not use the
    58    Update Branch button provided by GitHub on the pull request page.
    59  
    60  **Commit Messages**
    61  
    62  Commit messages should follow common Git conventions, such as using the
    63  imperative mood, separate subject lines, and a line length of 72 characters.
    64  These rules are well documented in `Chris Beam's blog post
    65  <https://chris.beams.io/posts/git-commit/#seven-rules>`_.
    66  
    67  **Signed-off-by**
    68  
    69  Each commit must include a "Signed-off-by" line in the commit message
    70  (``git commit -s``). This sign-off indicates that you agree the commit satisfies
    71  the `Developer Certificate of Origin (DCO) <http://developercertificate.org/>`_.
    72  
    73  **Commit Email Address**
    74  
    75  Your commit email address must match your GitHub email address. For more
    76  information, see
    77  https://help.github.com/articles/setting-your-commit-email-address-in-git/
    78  
    79  **Important GitHub Requirements**
    80  
    81  A pull request cannot merged until it has passed these status checks:
    82  
    83  * The build must pass on Jenkins
    84  * The PR must be approved by at least two reviewers without any
    85    outstanding requests for changes
    86  
    87  **Integrating GitHub Commits with JIRA**
    88  
    89  You can link JIRA issues to your commits, which  will integrate
    90  developer activity with the associated issue. JIRA uses the issue key to
    91  associate the commit with the issue, so that the commit can be summarized in the
    92  development panel for the JIRA issue.
    93  
    94  When you make a commit, add the JIRA issue key to the end of the commit message
    95  or to the branch name. Either method should integrate your commit with the JIRA
    96  issue that it references.
    97  
    98  .. Licensed under Creative Commons Attribution 4.0 International License
    99  .. https://creativecommons.org/licenses/by/4.0/