---
# System prepended metadata

title: Untitled

---

## Discuss points


### Size of the PR: When is a good time to break it into a separate PR?
* Divide PR by size 
    * large PRs are accectable. but they need a clear goal 
* Divide PR by goal (ticket)


### How to get better understanding on the review criteria:
Review PRs (both the code changes AND others’ comments)



* Tips on more smooth review process
    * Self-review before submitting for review




### Format
* PR title:
    * Should follow the format: `[JIRA-TICKET] Commit message`

* Title
    * The title is important as it becomes the commit message for the squashed commits going into master

* Description:
    * remove unnecessary texts from the PR template
(Personally I do not like the template headers - it adds extra text that I don't need to read and usually results in short (sometimes repeated) descriptions.
I prefer an explanation of the code that is about to be merged and calling out any parts that may not be obvious when reviewing the code. 
Include links to related PRs and give a short description of what will be coming next in relation to this PR

* Labels:
    * Add `waiting-review`, assign yourself

### Commits:
* A really good PR should have atomic commits with meaningful commit messages so that the reviewer can go commit by commit. This may require interactive rebasing.
* Commit message:
    * Specific as possible (even trivia code changes, clearly explains what this commit was doing 

### Code content: 
* Avoid empty implementations and unused properties and parameters
* Avoid unnecessary imports
* Try to follow the code formatting styles in the code base
* Create classes / structs with the minimum required properties (red flag: var something = class.model.property)
* Break up types (especially views) into smaller type. (red flag: let isSomeVarient: Bool)
* Reuse code as much as possible. If you need to move files or make things public, think about doing it
* Naming is hard

### Reviewing:
* Ask questions (answer reviewers questions)
* The PR is your responsibility to get merged - if it is not reviewed don't be afraid to push for a review
* Don't leave PRs in review for weeks
* Ask for pairing if you need to
* Using the `request changes` option is a good thing



### One more thing:
**REVIEW YOUR OWN PR!**




