Once the project is complete, a pull request of your work back to the upstream repository should be made in the spirit of collaboration and growth of PyCut.
Analysis
This issue should be the last one closed for the semester. Once the project is at a "final" state, a team member can initiate a single, large pull request of the repository to the upstream. Since instead of smaller, incremental PRs we are doing one big one, it would be courtesy for the upstream maintainer to see what changes you are adding in your pull request and how rigorously they have been tested. A bulletpoint changelog of additions, modifications, and removals would expedite the process for the PR to be merged back into the upstream version and to cut a new release.
As noted, it's also a good idea to make notes of (1) what the proposed changes were tested on (e.g. what XO model), and (2) any other notes about the changes that should be made known.
Implementation
At end of project, compile a list of additions, modifications, and removals to PyCut since you all started working on it
Format the changes into a bulletpoint changelog
One team member initiates the PR back to the upstream FOSSRIT/PyCut repository
An upstream maintainer reviews changes, provides feedback as necessary
Related to FOSSRIT/PyCut#37.
Summary
Once the project is complete, a pull request of your work back to the upstream repository should be made in the spirit of collaboration and growth of PyCut.
Analysis
This issue should be the last one closed for the semester. Once the project is at a "final" state, a team member can initiate a single, large pull request of the repository to the upstream. Since instead of smaller, incremental PRs we are doing one big one, it would be courtesy for the upstream maintainer to see what changes you are adding in your pull request and how rigorously they have been tested. A bulletpoint changelog of additions, modifications, and removals would expedite the process for the PR to be merged back into the upstream version and to cut a new release.
As noted, it's also a good idea to make notes of (1) what the proposed changes were tested on (e.g. what XO model), and (2) any other notes about the changes that should be made known.
Implementation