# Project Management ## GitHub Code for Life is managed using [GitHub Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues) and [GitHub Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects). ### [Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues) An issue is a task (most common) or epic that is assigned to a repo ([see issue types](#issue-relationships-and-types)). {% hint style="info" %} All of Code for Life's repos are prefixed with "codeforlife-" ([see](https://github.com/orgs/ocadotechnology/repositories?q=codeforlife-)), except for [rapid-router](https://github.com/ocadotechnology/rapid-router). {% endhint %} ### [Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) Simply put, a GitHub project allows you to collect issues from one or more repos, visualize them in a [variety of views](#project-views), and create your own [custom workflows](#automated-workflows). From GitHub's docs: > A project is an adaptable table, board, and roadmap that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively at the user or organization level. You can create and customize multiple views by filtering, sorting, slicing, and grouping your issues and pull requests to manage your team backlogs and roadmaps, visualize work with configurable charts, add custom fields to track metadata specific to your team, create templates, share status updates, and automate your projects. ## Custom Project Fields GitHub Projects supports creating [custom fields](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields) to track different values per issue. Below are the custom fields we define.

How the CFL project-card appears on an issue

### Status \[[single select](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-single-select-fields)] The current status of a [task](#tasks) in our [Definition of Done](#definition-of-done). **Options:** 1. [**To Do**](#id-2.-to-do) - To be completed but haven't started yet. 2. [**In Progress**](#id-3.-in-progress) - Actively being worked on (unless blocked). 3. [**Ready For Review**](#id-4.-ready-for-review) - Ready to be reviewed but haven't started yet. 4. [**In Review**](#id-5.-in-review) - Actively being reviewed. 5. [**Staging**](#id-6.-staging) - Has been deployed to staging and needs testing. 6. [**Production**](#id-7.-production) - Has been deployed to production and needs testing. 7. [**Closed**](#id-8.-closed) - Has been completed. ### Size \[[single select](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-single-select-fields)] Approximately how many [man-hours](https://en.wikipedia.org/wiki/Man-hour) is needed to close a [task](#tasks). {% hint style="danger" %} [Epics](#epics) should NOT be sized; their size may be inferred by summing the sizes of their sub-issues. {% endhint %} **Options:** 1. **XS** - Extra small (approx. 2hrs / ΒΌ working day). 2. **S** - Small (approx. 4hrs / Β½ working day). 3. **M** - Medium (approx. 8hrs / 1 working day). 4. **L** - Large (approx. 16hrs / 2 working days). 5. **XL** - Extra large (approx. 24hrs / 3 working days). {% hint style="warning" %} If a [task](#tasks) is larger than an **XL**, it should be broken down into an [epic](#epics) with smaller tasks. Avoid "mega" tasks. {% endhint %} ### Sprint \[[iteration](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-iteration-fields)] The [sprint](https://www.atlassian.com/agile/scrum/sprints) the [task](#tasks) is scheduled to be worked on. Our sprints are 2-week intervals. {% hint style="danger" %} [Epics](#epics) should NOT be assigned to a sprint. {% endhint %} ### Est. start \[[date](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-date-fields)] The estimated start-date of an [epic](#epics). Used in our [Epic Roadmap](#epic-roadmap). {% hint style="success" %} ONLY [epics'](#epics) timelines should be estimated when [roadmapping](#epic-roadmap). {% endhint %} ### Est. end \[[date](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-date-fields)] The estimated end-date of an [epic](#epics). Used in our [Epic Roadmap](#epic-roadmap). {% hint style="success" %} ONLY [epics'](#epics) timelines should be estimated when [roadmapping](#epic-roadmap). {% endhint %} ### Category \[[single select](https://docs.github.com/en/issues/planning-and-tracking-with-projects/understanding-fields/about-single-select-fields)] The type of work involved in a [task](#tasks). {% hint style="danger" %} [Epics](#epics) should NOT be categorized; sub-issues may span multiple categories. {% endhint %} **Options:** 1. :computer: ( a.k.a. **:computer:** ) - Software development. 2. :art: ( a.k.a. **:art:** ) - Design. 3. :mag: ( a.k.a. **:mag:** ) - Research. 4. :books: ( a.k.a. **:books:** ) - Educational resources. 5. :gear: ( a.k.a. **:gear:** ) - Operations.
Examples of tasks per category :computer: develop a new feature. :computer: squash a bug. :computer: deploy a service. :computer: fix a security vulnerability. :art: design a user interface component. :art: design a page layout. :art: design some imagery/iconography/branding. :art: design some marketing/event materials. :mag: conduct market/competitor research. :mag: consolidate feedback provided in user-support tickets. :mag: actively seek feedback on existing functionality. :mag: investigate which feature to develop next. :books: write a lesson plan. :books: plan a game level. :books: write a brain teaser. :books: write a coding-club pack. :gear: consult with a legal professional about a concern. :gear: make a payment/budget. :gear: create & schedule a marketing campaign. :gear: organize an event.
## Definition of Done Our [Definition of Done](https://www.atlassian.com/agile/project-management/definition-of-done) is defined using our custom [Status](#status) field. The order of the statuses matter as each subsequent status is one step closer to a [task](#tasks) being "[closed](#id-8.-closed)". As seen on our [Task Board](#task-board), the leftmost/first ([No Status](#id-1.-no-status)) column is where you find newly created tasks and the rightmost column is where you find [Closed](#id-8.-closed) tasks; the general idea is to move the tasks from the left side of the board to the right.

The status columns in order (from left to right)

Here's a high-level overview of how tasks move throughout the columns (not all possible paths). {% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"]" %} Below are the statuses in order, each with: * a description of the conditions under which a [task](#tasks) qualifies for the status; * general do's & do-not's for [tasks](#tasks) in this status; * a list of acceptable previous/next status changes. ### 1. No Status Technically this is the absence of a status and not an actual status. Newly created [tasks](#tasks) go here. When a [task](#tasks) is first created, it should NOT be allocated a status.

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] NS --> IP NS --> C style NS stroke:#E0004D,stroke-width:4px linkStyle 0,9,10 stroke:#E0004D,stroke-width:4px" %} * :arrow\_right: [**To Do**](#id-2.-to-do) - if a [task](#tasks) is assigned to the current sprint or a previous sprint. * :arrow\_right: [**In Progress**](#id-3.-in-progress) - if a [task](#tasks) is actively being worked on, regardless of sprint. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 2. To Do [Tasks](#tasks) that have [been prioritized for this sprint](#sprint-planner) and are aimed to be completed by end-of-sprint. [Tasks](#tasks) not started from previous sprints will remain in this column.

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] TD --> NS TD --> C style TD stroke:#E0004D,stroke-width:4px linkStyle 1,9,10 stroke:#E0004D,stroke-width:4px" %} * [**No Status**](#id-1.-no-status) :arrow\_left: - if a [task](#tasks) is unassigned from the current sprint or assigned to a future sprint. * :arrow\_right: [**In Progress**](#id-3.-in-progress) - if a [task](#tasks) is actively being worked on, regardless of sprint. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 3. In Progress [Tasks](#tasks) actively being worked on, regardless if they're assigned to a sprint or not. If a [task](#tasks) is blocked, by which we mean it cannot be progressed by the assignee(s), it should be labelled with (search "blocked" in labels to find these): * ":octagonal\_sign:" if the [task](#tasks) can be unblocked by someone *inside of Ocado;* * ":earth\_africa::octagonal\_sign:" if the [task](#tasks) can ONLY be unblocked by someone *outside of Ocado*.

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] IP --> NS IP --> TD IP --> C style IP stroke:#E0004D,stroke-width:4px linkStyle 2,9,10,11 stroke:#E0004D,stroke-width:4px" %} * [**No Status**](#id-1.-no-status) :arrow\_left: - if a [task](#tasks) is no longer being worked on and was unassigned from the current sprint or assigned to a future sprint. * [**To Do**](#id-2.-to-do) :arrow\_left: - if a [task](#tasks) is no longer being worked on and is assigned to the current sprint. * :arrow\_right: [**Ready For Review**](#id-4.-ready-for-review) - if a [task's](#tasks) assignee(s) believe they have delivered the requirements. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 4. Ready For Review [Tasks](#tasks) that are ready to be reviewed but haven't started being reviewed yet.

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] RFR --> IP RFR --> C style RFR stroke:#E0004D,stroke-width:4px linkStyle 3,9,10 stroke:#E0004D,stroke-width:4px" %} * [**In Progress**](#id-3.-in-progress) :arrow\_left: - if a [task's](#tasks) assignee(s) realize that changes are required to the deliverables. * :arrow\_right: [**In Review**](#id-5.-in-review) - if a reviewer has started reviewing a [task's](#tasks) deliverables. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 5. In Review [Tasks](#tasks) that are actively being reviewed. Assignees should NOT review their own [task](#tasks); we do peer reviewing. When a [task](#tasks) is reviewed, the [task's](#tasks) deliverables will either be accepted or the reviewer will request changes. If changes are requested, the [task](#tasks) will go back to [In Progress](#id-3.-in-progress) and the assignee(s) must [request another review](#id-4.-ready-for-review). It's normal for a [task](#tasks) to go through multiple *rounds of review* before its deliverables are accepted. If a reviewer accepts, they should comment "LGTM" (an acronym for "looks good to me"). {% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] subgraph review\_round \["Review Round"] IP RFR IR end" %}

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] style IR stroke:#E0004D,stroke-width:4px linkStyle 4,5,6 stroke:#E0004D,stroke-width:4px" %} * [**In Progress**](#id-3.-in-progress) :arrow\_left: - if a reviewer requests changes on a [task's](#tasks) deliverables. * :arrow\_right: [**Staging**](#id-6.-staging) - if a [dev-task](#category) (:computer:) was accepted and has been deployed to our staging environment. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 6. Staging [Dev-tasks](#category) (:computer:) that have been deployed to our [staging environment](https://staging-dot-decent-digit-629.appspot.com/) and require manual testing. A clear description of how to manually test a [task's](#tasks) deliverables should be provided by the assignee(s) in a comment. At least 2 different testers (not including the assignees) should test the [task's](#tasks) deliverables. If a tester approves, they should comment "LGTM" (an acronym for "looks good to me").

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] S --> IP S --> C style S stroke:#E0004D,stroke-width:4px linkStyle 7,9,10 stroke:#E0004D,stroke-width:4px" %} * [**In Progress**](#id-3.-in-progress) :arrow\_left: - if a bug or missing requirement managed to slip through the reviews. * :arrow\_right: [**Production**](#id-7.-production) - if a [dev-task](#category) (:computer:) was accepted in our staging environment. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 7. Production [Dev-tasks](#category) (:computer:) that have been deployed to our [production environment](https://www.codeforlife.education/) and require manual testing. A clear description of how to manually test a [task's](#tasks) deliverables should be provided by the assignee(s) in a comment. At least 2 different testers (not including the assignees) should test the [task's](#tasks) deliverables. If a tester approves, they should comment "LGTM" (an acronym for "looks good to me").

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] P --> IP style P stroke:#E0004D,stroke-width:4px linkStyle 8,9 stroke:#E0004D,stroke-width:4px" %} * [**In Progress**](#id-3.-in-progress) :arrow\_left: - if a bug or missing requirement managed to slip through the reviews. * :arrow\_right: [**Closed**](#id-8.-closed) - if a [task](#tasks) is closed, no longer relevant or a duplicate of another [task](#tasks). ### 8. Closed [Tasks](#tasks) that have been completed.

Acceptable status changes:

{% @mermaid/diagram content="graph LR NS\["No Status"] --> TD\["To Do"] TD --> IP\["In Progress"] IP --> RFR\["Ready For Review"] RFR --> IR\["In Review"] IR --> IP IR --> C IR --πŸ’»--> S\["Staging"] S --> P\["Production"] P --> C\["Closed"] C --> NS C --> TD C --> IP style C stroke:#E0004D,stroke-width:4px linkStyle 9,10,11 stroke:#E0004D,stroke-width:4px" %} * [**No Status**](#id-1.-no-status) :arrow\_left: - if a [task's](#tasks) requirements weren't delivered and aren't scheduled in the current sprint. * [**To Do**](#id-2.-to-do) :arrow\_left: - if a [task's](#tasks) requirements weren't delivered and are scheduled in the current sprint. * [**In Progress**](#id-3.-in-progress) :arrow\_left: - if a [task's](#tasks) requirements weren't delivered and are actively being worked on. ## Issue Relationships & Types As documented by GitHub, you can [add sub-issues to an issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues) which creates a child & parent relationship between issues. Depending on these relationships, we define different types of issues. {% hint style="info" %} The terms "sub-issue" and "child-issue" are interchangeable. {% endhint %} Below is an example relationship-graph between various issues. **Legend:** * **--**:octagonal\_sign:**-- >** = blocking relationship ("this issue is blocking that issue"). * **β€”**:baby:**β€” >** = child relationship ("this issue has that issue as a child"). {% @mermaid/diagram content="graph TD A --πŸ‘Ά--> B B --πŸ‘Ά--> C B --πŸ‘Ά--> D B --πŸ‘Ά--> E C -.πŸ›‘.-> D D -.πŸ›‘.-> E A --πŸ‘Ά--> F G --πŸ‘Ά--> H G --πŸ‘Ά--> I J K subgraph epics \["Epics"] B subgraph root\_epics \["Top Epics"] A G end end subgraph tasks \["Tasks"] C D E F H I subgraph orphan\_tasks \["Orphan Tasks"] J K end end" fullWidth="false" %} ### Epics **(In graph: A, B, G)** Issues that... * ...do have a sub-issue. Epics are not tasks to be completed in themselves. Rather, epics represent *initiatives* that comprise multiple tasks. Epics are closed by closing all the sub-issues within them. #### Top \[Level] Epics **(In graph: A, G)** Issues that... * ...do have a sub-issue... * ...and do NOT have a parent-issue. Top-level epics contain sub-epics and/or [tasks](#tasks). These are useful for breaking down larger initiatives into smaller ones, each with their own [tasks](#tasks). ### Tasks **(In graph: C, D, E, F, H, I, J, K)** Issues that... * ...do NOT have a sub-issue. Tasks are the actual work that needs to be completed. #### Orphan Tasks **(In graph: J, K)** Issues that... * ...do NOT have a sub-issue... * ...and do NOT have a parent-issue. Orphan tasks are one-off tasks that are NOT part of an [epic](#epics). {% hint style="warning" %} Ideally, we should have few of these; we want tasks to work towards initiatives set out in our [roadmap](#epic-roadmap). {% endhint %} #### [Blocking Tasks](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-issue-dependencies#marking-an-issue-as-blocked-by-or-blocking-another-issue) **(In graph: C, D)** Issues that... * ...do NOT have a sub-issue... * ...and are blocking another issue. Blocking tasks define a sequence in which tasks must be [closed](#id-8.-closed) ("this task must be done before that task"). #### [Blocked Tasks](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-issue-dependencies#marking-an-issue-as-blocked-by-or-blocking-another-issue) **(In graph: D, E)** Issues that... * ...do NOT have a sub-issue... * ...and are being blocked by another issue. Blocked tasks define a sequence in which tasks must be [closed](#id-8.-closed) ("this task must be done after that task"). ## Project Views In GitHub, a project-view is a way to visualize the issues in a project. A project can have 1 or more views, where each view has its own visualization-customizations and [preset filters](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/filtering-projects). Fundamentally, GitHub supports 3 different view types: 1. [**Table**](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/changing-the-layout-of-a-view#about-the-table-layout) - a spreadsheet comprised of issues. 2. [**Board**](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/changing-the-layout-of-a-view#about-the-board-layout) - spreads issues across customizable columns. 3. [**Roadmap**](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/changing-the-layout-of-a-view#about-the-roadmap-layout) - a high-level visualization of issues across a configurable timespan. ### Common Filters There are a few filters common across our views. It's highly recommended you memorize them. 1. `is:open` - An issue that has not [been closed](https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/closing-an-issue). 2. `has:sub-issues-progress` - An issue that [has sub-issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/browsing-sub-issues#navigating-issue-hierarchy) (a.k.a. child-issues). 3. `has:parent-issue` - An issue that is a sub-issue (and therefore [has a parent](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/browsing-sub-issues#finding-a-sub-issues-parent-issue)). ### Our Custom Views Below are our custom project-views, each with: * a short description of the insight it gives us into our project; * the preset filters (and what they do).

You can tab between views

#### [Task Board](https://github.com/orgs/ocadotechnology/projects/3/views/8) All [tasks](#tasks), grouped by [Status](#status). This helps us to explore all the [tasks](#tasks) in our project (also see [Open Task Table](#open-task-table)). **Preset filters ("Filter to issues that..."):** 1. `-has:sub-issues-progress` - ...do NOT have sub-issues. #### [Sprint Board](https://github.com/orgs/ocadotechnology/projects/3/views/15) All open [tasks](#tasks) assigned to the current or a previous [Sprint](#sprint), grouped by [Status](#status) and by [Assignee](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/assigning-issues-and-pull-requests-to-other-github-users). This helps to see how many open [tasks](#tasks) are remaining in the current sprint, including [tasks](#tasks) carried over from previous sprints. **Preset filters ("Filter to issues that..."):** 1. `-has:sub-issues-progress` - ...do NOT have sub-issues... 2. `sprint:<=@current` - ...and are in the current or previous sprints... 3. `has:status` - ...and have a status (aren't in the [No Status](#no-status) column)... 4. `-status:Closed` - ...and are NOT in the [Closed](#closed) column (this hides the column). #### [Open Task Table](https://github.com/orgs/ocadotechnology/projects/3/views/14) All open [tasks](#tasks). Similar to our [Task Board](#task-board), this helps us to explore all the open [tasks](#tasks) in our project but see them in a dense spreadsheet format that supports bulk-editing field values by multi-selecting cells. **Preset filters ("Filter to issues that..."):** 1. `-has:sub-issues-progress` - ...do NOT have sub-issues... 2. `is:open` - ...and are open. #### [Epic Roadmap](https://github.com/orgs/ocadotechnology/projects/3/views/1) All open [top-level epics](#top-level-epics). This helps us to estimate the timelines ([start](#est.-start) & [end](#est.-end)) of each [top-level epic](#top-level-epics) so that we can roughly plan the year ahead. Generally, the next quarter (3 months) should be understood to be well planned, with each proceeding quarter having rougher estimations. > The only thing that is constant is change β€” **Heraclitus** **Preset filters ("Filter to issues that..."):** 1. `has:sub-issues-progress` - ...have sub-issues... 2. `-has:parent-issue` - ...and do NOT have a parent-issue... 3. `is:open` - ...and are open. ## Roles & Responsibilities Below are the roles we define when managing our project, each with their own responsibilities and assignee(s). ### \[Sprint] Planner 🧭 Prioritizes [tasks](#tasks) by assigning them to the current or upcoming sprints. **Responsibilities:** 1. (Un)assigns [tasks](#tasks) to a sprint. 2. Chases CFL team members to curate [tasks](#tasks) which are assigned to next sprint. 3. Consults CFL team members for potential [blocking tasks](#blocking-tasks). **Assignees:** CFL's team lead, [Sidi Jow](https://github.com/sjforever). ### \[House] Keeper :broom: Curates [tasks](#tasks) to maintain a clean project with well defined requirements. **Responsibilities:** 1. Writes a full description. 2. Writes the required deliverables. 3. Sets the correct labels. 4. Sets the correct [Size](#size). 5. Sets the correct [Category](#category). 6. Sets the correct [relationships](#issue-relationships-and-types). 7. Checks with other CFL team members if there are any doubts on any details. 8. Closes tasks that are no longer relevant. **Assignees:** [Everyone in CFL](https://github.com/orgs/ocadotechnology/teams/cfl?query=membership%3Achild-team). ### \[Trouble] Maker :bomb: Creates new [tasks](#tasks) to track work that needs to be done at some point. **Responsibilities:** 1. Searches existing [tasks](#tasks) to ensure no duplicate [tasks](#tasks) already exist. 2. Creates new [tasks](#tasks) with full descriptions and correct [field values](#custom-project-fields). **Assignees:** [Everyone in CFL](https://github.com/orgs/ocadotechnology/teams/cfl?query=membership%3Achild-team). ### \[Project] Contributor :muscle: Is assigned to [tasks](#tasks), delivers their requirements, and follows our [Definition of Done](#definition-of-done) \[to close [tasks](#tasks)]. **Responsibilities:** 1. Updates the [Status](#status) to reflect the current situation. 2. Regularly comments significant progress-updates. 3. Comments any discoveries which are perceived to be 'blockers'. 4. Comments any discoveries which are believed to change the required deliverables. 5. Attaches or links to the required deliverables in a comment. 6. Addresses all feedback (through multiple [review rounds](#id-5.-in-review) if necessary) until the reviewer accepts. 7. Avoids sharing [PII](https://www.ibm.com/think/topics/pii) of others and security vulnerabilities, which others could use to exploit. 8. Is kind, collaborative and patient with everyone. **Assignees:** Anyone. Become a Contributor ## Automated Workflows To keep our project 'clean' we've created [@cfl-bot](https://github.com/cfl-bot) whose job it is to monitor to all issues and: * nudge user(s) or team(s) to create clean issues by commenting on them with change requests; * perform actions on others' behalf when [prompted](#prompts); * enforce rules (unless [ignored](#bot-ignore-labels)). ### Prompts [Contributors](#project-contributor) can instruct [@cfl-bot](https://github.com/cfl-bot) to perform actions on their behalf by commenting one of the following prompts: {% hint style="info" %} Usually [contributors](#project-contributor) will NOT have the permissions to perform these actions themselves. {% endhint %} #### "assign me" **Description:** Assigns you to an issue. **Use When:** You want to work on an issue. #### "unassign me" **Description:** Unassigns you from an issue. **Use When:** You no longer want to work on an issue. #### "ready for review" **Description:** Sets the status of an issue to [Ready For Review](#id-4.-ready-for-review). **Use When:** You've attached deliverables to an issue and you would like a CFL team member to review it. #### "requires changes" **Description:** Sets the status of an issue to [In Progress](#id-3.-in-progress). **Use When:** You've realized that your deliverables are missing something. #### "link pr \ \" **Description:** Links a pull request to an issue. **Arguments:** 1. **\** The number of the PR to link. 2. **\** The repo the PR is in.[\*](#prompt-notes) Defaults to the issue's repo. **Use When:** You want to associate your code changes with an issue. **Examples:** 1. `link pr 1` 2. `link pr 1 codeforlife-portal` 3. `link pr 1 portal` #### "unlink pr \ \" **Description:** Unlinks a pull request from an issue. **Arguments:** 1. **\** The number of the PR to unlink. 2. **\** The repo the PR is in.[\*](#prompt-notes) Defaults to the issue's repo. **Use When:** You want to disassociate your code changes with an issue. **Examples:** 1. `unlink pr 1` 2. `unlink pr 1 codeforlife-portal` 3. `unlink pr 1 portal` #### Prompt Notes \*Only [CFL repos](https://github.com/orgs/ocadotechnology/repositories?q=codeforlife-) may be specified. You can optionally omit the "codeforlife-" prefix. ### Bot-Ignore Labels If a CFL team member wants an issue to be ignored by the bot, they can add the bot-ignore label. * ":robot:" ( a.k.a. **:robot:** ) - ignores all rules. {% hint style="warning" %} Bot-ignore labels should be used sparingly! We should not lightly abandon the rules that help us keep order. {% endhint %}