Create an application that allows the user to bring in their video, and use algorithms in order to change the speed of the video to varying speeds, while maintining the best quality possible.
Team will have mandatory meetings with our client, Brian Thomas, Mondays at 11 am, and with Rex, Wednesdays at 8:40 am.
Josh: Front End Lead
Luka: File Management and Manipulation
Max: Algorithm Developer
Sean: NVIDIA API Expert
Team members will use the following process to develop a feature or bug fix.
- Create a branch using the following naming convention:
<initials>‐<name‐of‐feature>e.g.nd‐dev‐standards
- When you are ready for feedback on your changes, even if they are not ready to be fully reviewed, open a pull request.
- When your changes are ready for review, mark your pull request with the yellow review label. Strive to resolve merge conflicts with master before asking for review.
- Pull requests require at least one other teammate to review and sign off via GitHub pull request approval. Feel free to add an LGTM, 🚢 (
type :ship:), or other similar comment in the comment thread so the pull request creator is notified about your approval.
- Pull requests with systemic or sweeping changes require all teammates to review and sign off.
- Code review responsibilities should be divided among all teammates.
- The pull request creator will make any reasonable changes requested by reviewers until the pull request is approved.
- When a pull request passes the review requirements and is ready to merge, remove the review label and add the blue ship label.
- The pull request creator will ship the feature into master with a squash commit via GitHub. Commit messages should, at a minimum, contain a concise but descriptive explanation of the changes.
- Commit messages can contain references to issue numbers for auto‐resolution. e.g.
Closes #10 - Delete your feature branch after it is merged into master. In general, we should keep feature branches for 1‐2 weeks after merging in case we need to reference them post‐merge.
- Consider resolving merge conflicts with the
git town‐synccommand of git‐town, a tool that simplifies Git workflows.
- If a pull request is accidentally merged without squashing, the pull request creator is responsible for reverting the offending commits with
git revertor an equivalent command. Since the original pull request should have already passed review, the creator has authority to open a new pull request with the original changes, mark it with the ship label, and immediately squash commit the changes into master. - If a pull request is accidentally merged before review, the pull request creator is responsible for reverting the offending commits with
git revertor an equivalent, reopening a pull request, and marking it with the review label. ﴾This should happen rarely since our project settings don't allow merging via the web unless the pull request has been reviewed and approved.﴿