Skip to content

Latest commit

 

History

History
129 lines (99 loc) · 6.57 KB

CONTRIBUTING.md

File metadata and controls

129 lines (99 loc) · 6.57 KB
Raw

Contributing Guidelines

The F0.Analyzers open source project is hosted on GitHub, so we start this document off with the GitHub Community Guidelines.

Coding Style

See .editorconfig file.

See also

Development Techniques

Apply test-driven development when adding features or fixing bugs. Follow the rules of Clean Code for the entire codebase.

Version Scheme

See Semantic Versioning.

Although .NET analyzers do not declare a public API, MAJOR, MINOR and PATCH changes for each release are observed from the user's point of view, consumed by tools like Microsoft Visual Studio, JetBrains Rider or MSBuild.

Issues

See GitHub Guides: Issues.

Each issue should be submitted with an intention-revealing title and a descriptive comment. Define the scope of an issue by applying meaningful labels rather than prefixing the title. Before work is started, the issue should have contributing assignees added or updated.

Issues that result in changes to the repository are closed via pull requests.

Branching Workflow

Based on the GitHub flow.

The main branch is the default branch. It includes all verified changes being published in the next release. New topic branches are created off of main. Tags target the main branch.

The publish branch is the second long-running branch. It represents the state of the latest release. On each release published, the publish branch is updated from main and pushed to.

Every change to the repository is committed to short-lived topic branches. New topic branches are based on main. Their work in progress is status checked, reviewed and discussed through pull requests. When approved, the topic branch may be merged into the main branch while maintaining a linear history. After a successful merge, the topic branch should be deleted.

Topic branch naming conventions:

  • all lowercase
  • start with commit type (see Commit Messages)
  • followed by a slash: /
  • end with a short description, use hyphen as word divider: -

Format: {type}/{short-description}
Example: docs/contributing-guidelines

Commit Messages

Based on Conventional Commits, where a major/breaking change is indicated by a ! between the type/scope and the :, and may optionally include a BREAKING CHANGE: footer with additional information.

Another common footer is Co-authored-by: name <name@example.com> to attribute a commit to more than one author. Such trailers should be provided after the BREAKING CHANGE: footer.

Write both the description and the optional body of commit messages in present tense imperative.

For pull requests' squashed merge commit messages, append the Pull-Requests-Number to the end of the commit title surrounded by parentheses.

Format:

<type>[optional scope][!]: <description> [optional pull request number]

[optional body]

[optional footer(s)]

Example:

feat(object-initializer)!: add support for C# 9.0 (#123)

include init-only properties in Object Initializer refactoring
add tests for Records to Object Initializer

BREAKING CHANGE: drop support for Visual Studio 2017
Co-authored-by: name <name@example.com>

Pull Requests

See GitHub Help: Creating a pull request.

The title of a pull request should be the commit message's commit title of the closing squash and merge.

Pull requests that resolve one or many issues should reference these by linking a pull request to an issue using a supported keyword in the pull request's description, such as Closes #123.

Changelog

Based on Keep a Changelog, where the Unreleased section is called vNext, and where changes are grouped by product scope, and where changes within a group begin with a type.

Release Checklist

The ultimate requisite for each release is that all tests pass and the production codebase is both fully covered and asserted.