Commit Policy - otwcode/otwarchive GitHub Wiki
Please make sure to also read our Contributing Guidelines.
- 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.
- Your branch name should include the id of the Jira issue you are working on, e.g.
AO3-1234orAO3-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!
-
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
- Follow the steps in "Submitting a pull request" and "After submitting a pull request" on the AO3 Coding: Your First Pull Request page.
- Do something nice for yourself! :)
- 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.
- 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
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.
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.