-
Notifications
You must be signed in to change notification settings - Fork 1
Working Agreement
Cooper 2.0 is a project that is bound by the requirements of SSW 695. This working agreement is meant to set guidelines as to how this team will deliver Cooper 2.0 for the end of the semester. This agreement will change as necessary as the semester goes on.
- TBD Outside of Class
- Weekly in class
- Github
- Slack
- Every change will be reviewed by all of the team members.
- Every change will require a minimum of 1 approval to merge.
- Every change will execute and pass existing unit tests and generate coverage metrics.
- Every change must have a passing build via CI/CD automation.
- Every change will trigger a code quality report.
Contributing to Cooper 2.0 is intended to be bounded by the requirements of SSW 695. Contributing will be limited to the team members currently enrolled in the class. The future state of this project will be determined once the deliverables for SSW 695 have been finalized.
Contributing will three ingredients from each member:
- Understanding the problems that the platform will provide solutions to.
- Adapting to an Agile team structure and owning all facets of the solution as a team.
- Creating technical and business-oriented requirements using Github Issues.
The template for creating an Issue should be as if you were creating a User Story.
- Who is the user?
- What is the intended functionality?
- Can you test it?
- What part of the platform should this functionality be implemented on?
Example of a well-documented issue:
Title: Cooper 2.0 Functional Availability
Summary: As a developer, I am able to clone this repository and deploy Cooper2.0 on my local machine.
Testing Strategy: Manual Testing (clone via Github) and Automated Testing (automated builds of Cooper2.0 through Travis CI)
Platform Technology: Backend and Frontend
User: Developers
Contributing will require changes to the codebase. Every change should be made through this Github repository.