---
# System prepended metadata

title: Core Team Working Agreement

---

# Core Team Working Agreement

## Git
- Anyone can merge work except your own work
- Create a changelog file that PR data is added to
- Squashing would be more efficient for our usage
    - Develop: atomic commits
    - Master: Squash merge w/ changelog

## Coding Standards
- `public` functionality must have documentation
    - Implement swiftlint rule (?)
- Implement Jazzy or similar functioning doc system
- Social Pull Request - A process for proposing an idea where the group looks for faults/problems with the idea and votes to bring it into the process, turns it down outright or requests iteration

### Coding Philosophies
- Discoverability: Developers should be able to quickly find and understand public API's
    - An API can be glanced at and know what it does
    - An intern can pick it up w/ little to no experience
- Ergonomics: API's should be as easy to work with as possible
- Scalability:
    - Flexibility through extensibility
        - Assume growth of a system: Build flexibility into API's for future growth
        - Assume abuse of a system: Assume the worst case for the usage and future of APIs and build guard rails to keep them in line with their original intention
        - Examples
            - Use `final` classes to signal that something is not to change
            - Code coverage should signal the intention of how code is meant to work

## Testing/QA
- Mocked network layer
- Identify pertitnent tests for each framework
- Stress Testing
    - Fuzz Testing
    - Snapshot
        - https://github.com/pointfreeco/swift-snapshot-testing
    - Pseudo language UI testing
- We have no Moe
- Ideas
    - Have others implement new code into sample app code, it would catch ergonomics and missing/poor documentation
    - Playgrounds & Pods
        - https://github.com/JohnSundell/TestDrive
        - https://github.com/asmallteapot/cocoapods-playgrounds
        - https://learnappmaking.com/cocoapods-playground-how-to/
- Performance Testing
    - Algorithmically based code should be performance tested (loops, recursion)
- Crashes
    - Use built-in Xcode crash reporting

## Needs Implementation
- Onboarding workflow

## Rollback Process
- Ad-Hoc: Just tell framework consumers to rollback and fix in the next release
- Re-Release: Re-release previous version as a version bump
- Process
    - Communicate internally about changes
    - Communicate w/ clients about the change and how to process the rollback w/ the individual apps 

## Workflow
- Core member's are responsible for note taking in meetings that the entire team is not involved
- AC should be explicit to the point that all core members can understand what the expectations are
- AC
    - Visually related AC is frozen
    - Technical
        - If it is releasable and AC needs to be added, create a new ticket
        - If it is not releasable and AC needs changes communicate w/ the team and update the AC

### Standups
- Rolling Grooming, because of the nature of kanban grooming should occur on a regular basis to make sure tickets are pointed in line with workload
- If there is not kanban board and one can't be created we might need a shadow board

# Questions Needing Answers
- Is kanban or other methodology a better platform for managing tickets and time?
- How would this work w/ our current system of sprints & agile?

# Repos
## Foundation
- Snapshot testing against dynamic type properties

# Random Resources
- https://github.com/vadymmarkov/Fakery
- https://github.com/realm/jazzy
- https://github.com/pointfreeco/swift-snapshot-testing
- https://developer.apple.com/library/archive/documentation/Xcode/Reference/xcode_markup_formatting_ref/index.html

# Tasks
- [ ] Implement jazzy fastlane action for repos
- [ ] Build script for new team members to install everything
- [ ] Components: Implement snapshot testing
- [ ] Talk to Nicole about how to handle PM in relation to standups/grooming/etc.