UCF Developer Contributing Projects Conventions Guide
- Give issue at least two labels
- Milestones: If you know the release milestone it should be under, use that. If it's a wishlist "someday" type of feature assign the "On Hold - Future Release Issues" milestone. Otherwise leave it blank and the project managers will assign it as desired.
- Project: Leave blank
- Only work on issues in the upcoming release milestone.
- Exception: If the upcoming release milestone has no unassigned issues you can work on features in the next release milestone.
- Make sure to assign yourself to the issue that you're working on. If you abandon the issue remove yourself as the assignee.
- Pull requests should be created from your fork.
- Assign the base to the dev branch for the release you're working on.
- In the description write "Fixes #IssueNumber" on the first line if this PR will fix an issue.
- Assign "ucfopen/obojobo-next-devs" as the Reviewer
- If you've addressed a PR review and are ready for a re-review, hit the rotating circle icon next to the obojobo-next-devs user in the Reviewers column.
- Pull requests typically will only be merged in if all tests pass and they have two approved reviews.
- Exceptions apply for hot fixes or critical issues.
Releases are held in three week sprints:
- Week 1: Development begins on a new release.
- Week 2: Development on the release continues.
- Week 3: This week is focused on testing and reviewing. During this week we'll publish the new release and update UCF's production server with the final tagged release.
