Skip to content

Latest commit

 

History

History
65 lines (51 loc) · 3.59 KB

CONTRIBUTING.md

File metadata and controls

65 lines (51 loc) · 3.59 KB
Raw

Contributing Code

  • You agree to license your contributions under MPL 2

  • Discuss large changes on the dev-mdn mailing list or on a bugzilla bug before coding.

  • Python code style should follow PEP8 standards whenever possible.

  • All commit messages must start with "bug NNNNNNN" or "fix bug NNNNNNN"

    • Reason: Make it easy for someone to consume the commit log and reach originating requests for all changes
    • Exceptions: "Merge" and "Revert" commits
    • Notes:
      • "fix bug NNNNNNN" - will trigger a github bot to automatically mark bug as "RESOLVED:FIXED"
      • If a pull request has multiple commits, we should squash commits together or re-word commit messages so that each commit message contains a bug number

  • MDN module owner or peer must review and merge all pull requests.

    • Reason: Owner and peers are and accountable for the quality of MDN code changes
    • Exceptions: Owners/peers may commit directly to master for critical security/down-time fixes; they must file a bug for follow-up review.

  • Pull requests that contain changes to database migrations or any other code changes that modify the database layout MUST have been reviewed at least by two peers, one of which MUST be a module owner.

    • Reason: Changes to database tables are critical and may lead to loss of data.
    • Exceptions: None.
    • Notes: A great way to get a 2nd review is to explain the migration to someone who wasn't involved in its development or 1st review.

  • MDN reviewers must verify sufficient test coverage on all changes - either by new or existing tests

    • Reason: Automated tests reduce human error involved in reviews
    • Notes: The Django site has good testing docs

What to work on

Good starting projects are listed on GitHub and Bugzilla. If you have any questions, just ask in the #mdndev IRC channel on irc.mozilla.org!

How to submit code

GitHub workflow

  1. Install our development environment
  2. Set up mozilla remote ($ git remote add mozilla git://github.com/mozilla/kuma.git)
  3. Create a branch for a bug ($ git checkout -b new-issue-888888)
  4. Develop on bug branch.

[Time passes, the mozilla/kuma repository accumulates new commits] 5. Commit changes to bug branch ($ git add . ; git commit -m 'fix bug 888888 - commit message') 6. Fetch mozilla ($ git fetch mozilla) 7. Update local master ($ git checkout master; git pull mozilla master)

Repeat steps 4-7 till dev is complete

  1. Rebase issue branch ($ git checkout new-issue-888888; git rebase master)
  2. Push branch to GitHub ($ git push origin new-issue-888888)
  3. Issue pull request (Click Pull Request button)