Commit Policy - otwcode/otwarchive GitHub Wiki

Please make sure to also read our Contributing Guidelines.

Table of Contents

Scary Legal Stuff

  • Please be aware that any code you commit to our projects becomes the property of the OTW and will be licensed under The GNU General Public License. No take-backs. :) Don't commit code if you're not willing for it to be shared forever!
  • Never commit code you didn't write yourself or code that doesn't have a suitable license.
    • If you are adding code written by someone else (for instance a third-party Rails plugin), it must have been released under a license that is the same or *more* permissive than our own license. Please do specify in your commit message how the plugin is licensed.
    • Do not submit code written by AI tools like GitHub Copilot or GitLab Duo; we will not accept pull requests that contain AI-generated code.
  • Never remove licensing info from code.
  • Never use a decompiler or disassembler to look at proprietary code.

Commit Rules

  • Your branch name should include the id of the Jira issue you are working on, e.g. AO3-1234 or AO3-1234_short_description
  • Start every commit message with the issue id and include a meaningful explanation of the changes in your commit, e.g. AO3-1234 Fix typo in work.rb
  • Commit only one thing at a time. Don't commit unrelated changes together, or a change and a fix at the same time.
  • Make sure that you are committing only the files you need.
  • Make sure your code matches the Coding Standards.
  • Send in your code as a pull request on GitHub.
    • Make sure to use the template provided!

Commit Steps

  • Make sure master is up-to-date first.

    git checkout master
    git pull upstream master
  • Merge master into your branch. Resolve any conflicts.

    git checkout your_branch_name
    git merge master
  • Run all relevant tests on your branch before submitting a pull request.

    bundle exec cucumber features
    bundle exec rspec spec
  • Do something nice for yourself! :)

Good Practice

  • Merge with the master branch frequently to catch any conflicts early
  • If you are fixing or changing something without an issue, open one so that your change can be tested and tracked.
  • If your changes include a migration, refer to the Migrations guide.
  • Don't force-push to your branch after it has been reviewed. Prefer merging over rebasing for already pushed code.
    • Pull requests are squashed when they are merged by AD&T, so any amount of commits on the branch (including merge commits) will still only show up as a single commit in the history on master.

Merging

Our code reviewers with merge permissions are ariana-paris, Bilka2, bingeling, brianjaustin, CristinaRO, neuroalien, redsummernight, sarken, scottsds, and zz9pzza. Drive-by code review and discussion of anybody else's code is always welcome - we can all learn more - but please remember to keep it constructive.

Stalled Pull Requests and Jira Issues

If a pull request has had its label set to "Reviewed: Action Needed" for over a year with no action by the coder, official AD&T volunteers may adopt the PR (with credit) without prior notification.

If a Jira issue has been in the "To Do" or "In Progress" status for over a year without a submitted pull request, official AD&T volunteers may set the issue back to unassigned without prior notification so that it can be picked up by another coder.

We may also do these (with notification) if an existing issue is high priority or becomes high priority.

⚠️ **GitHub.com Fallback** ⚠️