Skip to content

Latest commit

 

History

History
98 lines (71 loc) · 4.11 KB

CONTRIBUTING.md

File metadata and controls

98 lines (71 loc) · 4.11 KB
Raw

Contributing code

Things to know when 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.
  • We don't accept pull requests for translated strings (i.e. anything under locale/). Please use Pontoon instead.

Conventions

  • 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.

  • We use the following labels for pull requests:

    • needs rebase: This pull request needs to be rebased against the master branch.
    • needs tests: The changes in this pull request need additional tests.
    • not ready: This pull request isn't ready to merge. If it requires feedback or answers from someone, please tag that person in the PR comments.
    • webops: This pull request is blocked on additional work by webops that must be done before it lands.

  • When a Pull request is ready to merge, one of the reviewers will merge it.

What to work on

We keep a good list of starting mentored bugs on the MDN "Getting Involved" page.

If you have questions about what to work on, you can ask:

How to submit code

MDN development process is very much like these Mozilla Webdev guidelines.

The GitHub Flow site is a great interactive guide to the flow described here.

GitHub workflow

  1. Install our development environment.

  2. Create a branch for your bug:

    git checkout -b new-issue-888888

  3. Code on the bug branch.

  4. Commit changes to bug branch:

    git add .
git commit -m 'fix bug 888888 - commit message'

  5. Push branch to GitHub:

    git push origin new-issue-888888

  6. Send pull request on GitHub.