github.com/hpcng/singularity@v3.1.1+incompatible/CONTRIBUTING.md (about)

     1  # Contributor's Agreement
     2  
     3  You are under no obligation whatsoever to provide any bug fixes, patches,
     4  or upgrades to the features, functionality or performance of the source
     5  code ("Enhancements") to anyone; however, if you choose to make your
     6  Enhancements available either publicly, or directly to the project,
     7  without imposing a separate written license agreement for such
     8  Enhancements, then you hereby grant the following license: a non-exclusive,
     9  royalty-free perpetual license to install, use, modify, prepare derivative
    10  works, incorporate into other computer software, distribute, and sublicense
    11  such enhancements or derivative works thereof, in binary and source code
    12  form.
    13  
    14  
    15  # Contributing
    16  
    17  When contributing to Singularity, it is important to properly communicate the
    18  gist of the contribution. If it is a simple code or editorial fix, simply
    19  explaining this within the GitHub Pull Request (PR) will suffice. But if this
    20  is a larger fix or Enhancement, you are advised to first discuss the change
    21  with the project leader or developers.
    22  
    23  Please note we have a code of conduct, described below. Please follow it in
    24  all your interactions with the project members and users.
    25  
    26  ## Pull Requests (PRs)
    27  
    28  1. Essential bug fix PRs should be sent to both master and release branches.
    29  2. Small bug fix and feature enhancement PRs should be sent to master only.
    30  3. Follow the existing code style precedent, especially for C. For Golang, you
    31     will mostly conform to the style and form enforced by the "go fmt" and
    32     "golint" tools for proper formatting.
    33  4. Ensure any install or build dependencies are removed before doing a build
    34     to test your PR locally.
    35  5. For any new functionality, please write appropriate go tests that will run
    36     as part of the Continuous Integration (Circle CI and Travis) systems.
    37  6. Make sure that the project's default copyright and header have been included 
    38     in any new source files.
    39  7. Make sure you have locally tested using `make test` and that all tests succeed
    40     before submitting the PR.
    41  8. To conform to the Golang standards and idioms, make sure you have done the 
    42     following:
    43      - Run `go fmt ./...` to format all `.go` files. We use `go1.11`'s 
    44        formatting as our standard
    45      - Left a function comment on **every** new exported function and package that
    46        your PR has introduced. To learn about how to properly comment Golang code, read [this post on golang.org](https://golang.org/doc/effective_go.html?#commentary)
    47  9. Is the code human understandable? This can be accomplished via a clear code
    48     style as well as documentation and/or comments.
    49  10. The pull request will be reviewed by others, and finally merged when all
    50     requirements are met.
    51  11. The `CHANGELOG.md` must be updated for any of the following changes:
    52      - Renamed commands
    53      - Deprecated / removed commands
    54      - Changed defaults / behaviors
    55      - Backwards incompatible changes
    56      - New features / functionalities
    57  12. PRs which introduce a new Golang dependency to the project via `dep` must include a justification for introducing the dependency. Ideally, newly introduced dependencies should also be pinned to a specific version.
    58  
    59  ## Documentation
    60  There are a few places where documentation for the Singularity project lives. The [changelog](CHANGELOG.md) is where PRs should include documentation if necessary. When a new release is tagged, the [user-docs](https://www.sylabs.io/guides/3.0/user-guide/) and [admin-docs](https://www.sylabs.io/guides/3.0/admin-guide/) will be updated using the contents of the `CHANGELOG.md` file as reference.
    61  
    62  1. The [changelog](CHANGELOG.md) is a place to document **functional** differences between versions of Singularity. PRs which require documentation must update this file. This should be a document which can be used to explain what the new features of each version of Singularity are, and should **not** read like a commit log. Once a release is tagged (*e.g. v3.0.0*), a new top level section will be made titled **Changes Since vX.Y.Z** (*e.g. Changes Since v3.0.0*) where new changes will now be documented, leaving the previous section immutable.
    63  2. The [README](README.md) is a place to document critical information for new users of Singularity. It should typically not change, but in the case where a change is necessary a PR may update it.
    64  3. The [user-docs](https://www.github.com/sylabs/singularity-userdocs) should document anything pertinent to the usage of Singularity.
    65  4. The [admin-docs](https://www.github.com/sylabs/singularity-admindocs) document anything that is pertinent to a system administrator who manages a system with Singularity installed.
    66  5. If necessary, changes to the message displayed when running `singularity help *` can be made by editing `docs/content.go`.
    67  
    68  
    69  # Code of Conduct
    70  
    71  ## Our Pledge
    72  
    73  In the interest of fostering an open and welcoming environment, we as
    74  contributors and maintainers pledge to making participation in our project and
    75  our community a harassment-free experience for everyone, regardless of age, body
    76  size, disability, ethnicity, gender identity and expression, level of experience,
    77  nationality, personal appearance, race, religion, or sexual identity and
    78  orientation.
    79  
    80  ## Our Standards
    81  
    82  Examples of behavior that contributes to creating a positive environment
    83  include:
    84  
    85  * Using welcoming and inclusive language
    86  * Being respectful of differing viewpoints and experiences
    87  * Gracefully accepting constructive criticism
    88  * Focusing on what is best for the community
    89  * Showing empathy towards other community members
    90  
    91  Examples of unacceptable behavior by participants include:
    92  
    93  * The use of sexualized language or imagery and unwelcome sexual attention or
    94    advances
    95  * Trolling, insulting/derogatory comments, and personal or political attacks
    96  * Public or private harassment
    97  * Publishing others' private information, such as a physical or electronic
    98    address, without explicit permission
    99  * Other conduct which could reasonably be considered inappropriate in a
   100    professional setting
   101  
   102  ### Our Responsibilities
   103  
   104  Project maintainers are responsible for clarifying the standards of acceptable
   105  behavior and are expected to take appropriate and fair corrective action in
   106  response to any instances of unacceptable behavior.
   107  
   108  Project maintainers have the right and responsibility to remove, edit, or
   109  reject comments, commits, code, wiki edits, issues, and other contributions
   110  that are not aligned to this Code of Conduct, or to ban temporarily or
   111  permanently any contributor for other behaviors that they deem inappropriate,
   112  threatening, offensive, or harmful.
   113  
   114  ## Scope
   115  
   116  This Code of Conduct applies both within project spaces and in public spaces
   117  when an individual is representing the project or its community. Examples of
   118  representing a project or community include using an official project e-mail
   119  address, posting via an official social media account, or acting as an appointed
   120  representative at an online or offline event. Representation of a project may be
   121  further defined and clarified by project maintainers.
   122  
   123  ## Enforcement
   124  
   125  Instances of abusive, harassing, or otherwise unacceptable behavior may be
   126  reported by contacting the project leader (gmkurtzer@gmail.com). All
   127  complaints will be reviewed and investigated and will result in a response
   128  that is deemed necessary and appropriate to the circumstances. The project
   129  team is obligated to maintain confidentiality with regard to the reporter of
   130  an incident. Further details of specific enforcement policies may be posted
   131  separately.
   132  
   133  Project maintainers, contributors and users who do not follow or enforce the
   134  Code of Conduct in good faith may face temporary or permanent repercussions 
   135  with their involvement in the project as determined by the project's leader(s).
   136  
   137  ## Attribution
   138  
   139  This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
   140  available at [http://contributor-covenant.org/version/1/4][version]
   141  
   142  [homepage]: http://contributor-covenant.org
   143  [version]: http://contributor-covenant.org/version/1/4/