jupyter | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The following team contract describes a working and a live document that identifies how this team of MDS students will work.
- The overall team goal is to build a DASH app as per the sketch.
- The main concept of the DASH app project is to build a prototype assuming that our team is working for a small company and is intending to provide a prototype sample as indicated in the sketch document
Meeting Norms
- The team has decided to meet two times a week for an hour each, to revise the tasks and assign tasks as each new week unfolds
- We expect to keep parallel to the lecture material in terms of developing our own app
- The contributions.md document will serve as the main project management tool
- Kanban based tasks will be assigned and completed as required
- The team will meet through Zoom and in each meeting, have an updated contributions.md document that is updated based on specific tasks assigned.
Decision Making Norms
- The team acknowledges that there might be several challenges that the team faces as a multitude of decisions could be made with regards to the specific app that is being developed.
- It should be noted that the team resolves to vote and consider all specific ideas in a collegial way, before deciding on a change in the overall project structure
- The team also agrees to consult with Dr. Firas Moosvi (the class instructor on a regular basis) to keep themselves updated on the project tasks as required
- Overall, slack will be used as the primary communication channel, however, the team will also work on using other communication means including emails and watts-app messaging services as appropriate
- Our office hours, when we can expect to collaborate via Microsoft Teams, phone or face-to-face are Monday to Friday 10AM - 5PM
- We are not expected to answer emails past 6PM, on weekends or when we are on holidays or vacation.
- We work in different time zones and respect this, especially when setting up recurring meetings.
- We record meetings when possible, so that team members who could not attend live can listen later.
- We follow the git flow branch naming convention for branches and identify the task number eg. feature/123-add-working-agreement
- We merge all code into main branches and always review existing codes before starting work on a new task
- We treat documentation as code and apply the same standards to Markdown as code
- We communicate what we are working on through the slack
- In event of backlogs, the team will meet and communicate with the instructor to identify an appropriate catch-up strategy
- The risk for having a huge backlog is low as our team plans to meet twice a week and has been consistent in maintainence of open communications