GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free: gitlabcommitvirtual2021.com

Commit 9f7bec66 authored by Sandeep Kumar Choudhary's avatar Sandeep Kumar Choudhary Committed by Boros Gábor
Browse files

Fixing the URL References in the Handbook

parent f90017da
# Client Briefings
We have many clients, and not all of them are covered in this handbook. If you're
encountering a new client for the first time, you're encouraged to visit [our
CRM](https://opencraft.monday.com/boards/1077823105) and read up on their entry.
Each entry in the CRM has an 'updates field' that you can expand which contains
an initial briefing on that client.
Maintaining these client briefings is a joint effort between the
[Business Development Representative](https://handbook.opencraft.com/en/latest/roles/#business-development-representative)
and the [Client Owner](https://handbook.opencraft.com/en/latest/roles/#client-owner)
for that client.
## Initial Briefing
When a new client signs a contract with us, the Business Development
Representative will post an initial 'Client Briefing' with [this template](client_briefing_template.md), which has been
made into a separate page so its formatting can be copy-pasted. Time for this work should be logged to whatever epic
we start for this client.
## Scope of the Briefings
The briefings should contain information that is useful to all (or nearly all) of their epics, as well as other background and contact information that may be helpful to know. Details relevant only to one epic should be kept in the relevant epic ticket, and that epic ticket should be linked in the briefing. If an epic is completed and not likely to be especially important for understanding the current needs of the client, it can be removed from the listing.
## Briefing Maintenance
Information about clients changes over time-- which projects we have, important links, points of contact-- all of these can change, as well as background knowledge. The purpose of a briefing is to allow a developer to get up to speed quickly on a client's most important information.
To keep things up to date, Client Owners will write an update to the CRM entry for each meeting or signficant interaction they have with the client. Once a sprint, they will consolidate the updates to the most important points and recreate the initial briefing with the most up to date context. Client owners should log time spent maintaining briefings to whatever epic they most commonly use for meetings with this client.
Keeping this client briefing information succinct and informative helps new team members get up to speed quickly. Think carefully about what information from recent discussions will be relevant in the long term, and what can be discarded. See the 'Scope of the Briefings' section above for points to consider.
# Onboarding and offboarding clients
This section describes the processes we use when we welcome new clients and say goodbye to existing ones.
## Creating a work epic
When working with a new lead or client, a Jira epic can be created to:
* Capture information that is essential or useful to developers
* Group tasks together and facilitate coordination when multiple discussions/discoveries are involved
* Find a client owner early in the process
The moment at which we create a work epic for a new lead or client changes from project to project.
If no discovery is required, the epic can be created after contract signature.
If an initial discovery (blueprint) process is required, epic creation can be handled in one of two ways:
* If doing a single and overall straightforward discovery, there is probably no need to create an epic until the contract is signed.
* If the discovery process involves lots of discussions, multiple discovery tasks, and multiple meetings, then we should create and assign an epic during the blueprint/discovery phase.
## Once a client has accepted our estimates
If the proposal resulting from the discovery is accepted, we move its **epic** to the "Accepted" column in Jira, and set a time budget and a timeline based on estimates from the discovery. Discoveries and epics are related through their estimates: tasks in an epic use the estimates and budget of the features the client selected from the quote, which was based on the discovery document. You can validate this with the Business Development Specialist.
## New client onboarding
Here's the workflow we use when a new client accepts our quote:
[![Client Onboarding workflow](https://docs.google.com/drawings/d/e/2PACX-1vQg2vl0awtHZro8gDdkaxtGKZipmlcET7RcitXUsfPsLfi2fCxMr1zhzMtGYJh7sihPPnY1RYFdOVHp/pub?w=1349&h=614)](https://docs.google.com/drawings/d/15RceotA5oqKNr0gQCR924B9OnbY5xy6E7b2xezaIkyc/edit?usp=sharing)
## Offboarding process for departing clients
We use the following steps to complete the offboarding of an existing client:
[![Client Offboarding workflow](https://docs.google.com/drawings/d/e/2PACX-1vSPf0UTwORLh-9uSIvVmfE6K9qs65zLUl3JleVYmQ4cX3REzs_bnmtoX_2gYdxfSMTQOE4gw1v7-3Kl/pub?w=1222&h=518)](https://docs.google.com/drawings/d/1n2MGglI0eK9pN-9k6UPyI5cj110M5k0ojQpZmhSbWqQ/edit?usp=sharing)
During the offboarding process, the following [technical document](https://gitlab.com/opencraft/documentation/private/blob/master/ops/client_data.md) provides guidelines on how to handle client data.
......@@ -84,7 +84,7 @@ Atlassian tool used to alert and page team members in case of incident. See [Ops
## OSPR
Short for ["Open Source Pull Request"](pull_request_process.md#OSPR). This is the edX process for reviewing pull requests from the open source community.
Short for ["Open Source Pull Request"](https://handbook.opencraft.com/en/latest/processes/#ospr). This is the edX process for reviewing pull requests from the open source community.
## OVH
......@@ -94,7 +94,7 @@ The [OpenStack](https://www.openstack.org/)-based cloud computing service we use
Also known as "story points", these represent the approximate "level of effort" and time a task would require. See [Task
Workflows](task_workflows.md#general-tasks) for a description of how we use points. The cells collectively vote on story
points for the tasks in the upcoming sprint, see [Process for sprints](process.md) for details.
points for the tasks in the upcoming sprint, see [Process for sprints](https://handbook.opencraft.com/en/latest/processes/#sprints) for details.
## Prometheus
......@@ -111,7 +111,7 @@ Also know as "user story", is a specific Jira ticket that represents a user need
## Task refinement / Agile poker
Also know as "planning poker" or "Scrum poker" is a gamified technique for estimating tasks. We are exclusively using the [agile-poker Jira plugin](https://marketplace.atlassian.com/apps/700473/agile-poker-for-jira-planning-estimation) for our [refinement session](sprint_planning_agenda.md#refinement-session).
Also know as "planning poker" or "Scrum poker" is a gamified technique for estimating tasks. We are exclusively using the [agile-poker Jira plugin](https://marketplace.atlassian.com/apps/700473/agile-poker-for-jira-planning-estimation) for our [refinement session](https://handbook.opencraft.com/en/latest/processes/#sprint-retrospectives).
## Tempo
......
......@@ -43,7 +43,7 @@ Once ready for review, ping your reviewers.
##### Proofreading Process
Once the draft has been reviewed and the comments addressed, it's time to have your copy proofead. Follow the steps from [proofreading procedure](/processes/#proofreading) in the Handbook to have your copy proofread.
Once the draft has been reviewed and the comments addressed, it's time to have your copy proofead. Follow the steps from [proofreading procedure](#proofreading) in the Handbook to have your copy proofread.
##### Publication
......@@ -286,7 +286,7 @@ When writing a pull request, you want to make it as easy as possible for everyon
Example title: "[SE-1234] Implement UI to import a content library from a .tar.gz file"
**Decisions**: Remember that pull requests are not often seen after they merge - so as explained in [Coding Standards](/processes/#opencraft-coding-standards-and-best-practices) you should always document major design decisions within the codebase itself (docstrings, README, ADRs) and just link to that explanation from the PR description.
**Decisions**: Remember that pull requests are not often seen after they merge - so as explained in [Coding Standards](#opencraft-coding-standards-and-best-practices) you should always document major design decisions within the codebase itself (docstrings, README, ADRs) and just link to that explanation from the PR description.
**Template**: [The `edx-platform` pull request template](https://github.com/edx/edx-platform/blob/master/.github/pull_request_template.md) shows what is expected in a good pull request description; we recommend using this template when you open a new pull request.
......@@ -358,7 +358,7 @@ Additionally, you can read more in this [article](https://chris.beams.io/posts/g
1. 🔗 **Link to the sandbox**, if available. A sandbox makes it easier for reviewers to test your code. For `edx-platform` pull requests, Ocim will try to create a sandbox for you automatically, but you'll still need to check that it worked and link it to the PR. For other PRs, you'll need to create a sandbox manually if possible. See "Sandbox process details" below. At this point, the sandbox may also be out of date, so make sure it's running the latest version of your code.
1. 📡 **Ping your OpenCraft reviewer** on the JIRA ticket that this is ready for review. If there are multiple PRs, include a link to the PR in your ping. (It's not necessary to also ping them on the pull request itself.)
1. 💯 **Address the feedback** from your reviewer, and get their approval.
1. 📡 **Ping your upstream reviewer** (all PRs to external repositories) or [core committer reviewer](/processes/#how-to-request-core-committer-review) (only PRs to edX repositories), if you know who they are. If this is an open source contribution / [OSPR](/processes/#ospr), you may need to wait for edx / the upstream project to assign a reviewer. If this is an OpenCraft repository/project, skip this step and the next.
1. 📡 **Ping your upstream reviewer** (all PRs to external repositories) or [core committer reviewer](#how-to-request-core-committer-review) (only PRs to edX repositories), if you know who they are. If this is an open source contribution / [OSPR](#ospr), you may need to wait for edx / the upstream project to assign a reviewer. If this is an OpenCraft repository/project, skip this step and the next.
* Just as for internal reviews, the Core Committer needs the be assigned before the sprint starts to avoid injections in the Core Committer's sprint
1. 💯 **Address the feedback** from your upstream reviewer, and get their approval.
1.**Squash** your PR down to "one commit per major change", with a clear commit message. Put useful context from the PR as additional lines in the commit message if useful. You should also rebase on top of the latest `master` branch while you do this, and fix any merge conflicts that may arise.
......@@ -528,7 +528,7 @@ Once a newcomer has signed their contract, the CEO creates an [onboarding checkl
Once the newcomer has access to the tools and joined the team, the onboarding and trial period starts.
Since newcomers may start at any time during the sprint, this process overlays the [sprint process](/processes/#sprints).
Since newcomers may start at any time during the sprint, this process overlays the [sprint process](#sprints).
Newcomers are expected to participate in sprint planning meetings, commit to tasks for the upcoming sprint, and practice
time management using the sprint planning tools and by updating the Remaining Time estimate fields on their tasks.
......@@ -861,12 +861,12 @@ At this stage, we determine if a lead is a good fit for us, and how much effort
* Keep a lookout for new potential projects with contacts and within current client organizations (bizdev, developers)
* Greet our leads, and send them our standard hosting/support quote (bizdev)
* Assess public Requests For Proposals (RFP) and determine if they're a match
* Apply the [Lead Prioritization Rubric](/processes/#lead-prioritization) to qualify leads and determine next course of action
* Apply the [Lead Prioritization Rubric](#lead-prioritization) to qualify leads and determine next course of action
* Capture information in the CRM (bizdev)
* Do periodical follow-ups (bizdev)
###### What resources and tools are used?
* [Lead prioritization rubric](/processes/#rubric)
* [Lead prioritization rubric](#rubric)
* [Customer Relationship Management (CRM) tool](https://opencraft.monday.com/boards/1042640419)
* [RFP match criteria document](https://docs.google.com/document/d/1evZOp13EHbaUpgMw70cYhAQEXz7Beo8deQ1kMIGD7Jw/edit#)
......@@ -899,7 +899,7 @@ We need to get a clear understanding of:
###### What resources and tools are used?
* [Lead prioritization rubric](/processes/#rubric)
* [Lead prioritization rubric](#rubric)
* [Customer Relationship Management (CRM) tool](https://opencraft.monday.com/boards/1042640419)
###### How does the opportunity advance to the next stage (stage gate)?
......@@ -976,14 +976,14 @@ In this stage, the client formally commits to OpenCraft by:
###### What activities are involved (and who does them)?
* Summarizing the benefits and value of our proposal, when required (bizdev)
* Completion of [onboarding steps](/processes/#client-onboarding-and-offboarding)
* Completion of [onboarding steps](#client-onboarding-and-offboarding)
* Resolve any outstanding legal and business issues (bizdev, admin specialist)
* Conduct kickoff meeting (kickoff) (bizdev, dev)
* Capture information in CRM
###### What resources and tools are used?
* Handbook: [Onboarding a client](/processes/#client-onboarding-and-offboarding)
* Handbook: [Onboarding a client](#client-onboarding-and-offboarding)
* [Customer Relationship Management (CRM) tool](https://opencraft.monday.com/boards/1042640419)
* Project kickoff [guide](https://plan.io/blog/kickoff-meeting/)
......@@ -1045,10 +1045,10 @@ in sync.
| Day of Sprint | |
|-------------------|----------------------------------------------------------|
| Day 0 (Monday) | Each cell holds a [sprint planning meeting](/processes/#planning-agenda) to do a final review of the plans for the upcoming sprint, and start the sprint. We use the [Sprints app] to plan our team's time (that everyone has enough work and nobody will be overcommitted) and to collectively make sure we're staying on track with each client's monthly budget and each epic/project budget. |
| Day 0 (Monday) | Each cell holds a [sprint planning meeting](#planning-agenda) to do a final review of the plans for the upcoming sprint, and start the sprint. We use the [Sprints app] to plan our team's time (that everyone has enough work and nobody will be overcommitted) and to collectively make sure we're staying on track with each client's monthly budget and each epic/project budget. |
| Day 0 or 1 | Each developer should review every ticket they have in the sprint, to confirm the due date, plan when/how to approach the work, coordinate with the reviewer for time-sensitive reviews, etc. |
| Days 0-4 | Development - each team member works on their tickets and code reviews. Tasks move from left to right until completion on our JIRA tracker. |
| Day 7 (Monday) | Each cell holds a [mid-sprint meeting](/processes/#planning-agenda) to ensure everything is going smoothly, and discuss how to help with tasks that are at risk of not being finished by the end of the sprint. |
| Day 7 (Monday) | Each cell holds a [mid-sprint meeting](#planning-agenda) to ensure everything is going smoothly, and discuss how to help with tasks that are at risk of not being finished by the end of the sprint. |
| Days 7-11 | Development continues |
| Day 10 (Thursday) | Each epic owner posts an epic update, which includes creating and prioritizing all tasks from that epic that their cell should work on in the upcoming sprint. |
| Day 11 (Friday) | Cells collaboratively and asynchronously refine and estimate tasks complexity. Once done, they assign tasks and reviews to themselves.<br> **End of day Friday is the deadline for creating and assigning stories to the upcoming sprint**, and is also when the asynchronous refinement session is closed. |
......@@ -1101,7 +1101,7 @@ in sync.
for the upcoming sprint are in line with each client's budget and each
epic's budget.
* We have a meeting on Monday via video chat. There we review the refinement and assignments
for the upcoming sprint (please see the [sprint planning agenda](/processes/#planning-agenda)
for the upcoming sprint (please see the [sprint planning agenda](#planning-agenda)
for details of this meeting).
* The meeting link is in the calendar invite.
* If you don't see the meetings as recurring events on your calendar, ask Xavier to send
......@@ -1153,7 +1153,7 @@ The sprint planning manager creates the sprint estimation session in Jira. An em
* Decide whether you can take it
* If you do want it, it's ok to spend a bit more time investigating
* If you have questions, put them in comments on the ticket
* Assign points as described in the [process section](/processes/#sprints)
* Assign points as described in the [process section](#sprints)
* Use the "estimate comments" box to qualify estimates
* Choose `?` if you have no idea how many points
* A little green `(/)` will appear next to your picture up top when you are done
......@@ -1373,7 +1373,7 @@ as checklists for backups of a specific role during the vacation.
1. If you own any epics, transfer any knowledge needed to the epic reviewer, and make
sure they are still prepared to plan/review all the needed stories and manage the
epic while you are away.
1. Similarly, for all of your [roles](/roles)
1. Similarly, for all of your [roles](https://handbook.opencraft.com/en/latest/roles/#roles)
and rotations, identify a backup (and for rotations like firefighting, see if the
other firefighter will be off the same days as you), and inform them of the days they
will need to cover for you.
......
......@@ -25,7 +25,7 @@ The general expectations for anyone working at OpenCraft:
* I will ensure that clients and people on the cell that I'll be working with (e.g. code reviews)
know my availability. (e.g. If I'm taking Friday off, I'll make sure people who need me
to do code review know that).
* When taking time off, I will follow the procedure described on the [vacation's section](vacation.md).
* When taking time off, I will follow the procedure described on the [vacation's section](https://handbook.opencraft.com/en/latest/processes/#vacation).
* If I'm unexpectedly sick or unavailable due to an emergency, I'll make every effort to notify
my cell and ask the [sprint firefighters](#firefighter) to take over my duties.
* I will provide my own hardware (laptop).
......@@ -101,7 +101,7 @@ The general expectations for anyone working at OpenCraft:
### Sprint tasks
* I will follow the process and expectations outlined in the [pull request process](pull_request_process.md)
* I will follow the process and expectations outlined in the [pull request process](https://handbook.opencraft.com/en/latest/processes/#pull-request)
section.
* I will never add my code (even DevOps code!) to a production branch directly - I will always
create a Pull Request.
......@@ -235,7 +235,7 @@ The recruitment manager role is responsible for organizing the selection of cand
This role is different from the [cell sprint manager](#cell-sprint-manager), though both roles can be taken by the same person if desired.
The tasks and their schedule are detailled in the [sprint planning agenda](sprint_planning_agenda.md#sprint-planning), but here is a non exhaustive overview:
The tasks and their schedule are detailled in the [sprint planning agenda](https://handbook.opencraft.com/en/latest/processes/#planning-agenda), but here is a non exhaustive overview:
* Create and close task estimation session for next sprint, allowing time for the assignees to take them and make proper planning.
* When creating the session, add all the unestimated tickets for next sprint and on stretch goals to it.
......@@ -329,7 +329,7 @@ disagreement about that, for example about how priorities relate to each other.
"Time / Estimates" sheet of the Epic Planning spreadsheet.
* Maintain a count of the amount of time required to complete the accepted
budgets over the next months in the epic planning spreadsheet
for your cell. This is used to [inform recruitment needs](recruitment.md#launch-of-a-recruitment-round).
for your cell. This is used to [inform recruitment needs](https://handbook.opencraft.com/en/latest/processes/#launch-of-a-recruitment-round).
* Keep a look out for completed discoveries. If a discovery is generic and the
estimates it produced can be reused for further discoveries and estimates
down the line, add it to the
......@@ -400,7 +400,7 @@ h4. Notes
* **Setting internal budgets**. The sustainability manager is responsible for setting budgets of
*non-billable cell accounts* in the [Sprints](https://sprints.opencraft.com) app and for reviewing
and updating them after each sustainability report, in coordination with epic owners.
* **Next sprint's sustainability prediction**. When [planning the next sprint](sprint_planning_agenda.md),
* **Next sprint's sustainability prediction**. When [planning the next sprint](https://handbook.opencraft.com/en/latest/processes/#planning-agenda),
the sustainability manager will review the amount of billable and unbillable work scheduled by the
cell for the next sprint, and will warn the epic owners about any budget issues and get them to
address those proactively. If the situation cannot be redeemed immediately, the sustainability
......@@ -496,7 +496,7 @@ As a **code reviewer**:
* I will give prompt, thoughtful, thorough, constructive code reviews.
* (When reviewing OpenCraft work): I will expect that the PR author has done everything outlined in the
*PR expectations* part of the [pull request process](pull_request_process.md)
*PR expectations* part of the [pull request process](https://handbook.opencraft.com/en/latest/processes/#pull-request)
section - if not, I will ask them to fix that before I start the review.
* (When reviewing non-OpenCraft work): If I get pinged to review a PR, I will
respond to it within 24 hours. If it is for a ticket in the current sprint, I
......@@ -579,7 +579,7 @@ If I'm **new to the team**, I will:
Also, it is not compulsory to log X hours per week as stated in the contract -- our contracts give an estimated amount
of time expected per week, but the actual work required for each sprint can vary due to many factors.
See the [Process: Onboarding & Evaluation](recruitment.md) page for more advice on the onboarding, the evaluation
See the [Process: Onboarding & Evaluation](https://handbook.opencraft.com/en/latest/processes/#recruitment) page for more advice on the onboarding, the evaluation
process and criteria.
#### Onboarding epic ownership
......@@ -623,16 +623,16 @@ As a newcomers, I am the owner of my onboarding project, and will:
### Mentor
* I will make sure to inform the team I'll mentor a newcomer before their first day.
* I will familiarize myself with the current [onboarding & evaluation process](recruitment.md), so I can
* I will familiarize myself with the current [onboarding & evaluation process](https://handbook.opencraft.com/en/latest/processes/#recruitment), so I can
answer questions and help the newcomer through the process.
* I will allocate sufficient time in my sprint, especially at the beginning, to assist and mentor the newcomer.
* I will help the new member in selection of tasks during sprint planning and ensure their assigned tasks meet the goals [specified below](#how-to-select-tasks-for-new-members).
* I will schedule an initial 121 meeting with the newcomer, and a recurring meeting every week.
These can be spaced out later on if the meetings become less useful. Refer to
[the mentor checklists page](mentor_checklists.md) for the topics to go through.
[the mentor checklists page](https://handbook.opencraft.com/en/latest/roles/#mentor-checklists) for the topics to go through.
* For the first 121 with the newcomer, I'll prepare a few interview questions to help in the screening process.
* I will participate on the screening and developer review tasks, taking into account these
[evaluation criteria](recruitment.md#evaluation-criteria).
[evaluation criteria](https://handbook.opencraft.com/en/latest/processes/#evaluation-criteria).
* I will evaluate the newcomer's usage of the onboarding budget and raise any issues with Xavier. I'll also help the newcomer with
creating, estimating and scheduling learning tasks in the onboarding epic, tracking them and with
precise time tracking of his/her tasks if the work logs show too many approximate (i.e. rounded) values.
......@@ -1082,7 +1082,7 @@ h6. Other Notes
* On Thursday or Friday in the final week of each sprint, I will assign
upcoming stories from this epic that need to be done next sprint
to myself - or I will ask others from my cell to be either the assignee or the reviewer.
* If I'm going on leave, I will follow the [vacation procedure](vacation.md), and hand off my responsibilities for my epic to
* If I'm going on leave, I will follow the [vacation procedure](https://handbook.opencraft.com/en/latest/processes/#vacation), and hand off my responsibilities for my epic to
Epic Reviewer.
### Epic Reviewer
......@@ -1103,7 +1103,7 @@ Epic reviewers are assigned to the 'Reviewer' field on an Epic ticket. As an **e
task reviews.
* Initial contact with prospects, estimations work. Note that a portion of Business development's
time is assigned to each cell to do most of the initial contact and quote work with prospects.
* Client owners keep the [Client Briefings](client_briefings.md) up to date.
* Client owners keep the [Client Briefings](https://handbook.opencraft.com/en/latest/working_with_clients/#client-briefings) up to date.
For each client, we have a single person who is designated as the owner for that client, called
the "client owner." The client owner is responsible for handling most communications with that
......@@ -1159,7 +1159,7 @@ As a **business development specialist**:
* I will handle the onboarding of confirmed clients: tell them how to work with us, such as when/how
to use the urgent@opencraft.com email address, when/how to use help@opencraft.com, who
their main contact(s) should be, how billing works, etc. I will write the initial
[Client Briefing](client_briefings.md) in our CRM.
[Client Briefing](https://handbook.opencraft.com/en/latest/working_with_clients/#client-briefings) in our CRM.
* When working on a new project or client, I will handle initial communication and coordination
between the client and the cell working on the project (until the kickoff/handover to the client owner).
* Generally, when writing to the clients, I will always make sure there is either contact@, help@, or billing@ CC'd:
......
This diff is collapsed.
......@@ -120,7 +120,7 @@ The `Create` button in JIRA will open a form where you need to input some basic
* `summary`: it's a short title
* `description`: the most important field. We have [a template](#task-description-standard) that you can use. As a reporter you should include all the information in the template
* `story type` ([story](glossary.md#story), [epic](glossary.md#epic), bug): use *story* by default, or *bug* if the task looks like a bug fix. We treat both in the same way but they get different icons. Use *epic* if you're creating new projects (see [epic management](epic_management.md))
* `story points`: leave this blank and then we'll include this task in an [estimation session](sprint_planning_agenda.md#refinement-session). If the task is trivial you can estimate it yourself
* `story points`: leave this blank and then we'll include this task in an [estimation session](https://handbook.opencraft.com/en/latest/processes/#estimation-session). If the task is trivial you can estimate it yourself
* `original estimate` and `remaining estimate`: these can be decided later by the assignee. The *original estimate* is set once and doesn't change, whereas the *remaining estimate* is dynamic. They will start at the same value but the *remaining estimate* will decrease as time is logged, and you may also manually adjust it. If the estimate for this task has been shared with the client (e.g., the task came from a [discovery](glossary.md#discovery)), then use that estimate here. The assignee might still change this number, but it gives them an idea of where to start
* `assignee` and `reviewer`: these can be decided later
* `sprint`: unless you're sure about when will we do the task, leave this blank and ping the epic owner to schedule it
......@@ -282,7 +282,7 @@ These are the main views you'll use:
- the _backlog view_ (where you see 1 task per row), while planning sprints. Find the link for your [cell](cells.md)
- the _weekly sprint board_ (where you see columns), while working on the current sprint. Find the link for your [cell](cells.md)
- `tempo` views, for [time logging](time_logging.md). Refer to [these instructions](https://courses.opencraft.com/courses/course-v1:OpenCraft+onboarding+course/courseware/week_1/first_sprint/6?activate_block_id=block-v1%3AOpenCraft%2Bonboarding-dev%2Bcourse%2Btype%40vertical%2Bblock%40how_when_to_pick)
- `tempo` views, for [time logging](https://handbook.opencraft.com/en/latest/time_management/#time-logging-best-practices). Refer to [these instructions](https://courses.opencraft.com/courses/course-v1:OpenCraft+onboarding+course/courseware/week_1/first_sprint/6?activate_block_id=block-v1%3AOpenCraft%2Bonboarding-dev%2Bcourse%2Btype%40vertical%2Bblock%40how_when_to_pick)
- estimation session (you'll receive a link)
- and of course the individual task view. Use the Edit button to modify any task field. Note that some advanced operations, like classifying a task as [newcomer-friendly](#newcomer-friendly-tasks), cannot be done from the task itself and are done from the backlog or sprint views
......
......@@ -150,7 +150,7 @@ the word "we" is intentional here, because a sprint is a team effort, and so spi
failing. Task reviewers, mentors, and sprint firefighters all have time set aside to help complete tasks, and it's ok
to lean on them and ask for help.
This is also why we have a [minimum spillover allowance for newcomers](/processes/#evaluation-criteria), because we need
This is also why we have a [minimum spillover allowance for newcomers](https://handbook.opencraft.com/en/latest/processes/#evaluation-criteria), because we need
everyone to take spillover seriously, and to know that everyone can improve.
### How to address spillovers?
......
......@@ -16,7 +16,7 @@ for that client.
### Initial Briefing
When a new client signs a contract with us, the Business Development
Representative will post an initial 'Client Briefing' with [this template](client_briefing_template.md), which has been
Representative will post an initial 'Client Briefing' with [this template](https://handbook.opencraft.com/en/latest/working_with_clients/#client-briefings), which has been
made into a separate page so its formatting can be copy-pasted. Time for this work should be logged to whatever epic
we start for this client.
......@@ -48,7 +48,7 @@ An overview of when, why, and how edX does "blended development" is on their wik
#### General tips:
* Before opening a [pull request](/processes/#pull-request), review the [Blended PR Workflow](https://openedx.atlassian.net/wiki/spaces/COMM/pages/1947926666/Blended+PR+Workflow) which explains the procedure for opening a PR on any blended project. (In addition to the usual [PR process](/processes/#pull-request) that we follow on all projects.)
* Before opening a [pull request](https://handbook.opencraft.com/en/latest/processes/#pull-request), review the [Blended PR Workflow](https://openedx.atlassian.net/wiki/spaces/COMM/pages/1947926666/Blended+PR+Workflow) which explains the procedure for opening a PR on any blended project. (In addition to the usual [PR process](https://handbook.opencraft.com/en/latest/processes/#pull-request) that we follow on all projects.)
* Remember to default to public communications. This is an open source project and generally most of the aspects of blended development can be public - so default to discussing and documenting things on public Confluence pages, Jira tickets, ADRs, Discourse threads and public Slack channels.
* If that doesn't get enough attention or timely response, then ping on synchronous and/or private tools, linking to the public question.
* Slack is one of edX's major communication channels and we should not be hesitant to ping people on it, in the same way we try to reduce synchronous pings on Mattermost within OpenCraft.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment