Table of Contents

Contributing to XToolkit

This document describes contribution guidelines that are specific to XToolkit.

General contribution guidance is included in this document. Additional guidance is defined in the documents linked below.

Coding Style Changes

Follow the style used by the C# Coding Guidelines.

Also:

  • DO NOT send PRs for style changes. For example, do not send PRs that are focused on changing usage of Int32 to int.
  • DO give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.

Pull Requests

We are happy to receive Pull Requests adding new features and solving bugs. As for new features, please contact us before doing major work. To ensure you are not working on something that will be rejected due to not fitting into the XToolkit roadmap or ideal of the framework.

  • DO submit all code changes via pull requests (PRs) rather than through a direct commit. PRs will be reviewed and potentially merged by the repo maintainers after a peer review that includes at least one maintainer.
  • DO give PRs short-but-descriptive names (e.g. "Improve code coverage for System.Console by 10%", not "Fix #1234")
  • DO refer to any relevant issues, and include keywords that automatically close issues when the PR is merged.
  • DO tag any users that should know about and/or review the change.
  • DO ensure each commit successfully builds. The entire PR must pass all tests in the Continuous Integration (CI) system before it'll be merged.
  • DO address PR feedback in an additional commit(s) rather than amending the existing commits, and only rebase/squash them when necessary. This makes it easier for reviewers to track changes.
  • DO assume that "Squash and Merge" will be used to merge your commit unless you request otherwise in the PR.
  • DO NOT mix independent, unrelated changes in one PR. Separate real product/test code changes from larger code formatting/dead code removal changes. Separate unrelated fixes into separate PRs, especially if they are in different assemblies.

Issues

Issues should clearly lay out the problem, platforms experienced on, as well as steps to reproduce the issue.

This aids in fixing the issues but also quality assurance, to check that the issue has indeed been fixed.

Issues are labelled in the following way depending on its type:

  • bug: The issue is a bug in the product.
  • enhancement: The issue is an enhancement to either an existing feature in the product or to the infrastructure around the development process.
  • documentation: A documentation-related task.
  • c/__: Specifies the component of the task.
  • e/__: Specifies the effort required for the task.
  • p/__: Specifies the priority of the task.

Commit Messages

Please format commit messages as follows (based on A Note About Git Commit Messages):

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

Also do your best to factor commits appropriately, not too large with unrelated things in the same commit, and not too small with the same small change applied N times in N different commits.

File Headers

The following file header is the used for XToolkit. Please use it for new files:

// Developed by Softeq Development Corporation
// http://www.softeq.com

Also, you can use bash script for set headers: tools/set-headers.sh

Edit this page