Contributing to PoGo

TL;DR:

Thanks for contributing!

Issues:

• Search through existing issues before you create a new one
• Concise & descriptive issue titles
• Use the template, it's there for a reason. Your post doesn't fit? -> Contact us via social media.

Pull Requests:

• Ask before creating PRs with new features or major rewrites
• Use 4 spaces per indentation level! No tab characters.
• Keep your local master up-to-date, only work in dedicated branches
• Always use git rebase PoGo/master from feature branch instead of merging.

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

New to Git?

• Make sure you have a GitHub account.
• Learning Git:
  • GitHub Help: Good Resources for Learning Git and GitHub.
• GitHub Flow Guide: step-by-step instructions of GitHub flow.

Contributing to Issues

• Check if the issue you are going to file already exists in our GitHub issues.
• If you can't find your issue already, open a new issue, making sure to follow the directions as best you can.

Contributing to Code

Forks and Pull Requests

GitHub fosters collaboration through the notion of pull requests. On GitHub, anyone can fork an existing repository into their own user account, where they can make private changes to their fork. To contribute these changes back into the original repository, a user simply creates a pull request in order to "request" that the changes be taken "upstream".

Additional references:

• GitHub's guide on forking
• GitHub's guide on Contributing to Open Source
• GitHub's guide on Understanding the GitHub Flow

Lifecycle of a pull request

Before submitting

• To avoid merge conflicts, make sure your branch is rebased on the master branch of this repository.
• Many code changes will require new tests, so make sure you've added a new test if existing tests do not effectively test the code changed.
• Clean up your commit history. Each commit should be a single complete change. This discipline is important when reviewing the changes as well as when using git bisect and git revert.

Pull request submission

Always create a pull request to the master branch of this repository.

• Add a meaningful title of the PR describing what change you want to check in. Don't simply put: "Fixes issue #5". A better example is: "Add Ensure parameter to New-Item cmdlet", with "Fixes #5" in the PR's body.

• When you create a pull request, including a summary of what's included in your changes and if the changes are related to an existing GitHub issue, please reference the issue in pull request description (e.g. Closes #11). See this for more details.

Pull Request - Code Review

• After a successful pass, the area maintainers will do a code review, commenting on any changes that might need to be made.

• Additional feedback is always welcome! Even if you are not designated as an area's maintainer, feel free to review others' pull requests anyway. Leave your comments even if everything looks good; a simple "Looks good to me" or "LGTM" will suffice. This way we know someone has already taken a look at it!

• Once the code review is done, and all merge conflicts are resolved, a maintainer should merge your changes.

Common Engineering Practices

We encourage contributors to follow these common engineering practices:

• Format commit messages following these guidelines:

Summarize change in 50 characters or less

Similar to email, this is the body of the commit message,
and the above is the subject.
Always leave a single blank line between the subject and the body
so that `git log` and `git rebase` work nicely.

The subject of the commit should use the present tense and
imperative mood, like issuing a command:

> Makes abcd do wxyz

The body should be a useful message explaining
why the changes were made.

If significant alternative solutions were available,
explain why they were discarded.

Keep in mind that the person most likely to refer to your commit message
is you in the future, so be detailed!

As Git commit messages are most frequently viewed in the terminal,
you should wrap all lines around 72 characters.

Using semantic line feeds (breaks that separate ideas)
is also appropriate, as is using Markdown syntax.

• These are based on Tim Pope's guidelines, Git SCM submitting patches, Brandon Rhodes' semantic linefeeds, and John Gruber's Markdown syntax.

• Don't commit code that you didn't write. If you find code that you think is a good fit to add to PoGo, 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.

• Avoid making big pull requests. Before you invest a large amount of time, file an issue and start a discussion with the community.