# 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.