PowerShell/.github/CONTRIBUTING.md
2016-06-27 12:12:19 -07:00

6.7 KiB

Contribute to PowerShell

We welcome and appreciate contributions from the community. There are many ways to become involved with PowerShell, including filing issues, joining in design conversations, writing and improving documentation, contributing to code. Please read the rest of this document to ensure a smooth contribution process.

New to Git?

Quick Start Check-list

Contributing to Issue

  • Review the GitHub Issue Management process. It covers the triage process and the definition of Label, Assignee and the guidance like verifying and closing issues
  • Check if the issue you are going to file already exists in GitHub Issue query
  • Submit an issue, assuming it does not exist yet, via GitHub Issue track by following the issue template.

Contributing to Documentation

  • TODO: Don will fill in the details

Contributing to Code

Making Breaking Changes

When you make code changes, please pay attention to these that can affect the Public Contract, for example, PowerShell parameter, API or protocols changes. Before starting making changes to the code, first review the Breaking Changes guidelines and follow the guidelines to keep PowerShell backward compatible.

Making Design Changes

To add new features such as cmdlets or making design changes, please follow the PowerShell Request for Comments (RFC) process.

Common Engineering Practices

Other than the guidelines (coding, RFC process for design, documentation and testing) discussed above, following are common engineering practices we would like everyone to follow:

Summarize change in 50 characters or less

Provide more detail after the first line. Leave one blank line below the
summary and wrap all lines at 72 characters or less.

If the change fixes an issue, leave another blank line after the final
paragraph and indicate which issue is fixed in the specific format
below.

Fix #42
  • Don't commit code that you didn't write. If you find code that you think is a good fit to add to PowerShell, file an issue and start a discussion before proceeding
  • Create and/or update tests when making code changes
  • Run tests and ensure they are passing before pull request
  • All pull requests must pass CI systems before they can be approved
  • Avoid making a big pull requests. Instead, file an issue and start a discussion with the community before you invest a large amount of time
  • Blog and tweet about your contributions frequently!

File Headers

The following file header is the used for PowerShell. Please use it for new files. For more information, see coding guidelines.

// …  TODO TODO
// Licensed to the PowerShell …. under one or more agreements.
// See the LICENSE file in the project root for more information.

You can find here for the PowerShell sources license and copyright information.

Contributor License Agreement

You must sign a PowerShell Contribution License Agreement (CLA) before your Pull Request will be merged. This a one-time requirement for the PowerShell project. Signing the CLA process is simple and can be done in less than a minute. You can read more about Contribution License Agreements (CLA) on wikipedia.

You don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. When your pull-request is created, it is classified by a CLA bot. If the change is trivial (e.g. you just fixed a typo), then the PR is labelled with cla-not-required. Otherwise it's classified as cla-required. Once you signed a CLA, the current and all future pull-requests will be labelled as cla-signed.