Development Aspirations

Goals and Aspirations

As a team, our aim is to consistently uphold the following principles in our development process. While it might not always be possible to achieve these goals with every pull request, our standard should be to meet these criteria. In the rare instances where we decide not to fulfill any of the items below, it will be a collective team decision.

Maintaining Consistent Development Patterns Throughout the Code

1. Code should maintain a uniform design pattern, creating a seamless reading experience as if it were authored by a single developer.

2. Prior to implementing a different design pattern, it's important to engage in a discussion with the team and Product Owner (PO), as it might lead to a broader refactoring effort.

3. Any user experience functionality introduced in one area should be presumed and replicated in other sections with similar UI functionality.

   Example: For instance, when prompting for passwords in situations where password input is required, the same prompt should be applied, unless omitted when using the command prompt.

Code Coverage

1. We must consistently uphold or elevate our unit testing coverage level.
2. Swift attention is required when addressing end-to-end testing failures, ensuring a prompt understanding to prevent the emergence of systemic bugs.

Pull Request Scope

1. Each pull request should focus on a single, well-defined change in the codebase. Examples include:
   • Introducing a new feature
   • Rectifying a bug
   • Refactoring a function or library
2. Ideally, a pull request should contain only one commit message. The exception to this rule is when merging from the main branch into the PR branch.
3. When merging, all commits in the pull request should be squashed and the PR itself should be rebased.

Pull Request Reviews

1. Does the commit message adhere to the semantic commit message conventions? Examples include:
   • feat: Introducing a new feature
   • fix: Fixing a bug
   • docs: Documentation changes
   • style: Formatting, addressing missing semicolons, etc. (no code changes)
   • refactor: Refactoring production code
   • test: Adding or refactoring tests (no production code changes)
   • chore: Updating build tasks, package manager configurations, etc. (no production code changes)
2. Are there multiple commit messages? If so, only merges from the main branch are acceptable.
3. Are all checks passing?
4. The commit message should concisely describe the specific functionality and also include links to the associated issues it resolves:
   • Closes #azureboardID
   • Closes #githubID
5. Comprehend the functionality and evaluate code changes for potential improvements.
6. Thoroughly test the functionality to ensure it does not disrupt any existing features.