Operation and Process
This documents the general operation of the team.
Roles and Responsibilities
Category: Customer | Triage / Escalation: Internal | Sustaining: Internal | Success: Learner |
---|---|---|---|
Goal / Impact | |||
Overview |
|
Existing set of service we provide to our learners:
| (TBD, similar to the sustaining: internal, but this calls out the project work / teams / prioritization that this team does. |
Stakeholders |
|
What We are Not
- Taking on a project without explicit consent from all members of the team
- Dive into a new technology area without:
- Clear motivation
- Support
- Conversation
- Plan
- Expectation
- Isolated. We should communicate with Educator escalation regularity to discuss
- Issues impact both
- Best practices
- Technical knowledge
Development Process
- We shall employ Kanban as our development process.
We chose this agile methodology because it's flexible for interrupt and quick priority change. We anticipate interrupt and quick priority change will be the norm for this team
- Our Kanban board is [Spartans] Product Development Board
- We also have a filter for continuous prioritization at Getting issues...
Code Review Best Practices
- Communicate about the design and architecture of the solution in PR with code reviewers before you put up a PR.
- Use Request to Review feature on Github
- Fill out on the PR what you did to validate the fix (Your local environment or other environments)
- It's better to squash commits after code review is done