Skip to content

Latest commit

 

History

History
49 lines (31 loc) · 3.03 KB

CONTRIBUTE.md

File metadata and controls

49 lines (31 loc) · 3.03 KB

Contributing to mezzanine-community

Thanks for stopping by to contribute the mezzanine-community repository! The following is a set of guidelines for contributing.

Table Of Contents

Bugs and Suggestions

Before attempting to fix the issue/bug on your own, it is recommended to open an issue using the built-in issues page provided in this GitHub repository. One of our maintainers will get around to your issue as soon as possible. After review, the maintainer may fix the issue on his/her own, or request the subject step in to fix the observed issue. If inclined, at this point you should fork the repository, make said edits, and submit a Pull Request.

Please make sure you comply with the following criteria when creating/submitting your issue:

  • Use a clear and descriptive title for the issue to identify the problem/suggestion.
  • Describe the exact steps to reproduce the problem in as many details as possible in the case of a problem or suggestion.
  • Mention location where was this issue is found / what will your suggestion affect.

Contribution

Community contributions are always Welcome! This section is intended to help anyone interested in contributing to this repository. Before contributing, first get the approval from repository maintainers and community by raising a GitHub issue using the guidelines mentioned above.

After getting approval, you will need to do the following(these instructions assume you are a [GitHub user](GitHub Signup page):

  • Step 2: Make changes, commit and push to your fork
  • Step 3: Submit Pull Request

Make sure you follow the guidelines for submitting a Pull Request:

  • 1: Make sure you sign-off your commit and pull request: You can add it using the git command $ git commit -s . or manually add it to your commit and pull request Signed-off-by: NAME <committer-email>
  • 2: Start with a one-line summary (50 characters maximum), followed by a blank line. This format is used by git and Gerrit for various displays.
  • 3: Starting on the third line, enter a longer description: This description should focus on what issue the change solves, and how it solves it. The second part is somewhat optional when implementing new features, though desirable.
  • 4: Here is an example commit message:
    short description on first line
    
    more detailed description of your patch,
    which is likely to take up multiple lines.
    

For any additional questions/help, please visit us in IRC Channel: #OpenHours