x First time here? Check out the FAQ

Contributing to Umbraco

    How to fix bugs for Umbraco

    This is a guide to how you can contribute back to Umbraco with fixing bugs and code changes. 
    Although there is a crack team of ninjas behind the project not all issues can be resolved in a time which you may deem speedy enough.

    Who can fix bugs

    With the move of Umbraco to Mercurial as a source control system it's easy for anyone in the community to contribute back with bug fixing.
    All pull requests that are sent from the community will be reviewed by the Umbraco core to ensure that they meet the committer guidelines which will be outlined below. Any pull request which is submitted that doesn't meet the guidelines will not be accepted back into the core.

    Creating forks

    If you are looking to fix bugs within Umbraco then you need to create a fork of the Umbraco code in which you can do your changes and then produce a pull request. To do this you need to:
    - Create a fork, so navigate to umbraco.codeplex.com/SourceControl/list/changesets and click the Create Fork option
    - Enter a name for the fork and a description and click Save
    Note the rest of this document is going to assume you're familiar with working with Mercurial in terms of cloning repositories, etc. Refer to the appropriate Mercurial documentation if you aren't sure what to do next

    Preparing a pull request

    The following section is going to cover what the Umbraco code reviewers will be looking at when they are reviewing a pull request.

    Named branches

    When you are working in your own clone you have the choice of working in your own named branch or working aginst one of the existing branched. Generally speaking pull requests are expected to have their fixes against one of the named branches which are in the core Umbraco repository.
    There are a few reasons for this:
    - We know exactly what version of Umbraco your fix(es) are targetting
    - It keeps the branch list in Umbraco small
    There is a small exception to this rule, when a bug fix requires extremely large amounts of code refactoring. When you are doing a change that requires its own named branch then the named branch much be in the format of release-issue-id, for example, 4.6.0-1234.

    Associating with issues

    Any pull request that is submitted must list out the issues which it is resolving. All changes must be associated with a work item, a pull request won't be accepted unless there are work items which it is fixing.
    If you are fixing something that doesn't already have an issue which is listed in the CodePlex issue register then you will need to create one.
    Any pull request which doesn't have associated work items will be declined.
    Note - Work Items are subject to their own guidelines, available here: our.umbraco.org/.../submitting-bug-reports and may be rejected in addition to rejecting the pull request.

    Unit tests

    Umbraco has a large suite of unit tests covering a good portion of the codebase. Any pull request should not cause any the unit tests to fail. Where possible it is expected that the new code has supporting unit tests to ensure the bug is resolved.

    Keeping in sync with the core repository

    When a pull request is submitted it should be syncronized in line with the core repository, with your changes representing the tip tag (meaning it was the last commit to the repository) and all merge conflicts should have been resolved.