# OSCAL Team Development Culture ## OSCAL Engineering Norms - Issue essentialism - Focus on the highest identified priority items assigned to me. - Risks are identified as soon as possible; mitigations are also identified as soon as possible. - An issue is complete when it is tested, documented, and all goals and acceptence criteria are met. - Find the essential path to completing the issue; avoid labor intensive and tangential paths. - Estimate time spent on issues as accurately as possible. If unclear, overestimate. It is important to not be optimistic and have a manageable workload every sprint. - Issue clarity and transparency - Be clear on the who, what, when, where, and how around issue development - The issue assignee must ensure issue goals and acceptance criteria are clear at the point of assignment - Issue status is reported as significant changes occur - Summarize any offline discussions or decisions in the issue conversation to provide for transparency. - Be intentional about development languages and technologies - Discuss a new technology with the team prior to use. - Teach other team members about technologies you use. - Teamwork and collaboration - Provide code review and feedback on the readability/understandability/maintainability of the solution. - Every team member is responsible for reviewing PRs that they are not assigned to. - Pair as needed to work towards the essential/best solution. Re essential path: pair with teammates on work to understand what good is, understand how the solution is good enough (even if you are not intimately familiar with tech stack/approach). ## What's working? - Ad-hoc collaboration when needed - PR review process achieves results (more participation would improve more) ## What's not working? - A lot of synchronous communication (meetings, pairing) more than necessary. - It is not clear what people read based only written evidence (GitHub, Gitter). - Ambiguity in the GitHub issues on what actually needs to be done (we need to take planning and issue grooming/refinement very seriously). - It's unclear what people are working or why they work on a particular thing (the impact or priority of developer(s) is unclear to the larger group). - We rarely pair/cross-train.