Update labels and development process (#381)

* - Removed BUPA and NHS labels
- Removed Ready for review and WIP labels
- Removed Feature at risk label
- Updated description of Hotfix

* Update IOSP board link in Support Engineer doc

* - Update dev process document
  - Added JIRA link
  - Added explanation about draft/published PRs

* Fixed divider in readme

* Fixed another divider in readme

Cookbook/README.md

@@ -50,7 +50,7 @@
   - UI Automation tests
      - [UI Automation with XCTest & Gherkin](./Technical-Documents/UIAutomation.md)  
      - [Automation Identifiers](./Technical-Documents/AutomationIdentifiers.md)
-  - [Debugging Push Notifications](./Technical-Documents/DebuggingPushNotifications.md) 
+  - [Debugging Push Notifications](./Technical-Documents/DebuggingPushNotifications.md)
 
 ## SDKs 🌱
   - Documenting SDKs
@@ -126,7 +126,8 @@
 | [Stevenson](https://github.com/babylonhealth/Stevenson)                     | Ilya, Olivier                     |    [![GitHub stars](https://img.shields.io/github/stars/babylonhealth/Stevenson.svg?style=social&label=Star&maxAge=2592000)](https://github.com/babylonhealth/Stevenson/stargazers/) |
 | Style guide                   | Diego                    |    WIP       |
 
---
+---
+
 This is a live document. We are constantly writing documentation for the items that are missing one and we also do periodic reviews and updates to other documents that might be out-dated.
 
 Please come back from time to time to check the new stuff!

Cookbook/Technical-Documents/Development-Process.md

@@ -6,7 +6,7 @@ Alongside this framework, we also use a few services to help us keep track of wh
 
 There are 3 services we use daily:
 
-- Jira: is where the development process begins. Once a ticket has all the necessary details, dev can pick it up and implement it <!-- TODO: [CNSMR-3230] link to Jira article -->
+- [Jira:](JIRA.md) is where the development process begins. Once a ticket has all the necessary details, dev can pick it up and implement it
 - GitHub: used for hosting our project and version control using Git
 - CircleCI: our continuous integration service to run tests when integrating PRs <!-- TODO: [CNSMR-xxxx] link to CircleCI article -->
 
@@ -34,7 +34,8 @@ There are 3 services we use daily:
 ## 4. Creating the PR 📝
 
 - Fill in the PR template and set the title using the following format: `[TCKT-123] Short summary of work`
-- [Add labels](https://github.com/babylonhealth/ios-playbook/blob/master/Cookbook/Technical-Documents/LabelsInPRs.md)
+- [Add labels](https://github.com/babylonhealth/ios-playbook/blob/master/Cookbook/Technical-Documents/LabelsInPRs.md) if necessary
+    - To open a work in progress PR, use [GitHub's draft PR feature](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests) and pusblish it once it's ready for review. Reviewers will only be requested for published PRs.
 - Thanks to a GitHub action, the PR will automatically be assigned to its creator
 - Move the ticket to `Peer review` on Jira (or it'll be automatically moved if configured)
 - If you'd like feedback before the work on the ticket is done, open a draft PR so your peers can leave comments
@@ -48,6 +49,7 @@ There are 3 services we use daily:
 - If the required checks are passing, the PR is merged and the branch deleted.
 - The ticket is moved to `Awaiting build` on Jira by our [bot](https://github.com/babylonhealth/Stevenson). It will be updated to `Ready for QA` when the next App Center build is created. (if configured, otherwise this should be done manually)
 - If the checks fail, you will have to analyse what is the reason for the failure, fix it, and add the `Merge` label again
+
 ## 6. QA 🧑‍💻
 
 - Once the work is in the App Center builds, QA can test it to make sure everything works correctly

Cookbook/Technical-Documents/LabelsInPRs.md

@@ -26,12 +26,10 @@ A project horizontal corresponds to an area of the project that has an horizonta
 - ![Platform 🔩](https://img.shields.io/static/v1?label&message=Platform%20🔩&color=002360) - work in the iOS Platform, e.g. architecture, infrastructure, tooling, ...
 
 ### Branding
-We have several projects which contain a subset of functionalities from the main babylon app. These apps also have different flavours in terms of UI. 
+We have several projects which contain a subset of functionalities from the main babylon app. These apps also have different flavours in terms of UI.
 
 The labels to define work that is done in each different project are:
 
-- ![BUPA 🤕](https://img.shields.io/static/v1?label&message=BUPA%20🤕&color=1d76db) - work in the BUPA app
-- ![NHS 👩‍⚕️](https://img.shields.io/static/v1?label&message=NHS%20👩‍⚕️&color=0052cc) - work in the GP and hand app
 - ![Telus 🇨🇦](https://img.shields.io/static/v1?label&message=Telus%20&color=9746e2)🇨🇦 - work in the Telus app
 - ![US 🇺🇸](https://img.shields.io/static/v1?label&message=US%20&color=2f2799) 🇺🇸 - work in the US app
 
@@ -40,8 +38,6 @@ Informs in which stage of development the PR is. These labels are used to know w
 
 - ![Merge](https://img.shields.io/static/v1?label&message=Merge&color=FF7F50) - The PR is ready to be merged. Our bot picks up when this label is added. It will then automatically add the PR in the queue to merge the PRs in order. Once dequeued, it will first merge back develop into the PR, then wait for our CI system to run all the tests. Only if every test has passed the bot will finally merge the PR.
 - ![Needs one reviewer 🙏](https://img.shields.io/static/v1?label&message=Needs%20one%20reviewer🙏%20&color=ce3799) - The PR has one approval and is waiting for one more review.
-- ![Ready for Review 🚀](https://img.shields.io/static/v1?label&message=Ready%20for%20Review🚀&color=0e8a16) - The work on the PR is finished and it is ready to be reviewed.
-- ![Work in progress 🚧](https://img.shields.io/static/v1?label&message=Work%20in%20progress%20🚧&color=fbca04) - The work on the PR is not finished and is not ready to be reviewed.
 
 ### Status
 Flags if there is something preventing the PR from being merged that is unrelated with review requests or failing builds.
@@ -52,8 +48,7 @@ Flags if there is something preventing the PR from being merged that is unrelate
 ### Emergency
 Alerts when a PR is required to be merged. This is used in emergency situations like a hot fix or a piece of work that is mandatory to go in the release that is about to ship.
 
-- ![Feature at risk 🚑](https://img.shields.io/static/v1?label&message=Feature%20at%20risk%20🚑&color=e00000) - A PR that has to go in the next release that will ship in 2 days or less. This PR has priority to be reviewed over all the other PRs that are not in emergency.
-- ![Hotfix 🆘](https://img.shields.io/static/v1?label&message=Hotfix%20🆘&color=fcc1ba) - The PR has priority to be reviewed because it has an urgent fix targeting the PR's base branch, which could be develop or the current release branch.
+- ![Hotfix 🆘](https://img.shields.io/static/v1?label&message=Hotfix%20🆘&color=fcc1ba) - The PR has priority to be reviewed because it has an urgent change for the current or next release.
 
 ### Extra
 These tags are used to give extra context to the PR.
@@ -75,7 +70,7 @@ Multiple labels from these groups can be added to a PR because a piece of work c
 
 ### [**Stage**](#stage)
 
-In this group a mixed of rules are applied. 
+In this group a mixed of rules are applied.
 A PR can:
 
 - be either [ready for review](#ready_review) or still [in progress](#in_progress). These are mutually exclusive. It means the labels representing both these stages can't be present in the same instant.
@@ -98,5 +93,3 @@ A PR can only have one emergency label.
 ### [**Extra**](#extra)
 
 A PR can have one or more extra labels at the same time.
-
-

Cookbook/Technical-Documents/SupportEngineerRole.md

@@ -10,9 +10,9 @@ When an engineer is on support, these duties have higher priority over Squad dut
 * **Update #ios and #ios-usa-support Slack channels topics** The topics should be updated with the iOS Engineers in support for the current day. This update should be done first thing in the morning.
 * **Be available to answer any requests posted in the #ios and #ios-usa-support.** The engineer can either solve the request or delegate to someone who might know how to solve it.
 * **Pick up tickets from the iOS Platform backlog.** These are tickets that don't have any Squad as an owner and still need to be fixed, or ones for which the Platform team might need some help with.
-   * Use this [Kanban board](https://babylonpartners.atlassian.net/secure/RapidBoard.jspa?rapidView=1100&projectKey=IOSP) to see the list of pending BAU tickets.
+   * Use this [Kanban board](https://babylonpartners.atlassian.net/secure/RapidBoard.jspa?rapidView=1509) to see the list of pending BAU tickets.
    * But first, ping the platform team directly on Slack to check with them if there is any urgent/blocker ticket that could use some help and would take priority.
-   * Discussion of tickets and progress should be posted in #ios-support-info. This channel is used to share knowledge about a tasks progress and potential issues. 
+   * Discussion of tickets and progress should be posted in #ios-support-info. This channel is used to share knowledge about a tasks progress and potential issues.
 * **Work on personal goals.** Personal goals should be tasks that will help you improve competences in your preferred areas. They are also important tasks that are used, in addition to other metrics, to evaluate your performance. You should only work on these if there is no other task to be picked up from the points defined above and there is no critical work to be done as part of your Squad.
 * **Support handover to next support engineer.** Details / progress on outstanding tasks should be posted on the ticket / in the #ios-support-info channel for the next support engineer to finish off. This prevents us from having multiple half-finished tasks sitting in the backlog without an indication of progress made.
 
@@ -32,4 +32,3 @@ The days an engineer is on support are defined as following:
 The schedule is defined in the iOS Team Plan document and calendar events are also added to the iOS Developers Outlook calendar.
 
 Please let your squad know with a week's notice if you are being assigned to Support
-

README.md

@@ -8,7 +8,7 @@ iOS Playbook 📚
 
 At Babylon, we firmly believe that **transparency** is a core value that should be present in everything we do. In this playbook you can learn about [who we are](#who-are-we) and [our ways of working](/Cookbook/README.md).
 
-## Who are we? 
+## Who are we?
 
 We're organised in Squads. Each squad can be composed of people from Engineering (iOS, Android, Web, Backend), Design and Product.
 
@@ -96,8 +96,6 @@ The rest of the iOS Engineers work in the following squads:
 - On our [Cookbook](/Cookbook/README.md) 🥘
 - Check our [open positions](https://www.babylonhealth.com/careers-hub/vacancies) 👀
 
+---
 
---
 The [Babylon health iOS team](http://github.com/babylonhealth)
-
-