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

roles.md 88.8 KB
Newer Older
1
# Roles and Expectations
2

3
4
One other important way that we do differently than a lot of companies is the way we assign
responsibility. Instead of titles, which are linked to the concept of hierarchies and ranking,
5
6
we use [roles](#roles), and all people in the organization share a
[set of expectations](#what-is-expected-from-everyone).
7

8
## What is expected from everyone
9

10
The general expectations for anyone working at OpenCraft:
11
12
13

* I can work from wherever I want, provided I have access to a reliable high-bandwidth internet
  connection good enough for video calls.
14
* I can set my own work schedule, and work when I want during the week, as long as **I remain
15
  available to answer to others** (please see: the **Communication** section below)
16
* (In general) **I am *not* expected to work weekends** (unless I'm behind on my commitments),
17
  which should remain an exception, not the rule! If you find yourself forced to work on week ends
18
  more than once per month, that likely reflects an issue with your time management that needs
19
20
  fixing. If I work week ends as a personal choice, I will not expect other team members to also
  work week ends.
21
* I will make sure my [cell's responsibilities](#cell-member) are continuously being properly
22
  taken care of, by reviewing their status at least once per week.
23
* I will work at least the amount of hours per week that is specified in my contract (e.g. 40
24
  hours/week), averaged over each month, excluding scheduled holiday time.
25
* I will ensure that clients and people on the cell that I'll be working with (e.g. code reviews)
26
27
  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).
28
* When taking time off, I will follow the procedure described on the [vacation's section](processes/vacation.md).
29
* If I'm unexpectedly sick or unavailable due to an emergency, I'll make every effort to notify
30
  my cell and ask the [sprint firefighters](#firefighter) to take over my duties.
31
32
33
34
35
36
37
38
* I will provide my own hardware (laptop).
* I will keep my computer(s) secure and up to date as described in the
  [security policy](security_policy.md).
* I will record all hours that I spend on a task using the Tempo timesheets tool in JIRA
  (including things like setting up devstacks and time spent learning, which we all need to do
  and is an important part of the task, especially at the beginning, or when joining a project).
* If I use another tool for tracking my time,
  I will update the JIRA Tempo timesheets within 24 hours (excluding weekend days).
39
* I will attend the Open edX Conference every year, unless exceptional and important personal
40
41
42
  circumstances prevent me from being present (Note that team members who joined OpenCraft before
  July 31st 2018 are [only encouraged to attend the conference, but not strictly required to](https://forum.opencraft.com/t/open-edx-conference-attendance/134/20)).
* As a conference attendee, I will submit a talk proposal and present it. If my talk isn't
43
  accepted, I will co-present a talk with someone else from OpenCraft.
44

45
### Communication
46

47
* **If any client email is addressed to me, I will respond to it within 24 hours (excluding weekend
48
  days), or ensure that someone else on my cell does.**
49
50
    * I will CC or forward to help@opencraft.com all client emails and replies, so that others can take over the thread
      with that client if needed, or refer to it for context.
51
    * If I can't answer immediately, I will at least send a quick reply to let them know we're
52
      working on a response, and when they should expect it.
53
54
55
56
57
58
59
* **I will reply to pings/emails from other OpenCraft team members within 24 hours**
  (again excluding weekend days and scheduled time off).
    * But this should be a "worst case" scenario - completing the work on time
      is still the primary goal, so when someone is blocked and pings me for help,
      I will try to do as much as I can to unblock them quickly,
      rather than starting a 24h ping-pong cycle that takes up all the time
      in the sprint without accomplishing any work.
Loïc Dachary's avatar
Loïc Dachary committed
60
* **I will respond to pings on GitHub or GitLab within 24 hours**
61
62
  (with the usual exclusion for weekend days and scheduled time off).
    * If a ping has no corresponding ticket, or the ticket is not scheduled for
Kshitij Sobti's avatar
Kshitij Sobti committed
63
      the current sprint, I will respond to the ping with an estimate for when
64
      they can expect a full response.
65
66
67
* I will read and respond to forum threads:
    * On the [announcements forum](https://forum.opencraft.com/c/announcements/7): within 24h, excluding week-ends & time off;
    * On the rest of the forums, within 2 weeks, except for the [off topic forum](https://forum.opencraft.com/c/off-topic/8), which doesn't need to be read or replied to at all.
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
* I will be professional and polite when communicating with clients.
* I will prefer asynchronous over synchronous processes (keep meetings to a minimum). A chat
  conversation is a form of a meeting.
    * Generally, discussions should happen first asynchronously on the JIRA tickets;
      if there is really something that can't be efficiently sorted out asynchronously,
      have a chat or schedule a meeting. JIRA might have long response cycles (around
      1 day turnaround). If this time isn't enough to unblock someone and
      finish their sprint commitments, use Mattermost, even though
      it's more disruptive to people's workflow.
    * If you do have a synchronous conversation with someone about a particular task,
      post a summary of the result/decision from that conversation on the JIRA ticket
      for easier future reference.
    * When scheduling meetings, give them a precise agenda. For people using Calendly,
      like Braden and Xavier, book meetings there, as it allows us to avoid
      the scheduling overhead.
    * Try, as much as possible, to use a similar approach with clients - don't
      let them invade your days with meetings. Calendly is good for this too,
      as it allows to define time slots where you'll have the meetings,
      to minimize the disruption they cause to your day and productivity.
      If you want a calendly account, let Xavier know and he will set
      you up with the OpenCraft account.
* I will post on public channels on Mattermost rather than private 1-to-1 channels
  whenever possible, even if the message is just for one person.
  This allows us to know what others are working on, and helps to replace
  the overheard discussions in physical offices - it can also be an occasion
  for someone else with knowledge about your issue to get the context,
  and to intervene if it is useful to the conversation.
* I will make sure I communicate with my reviewer(s) on tasks about availability
  and timezone overlap if I didn't have knowledge about it before. I will use the
  [contact sheet](https://docs.google.com/spreadsheets/d/107dR9H1vWjLpJlXPuBaFJIFaEPEmaSh50xLow_aEGVw/edit)
  where necessary.
99
100
* I will join the weekly sprint meeting of my cell on Mondays, unless I have scheduled that day
  off in advance.
101

102
### Sprint tasks
103

104
* I will follow the process and expectations outlined in the [pull request process](processes/pull_request.md)
105
  section.
106
* I will never add my code (even DevOps code!) to a production branch directly - I will always
107
108
109
110
111
112
  create a Pull Request.
* I will always ensure my Pull Requests are reviewed by another OpenCraft team member **before** merging,
  except if I am a *core team member* and I'm merging *trivial changes*.
  In this exceptional case, I may merge the *trivial changes* before receiving a review,
  but I will then ensure all of those *trivial changes* are reviewed and acknowledged post-merge or
  post-deployment by another OpenCraft team member. Trivial changes include:
Loïc Dachary's avatar
Loïc Dachary committed
113
114
    * Small Open edX environment tweaks ([example](https://user-images.githubusercontent.com/514483/34581710-c167d10c-f191-11e7-9a66-7fa8c59def82.png))
    * Minor/bugfix package version bumps ([example](https://github.com/open-craft/ansible-rabbitmq/pull/4/files))
115
* I will only commit to work each sprint that I believe I can comfortably complete within the
116
  allotted sprint time (two weeks). Here, "complete" means "get to external review or get merged, deployed, and delivered."
117
* As a core team member, I will avoid taking [newcomer-friendly tasks](task_workflows.md#newcomer-friendly-tasks) unless they are urgent
118
119
  and there are no newcomers available to take them on.  I will take on reviews of newcomer-friendly tasks, and allow
  time to provide mentoring and extra guidance.
120
* I will get all of my tasks ready for internal review (by someone else on the OpenCraft team) by the
121
  **end of Wednesday in the second week of the sprint** at the latest. This will ensure that
122
123
124
125
126
127
  there is time for the review to take place, and for me to address the review comments
  and get the internal reviewer's approval in time.  If a ticket potentially requires multiple
  review cycles, get it into review as early as possible.  Schedule reviews with your reviewer
  to make sure they have time when you get your work ready for review.
* I will spend time to plan each task at the beginning of each sprint, including scheduling the
  review with the reviewer. Make sure you have an answer for:
Loïc Dachary's avatar
Loïc Dachary committed
128
129
130
    1. When do each step of the task need to be completed?
    1. Which days will you work on which task?
    1. When do individual parts need to be completed to be on time?
131
* It's also important to keep some margin on the sprint, in case something doesn't go as expected.
132
* I will get my tasks to at least **External Review**  (or "Deployed & Delivered" if no external review is required) by
133
134
135
  **one hour before the sprint planning meeting for the next sprint**. As this is also dependent on
  the internal reviewer, I'll make sure she/he will be available around the time I finish.
* If it is looking like I will have trouble meeting one of these deadlines,
136
  I will inform the [sprint firefighters](#firefighter) (and [epic owner](#epic-owner)) as early as possible,
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
  so they can get me additional help, start planning for contingencies,
  and/or warn the client.
* If necessary, I will work overtime to complete my tasks before the end of the sprint.
* I will prioritise stories that spilled over from the previous sprint.
* I will "work from the right", prioritizing responding to external reviews
  as the highest priority, then doing reviews / responding to questions
  from others on the team, and finally working on implementing my own "In Progress" tasks.
* I will be helpful to team members, responding to questions,
  helping with debugging, providing advice, or even taking over tasks
  if I have time and they are overloaded. This has precedence over starting
  to work on new tasks, when finishing a sprint early.
* Once a sprint, I will review all of my tasks that are in "Long External Review/Blocked"
  and if needed, I will ping the external reviewer/blocker or pull the task into
  an upcoming sprint.

152
## Roles
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168

Roles can be taken on by willing people, and people will usually take on multiple
roles, changing over time, based on interest and availability. This allows for a much smoother
progression of responsibilities than the ladder climbing game.

Note that responsibility is also uncorrelated with compensation and raises, which are given the
whole core team at once, based on time spent working at the company and overall financial results.
Compensation isn't a good source of motivation beyond a certain level, and this approach removes
a lot of politics.

If there is any role you would like to take up, the best way is to say it publicly - for example
in the forum. Then when opportunities arise others will remember it, and point you to tickets
you can own. Keep in mind that role assignments are intended to be permanent, so keep that in
mind before picking a role. Ideally you should work in a role for at least one year before you
consider swapping/dropping it.

169
### Changing Roles
170
171
172
173
174
175
176
177
178
179
180
181
182
183

Once someone takes up a role in a call there generally no need to reassign it unless someone leaves
OpenCraft. While an appointment to a role is generally permanent, no one should feel stuck in a
role if they are no longer comfortable in it. As such it is desirable to openly discuss with other
members of the cell on the forum, and perhaps in the sprint meeting when such a situation arises.

It is the responsibility of the current person with a role to find a replacement in their cell and
help their replacement during a transition period while they are still getting comfortable with
their new responsibilities.

Note that for roles like Client Owner or DevOps Specialist where the role involves a fair bit of
specialised knowledge or context, great care should be taken to find a suitable replacement with
a similar level of knowledge and context.

184
### Types of OpenCraft members
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204

There are three types of members at OpenCraft:

* *Additional members*:
    * *Short-term members* (temporary contractors), who have been hired for a specific task, scope
      or period of time. They are the most external members of the team.
    * *[Newcomers](#newcomer) on probation* (2 months, renewable).
* *Core team member* - the new recruits who have been confirmed become core team members. They differ
  from the other types of members in that they tend to have more team-based responsibilities.
  For example, core team members are on a
  [weekly rotation schedule](https://docs.google.com/spreadsheets/d/1ix68BsU2hJ2ikexXWeBcqFysfoF4l7IKRghIDQgyfPs/edit#gid=447257869)
  where they often have to take on some additional roles, including Sprint Firefighter, being on
  Discovery Duty, and occasionally leading our weekly sprint kick-off meeting.

However, in all other regards, all types of developers are put to the same expectations -- no
politics or special treatment between short-term developers, newcomers, and core team members.

The only acceptable exception is when providing extra mentoring on tasks for newcomers (or anyone
known to not have much context in the task), which is expected and useful.

205
### Cell member
206
207

The coordination on each of these responsibilities is to be assigned, each one to an individual
208
209
member of the cell as a recurring task. However, the way this responsibility is handled beyond
what is described in this handbook is the responsibility of the cell as a whole, with all of its
210
211
212
213
214
215
members being considered as weekly reviewers.

Each responsibility can be handled through multiple tasks assigned to multiple owners, as
long as the overall responsibility for the coordination of each item is assigned to a single
person:

216
#### Cell recruitment manager
217

218
The recruitment manager role is responsible for organizing the selection of candidate hires to match the needs of the [epic planning spreadsheet] for the cell, as determined by the epic planning manager. This includes:
219
220

* Selection of newcomers (see the [recruitment checklist](https://opencraft.monday.com/boards/948961077/)):
221
222
223
224
  * Pre-selection of candidates for interviews among the received candidatures;
  * Interviews (scripted, recorded for asynchronous review);
  * Selection of newcomers among the interviewed candidates (with review & confirmation by CEO);
  * Correspondance with candidates (positive & negative answers), except contract negotiation handled by the CEO;
225
* Onboarding and offboarding of newcomers, including:
226
227
228
  * Creation of their accounts on the OpenCraft tools & granting rights;
  * Creation of their onboarding epic and tasks;
  * Find their mentor, ahead of their start date;
229
* Organization of the review and confirmation of core developers:
230
231
  * Ensure that all core members of the cell participate in the review, as well as one core member from each other cell;
  * Compile the feedback from individual reviews in a consolidated list, which doesn't include the names of individual reviewers;
232
* Regularly review recruitment trial results for interview selection accuracy.
233

234
#### Cell sprint planning manager
235
236
237

This role is different from the [cell sprint manager](#cell-sprint-manager), though both roles can be taken by the same person if desired.

238
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:
Samuel Walladge's avatar
Samuel Walladge committed
239

240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
* 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.
  * Add epic owners as Scrum Masters, so that they can add the tickets they create or pull in after the estimation session was created.
  * Ping everyone that hasn't participated on the estimation session to estimate before closing the session.
* The cell being the closest to the client needs, and knowing best the work to be performed,
  it's positioned the best to prioritize its own backlog accordingly. To do so, it must
  prioritize in the following order (decreasing priority):
    1. Client work to ensure that the client needs are met, and that they are happy with
       our work.
    1. [Newcomer-friendly tasks](task_workflows.md#newcomer-friendly-tasks) should be ranked high enough in the list of tasks to
       allocate time for core team member review/mentoring. The earlier we can get newcomers up to speed, the better
       the workload will be for everyone.
    1. Internal projects flagged by the management as priorities.
    1. Additional work the cell finds useful to its or OpenCraft's function (or the Open
       edX community's), as long as the cell remains sustainable in proportion of
       billable hours. The cell defines and prioritizes the additional internal work,
       without a specific monthly budget cap (epic time budgets remain a good practice to
       follow, but the amount set doesn't require approval from management).

Note: It's important to keep in mind that to remain capable of leading initiatives at the company
level, not just at the cell level, hierarchy can retain an important role in prioritization.
Anyone in a cell can propose or prioritize a company-wide initiative, provided they get approval
and buy-in from people it would affect. It would escalate to management if there's a conflict or
disagreement about that, for example about how priorities relate to each other.

265
#### Cell sprint manager
266
267

* Each cell has its own sprint board and tickets, and is responsible for handling the sprint,
268
269
270
  as well as its preparation and estimation.
* Every Monday before the start of the new sprint, review:
    * Tasks from the previous sprint, waiting for 3rd party, "long reviews", and in the backlog;
271
272
    * [Epics](https://tasks.opencraft.com/secure/RapidBoard.jspa?rapidView=8&useStoredSettings=true);
    * Rotations - double-check if any of the people assigned to a rotation in the upcoming
273
      sprint are off, and if so that a backup will be available (eg. that the second [firefighter](#firefighter)
274
      will be present, or that a third firefighter has been assigned on those days).
275
276
277
278
279
280
* Assigning the rotations. How to assign the rotation hours within the cell are up to that cell,
  as long as the number of hours matches a % of the total hours of work in the cell. The hours
  can be adjusted slightly if more or less firefighting is required:
    * Firefighting budget: 7.5% (30h/week for 10 full times, split between two firefighters each sprint)
    * Discovery budget: 2.5% (10h/week for 10 full times) - The discovery budget and the discovery duty allocation are two different things. The weekly discovery duty allocation (5h/cell/week) is to be used for new tasks that pop-up in the course of a sprint - it is funded by the discovery budget. Any leftover discovery budget can be used for discovery tasks that are planned in advance.
* Handling the delivery to the client and the verification of the tasks by the clients.
281
* Check the [spillovers spreadsheet](https://docs.google.com/spreadsheets/d/1aJD-e2NkDsyBq_yBHykGiMYE29FvSOuYSCZjOJ5sjkM/edit#gid=0&fvid=787610946) for your cell contains explanations for all the spillovers listed in the previous sprint. It is updated by [Sprints](https://sprints.opencraft.com) at the end of each sprint.
282
283
* Review of sprint deliveries: Move tasks from "Deployed & Delivered" to "Done", after double-checking that all [the criteria for calling it "Done"](task_workflows.md#done) have been met.
* Check the update to the [sprint commitments spreadsheet](https://docs.google.com/spreadsheets/d/1aJD-e2NkDsyBq_yBHykGiMYE29FvSOuYSCZjOJ5sjkM/edit) at the end of each sprint.
284
* Check that [firefighters](#firefighter) are doing their part of work about the [community relations](#community-relations)
285
286
* Create the Sprint Retrospective forum post/poll and create new entries in the retrospective spreadsheet for the new sprint.
* For cells, such as the business cell, which don't have an asynchronous planning session, the Sprint Manager leads the sprint planning meeting.
287

288
#### Cell epic planning manager
289

290
* Understand the lifecycle of en epic:
291
292
293
294
295
    1. Most epics start with a discovery based on a client requirement.
       (For internal projects, the client is OpenCraft).
    1. An epic is created based on the corresponding discovery and starts in the "Prospect"
       column.
    1. The discovery and corresponding estimates are shared with the client, and the epic is
296
       moved to "Offer / Waiting on client".
297
298
299
300
301
    1. If the client accepts the work, the epic is moved to "Accepted".
    1. Once actual development starts, the epic is moved to "In Development".
    1. Once the client's requirements are met, and the client has access to the
       completed work, the epic can be moved to "Delivered to client / QA".
    1. The epic should be moved back from "Delivered to client/ QA" to "In
302
303
       Development" if the client requests additional work or modifications
       that need development.
304
305
306
    1. When all the work in the epic is complete (for instance if all upstream PRs
       have been reviewed and merged) the epic can be moved to "Done".
* Recurring epics are generally not based on a project or discovery, but are used
307
  to track work for different cell roles.
308
* Each cell has its own Epics board and epics, and is responsible for ensuring
309
310
311
312
  that the projects those epics represent are being properly delivered based on
  the above lifecycle.
* Every sprint, during the first week, you should evaluate the changes in status
  of epics over the past sprint. This will involve ensuring that:
313
314
315
316
317
318
319
320
321
322
323
324
325
326
    * Each epic has an epic update.
    * Delivered epics are moved to "Delivered to client / QA".
    * Completed epics are moved to "Done".
    * Blocked epics are moved to "Offer / Waiting on client".
* Generally, moving an epic from "Prospect" to "Offer / Waiting on client" or to
  "Accepted" isn't controversial. As described above, there are clear steps
  that trigger each of those transitions. In case of any doubt about the correct status
  for an epic leave a comment on the epic.
* Every sprint, compare the Epics board for your cell
  ([Bebop](https://tasks.opencraft.com/secure/RapidBoard.jspa?rapidView=28&useStoredSettings=true),
  [Serenity](https://tasks.opencraft.com/secure/RapidBoard.jspa?rapidView=27&useStoredSettings=true))
  with the corresponding sheet(s) of the
  [epic planning spreadsheet](https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit).
  Ensure delivery and bugfix deadlines for individual epics are on target.
327
  Comment directly on the spreadsheet.
328
329
330
* When an epic is completed, make sure that it is correctly reflected in the
  "Time / Estimates" sheet of the Epic Planning spreadsheet.
* Maintain a count of the amount of time required to complete the accepted
331
  budgets over the next months in the epic planning spreadsheet
332
  for your cell. This is used to [inform recruitment needs](https://handbook.opencraft.com/en/latest/processes/#launch-of-a-recruitment-round).
333
334
335
336
337
* 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
  [Price list](https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit#gid=1171479307)
  sheet of the epic planning spreadsheet.
338
* Keep a look out for newcomers and core members joining or leaving the team,
339
340
341
342
343
344
345
346
  and add their details to the epic planning spreadsheet.
    * For newcomers this includes adding onboarding time to the onboarding section
      and specifying (or updating) their availability in the availability section.
      *Only make these updates when the corresponding information is fully public,
      i.e., the newcomer should know whether they have been accepted or not
      by the time these updates are made.*
    * For core team members leaving the team, make sure to reset their availability
      for the remaining months of the year.
347
* Handle requests from cell members to change their weekly hourly commitment, when the requested time is in the range 30-40h/week:
348
  * Outside of that range, refer to the CEO - we generally avoid it as it prevents from taking some tasks and increases overhead of lower numbers, and can lead to burnout for higher numbers.
349
350
  * If you need time to implement the change, for example to finish a recruitment, don't hesitate to discuss a specific date at which to make the change. Generally we would always agree to those requests, but not necessarily to implement it immediately.
  * To implement the change:
351
     * Update the [epic planning spreadsheet](https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit) accordingly to take it into account for epic planning. (Note: Availability for each member is calculated in full time weeks, i.e. 1 == 40h)
352
     * Update the team member's hours by via the Tempo menu -> Administration -> [Workload schemes](https://tasks.opencraft.com/secure/TempoSchemeWorkload!default.jspa). Locate the team member's current workload scheme (e.g. 35h), and click "Members". Click "Move" to move the team member to the new workload schem (e.g. 30h).
353
* Once per sprint, during the first week, post an epic update in the "Epic
354
  Planning - \<CellName>" epic with the following checklist:
355

356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
```text
h4. Epic planning update (Sprint ???)

* ( ) Make sure all epics have epic updates.
* ( ) If an epic's status has changed make sure it has the correct status on the Epics board. Most importantly:
** ( ) If an epic has been completed, move it to "Done".
** ( ) If an epic has become permanently blocked on the client, move it to "Offer / Waiting on client".
* ( ) Compare the Epics board with the epic planning spreadsheet.
* ( ) Add/Update details in the "Time / Estimates" sheet of the epic planning spreadsheet:
** ( ) For [new epics|https://tasks.opencraft.com/browse/SE-1615?jql=issuetype = Epic AND status in (Backlog, Offer, Accepted, "In development")] (i.e., epics with a status of "Prospect", "Offer / Waiting on client", "Accepted", or "In development").
** ( ) For [completed epics|https://tasks.opencraft.com/browse/SE-999?jql=issuetype = Epic AND status in (Done, Archived)] (i.e., epics with a status of "Done" or "Archived").
** Note that you can filter the list of new/completed epics down to epics from your cell via the "Project" filter.
* ( ) For in-progress epics:
** ( ) Evaluate the amount of time required to complete the accepted budgets over the next months and update the epic planning spreadsheet.
** ( ) Ensure delivery and bugfix deadlines of individual epics are on target (or are being actively discussed on the epics). Comment directly on the epic planning spreadsheet, pinging epic owners as necessary.
** ( ) Ensure the projects from your cell's clients are being properly delivered using the epic management process.
* ( ) For completed discoveries, see if any estimates can be useful more broadly and add them to the "Price list" sheet of the epic planning spreadsheet.
373
* ( ) Check the calendar and/or the [Looking for mentors|https://forum.opencraft.com/t/looking-for-mentors/131] thread for people joining/leaving the team in the next couple months and update the epic planning spreadsheet as necessary:
374
375
376
377
378
379
380
381
382
383
384
385
** ( ) For people joining the team, add availability and onboarding hours for the coming months.
** ( ) For people leaving the team, update their availability for the coming months. If prompted by your cell's sprint manager, help find new owners for clients and epics belonging to the people leaving.
* ( ) Check the calendar for vacations coming up in the next couple months. If someone will be away for a total of 1 week (or longer), [post a comment mentioning their availability|https://gitlab.com/opencraft/documentation/public/merge_requests/99#note_198626533] in the epic planning spreadsheet.
* ( ) Check the descriptions of the Hosted Sites Maintenance and Small Projects & Customizations epics (SE-1690, SE-1693) and update the list of clients for your cell, following the existing format.
** ( ) Add info about new clients that we recently on-boarded. (Make sure to skip clients that haven't moved past the prospect stage.)
** ( ) Remove info about clients that we no longer work with. (Make sure they have been off-boarded completely before doing this.)
* ( ) Adjust client budgets for sustainability dashboard as necessary.

h4. Notes

...
```
386

387
#### Cell sustainability manager
388
389
390
391
392
393
394
395

* Each cell is meant to be a sustainable entity by itself: its members are the closest to
  most of the work that impacts its sustainability: the successful estimation and delivery of
  each client project.
* Some of the budgets for internal/non-billed accounts are also decentralized to individual cells.
  See [cell budgets](cell_budgets.md).
* The sustainability role is responsible for ensuring the cell keeps the budgets it is responsible
  for in order.
396
397
398
399
400
401
402
* **Reporting**. Every 3 months, the sustainability manager posts an update on the forum about the
  current status of the cell's sustainability budget and ratio, as well as plans for the next months
  that ensures sustainable ratios. This is done in January (winter update), April (spring update),
  July (summer update), October (autumn update).
* **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.
403
* **Next sprint's sustainability prediction**. When [planning the next sprint](https://handbook.opencraft.com/en/latest/processes/#planning-agenda),
404
405
406
407
408
409
410
411
412
413
414
  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
  manager will get a timeline and plan from the concerned epic owners to resolve the issue. The
  "budget" section of the Sprints dashboard includes "Left this sprint", "Next sprint" and
  "Remaining for next sprint" columns that can be used to estimate next sprint's sustainability.
* **Previous month's accounts review**. Shortly after the end of each month, the sustainability
  manager will review that the tasks worked on during that month are using the right account. In
  particular, incidents that have affected client instances should use the client's "Instance
  maintenance" account instead of an internal devops account. This review needs to happen before
  invoices are sent to clients.
415

416
[epic planning spreadsheet]: https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit#gid=849132736
417

418
#### Cell manager - Cell split
419
420
421
422
423
424
425
426
427
428
429

A temporary role to manage a cell split.

* Create the cell split epic and forum thread
* Manage the epic and the split

[Google Sheet template](https://docs.google.com/spreadsheets/u/0/?ftv=1&tgif=d).

There are the steps that need to be done for a cell split:

* Update the handbook to add the new cell
430
    * [Cells](cells.md#cells) handbook page
431
* Create the new forum group with the new members so that we can use the `@falcon` mention
432
433
    * [Falcon forum group](https://forum.opencraft.com/g/falcon)
    * This cannot be done by an admin, ask Xavier
434
435
* Create the [retrospective](https://forum.opencraft.com/t/sprint-retrospective-falcon/764) and [sprint updates](https://forum.opencraft.com/t/sprint-updates-falcon/763/9) threads in the forum
* Create the new [Jira team](https://tasks.opencraft.com/projects/FAL/)
436
437
    * Also known as "Project"
    * This should be done by Xavier
438
* Create the new Jira sprint and epics dashboards
439
440
441
    * Should be done by Xavier or with the [crafty](https://vault.opencraft.com:8200/ui/vault/secrets/secret/show/core/OpenCraft%20Tools%20:%20Resources%20:%20Jira%20-%20crafty%20bot%20account) user
    * [Falcon Epics Dashboard](https://tasks.opencraft.com/secure/RapidBoard.jspa?rapidView=50)
    * [Falcon Issues Dashboard](https://tasks.opencraft.com/secure/RapidBoard.jspa?rapidView=45)
442
* Assign the new clients and services accounts to the new cell on Jira
443
    * Should be done by Xavier or the Administrative Specialist
444
* Update Jira Tempo accounts
445
    * Should be done by Xavier or the Administrative Specialist
446
* Create current sprint and next one
447
    * Even if the current sprint will be empty this is needed for the Sprints app
448
* Create the Firefighting epic and issues
449
450
451
    * Falcon Firefighting epic: [FA-1](https://tasks.opencraft.com/browse/FAL-1)
    * Create two current sprint firefighting tickets (those may not be used)
    * Create two other firefighting for the next sprint
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
* Update epics project ownership
    * Epics move to the new cell with their owner.
    * Example of request to move Serenity epics owned by Falcon user to Falcon project: [Jira query](https://tasks.opencraft.com/browse/SE-250?jql=project%20%3D%20SE%20AND%20issuetype%20%3D%20Epic%20AND%20status%20in%20(%22In%20progress%22%2C%20Backlog%2C%20%22Need%20Review%22%2C%20Recurring%2C%20%22External%20Review%20%2F%20Blocker%22%2C%20Merged%2C%20%22Deployed%20%26%20Delivered%22%2C%20Accepted%2C%20%22In%20development%22%2C%20Offer)%20AND%20assignee%20in%20(membersOf(Falcon)))
    * For all epics that are still in progress, make sure that the owner and the reviewer belong to the same cell (this does not apply to cross-cell projects) - find new reviewers when necessary
* Move all past, present, and current tickets that belong to accounts owned by the new cell to the new cell
    * This is required in order to be able to correctly keep track of new cell's budgets and sustainability
    * Note that moving a ticket that is assigned to a person that's not a member of the new cell to the new cell will automatically unassign the owner since Jira enforces that the ticket owner is a member of the project (cell) that the ticket belongs to - that is an unfortunate side-effect, but the benefit of keeping the accounts clean is more important and it should always be possible to infer the previous owner from ticket comments and/or worklogs anyway
    * Search for all billable accounts that were moved to the new cell: [Jira query](https://tasks.opencraft.com/secure/TempoAccounts!default.jspa#query/category=2&status=OPEN&project=11800) - this query also returns accounts owned by multiple cells, you should ignore those
    * Run a query to find all tickets for each billable account that was moved to the new cell: [Jira query](https://tasks.opencraft.com/issues/?filter=-4&jql=project%20%3D%20FAL%20AND%20Account%20%3D%2026%20order%20by%20created%20DESC)
    * Use the "Bulk Change" tool under "Tools" in the top right part of the screen to move tickets in bulk
    * If a task that you want to move is a subtask of a task that belongs to an account from a different cell, the bulk tool will refuse to move it. A solution in that case is to convert the subtask to a proper ticket before moving
* Ensure that the accounts in the sprints app reflect the changes
    * The budget dashboard in the sprints app is heavily cached, so make sure to clear the cache before doing any checks: [How to clear the cache](https://tasks.opencraft.com/browse/FAL-743?focusedCommentId=189959&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-189959)
    * Go to the new cell's board in the sprints app and check the budgets for the past two years. Ensure that only the accounts owned by the new cell show up under the "Budgets" section and that the numbers look correct.
    * Do the same check on the old cell's board. Ensure that none of the accounts that were moved to the new cell show up under the "Budgets" section - if they do, double check that you've moved all the tickets and cleared the sprints' app cache.
467
* Start the current sprint
468
    * This won't be possible if the current sprint is already started. In that case, Sprints dashboard won't be available until the next sprint
469
* Create the retrospective preparation ticket ([FAL-8](https://tasks.opencraft.com/browse/FAL-8))
470
471
* Move current sprint's tickets to the new cell's sprint
    * Example of request to move Serenity tickets from current sprint to the Falcon current sprint: [Jira query](https://tasks.opencraft.com/issues/?jql=project%20%3D%20SE%20AND%20Sprint%20%3D%20368%20AND%20assignee%20in%20(membersOf(Falcon)))
472
473
    * Repeat the process for any future sprints in case any tickets were already scheduled
    * Repeat the process for `Stretch goals`
474
* Create the new Google Calendar and add both service accounts
475
476
    * `calendar@sprints-dev.iam.gserviceaccount.com`
    * `sprints@sprints-242609.iam.gserviceaccount.com`
477
478
* Create the new Mattermost channel ([Falcon channel](https://chat.opencraft.com/opencraft/channels/falcon))
* Update the rotation and spillovers spreadsheets
479
480
    * Create two new sheets on this [Google Sheet](https://docs.google.com/spreadsheets/d/1aJD-e2NkDsyBq_yBHykGiMYE29FvSOuYSCZjOJ5sjkM/edit#gid=0&fvid=787610946)
    * `Falcon Spillovers` and `Falcon Commitments`
481
* Update Jira scripts and rollout a new version
482
483
    * Previous Falcon [merge request](https://gitlab.com/opencraft/dev/jira-scripts/-/merge_requests/20)
    * Get it merged and then ask Braden to deploy them on the Jira server
484
* Update Mattermost to handle ticket links
485
    * Falcon [pull request](https://github.com/open-craft/ansible-secrets/pull/228)
486
* Update Jira quick filters of the original cell to remove former members
487
488
489
490
491
* Add the new Cell's name and its abbreviation (used in Jira) to [Crafty](http://crafty.opencraft.com/)
    * Lookup the admin access details in Vault
* Connect the Cell's (automatically created) Sprint evaluation and board with the Cell's (automatically created) Sprint retrospective board on [opencraft.monday.com](https://opencraft.monday.com) by setting an "automation" on Sprint evaluation board as "When an item is created in this board, create an item in Sprint retrospective and connect them in the selected board". Ensure the "Sprint retrospective" part of the sentence points to the corresponding board as the default is the template which is used to clone the board.
    * Change the "Column Setting" for the linked column, to point to the same board specified in the Automation you set
    * Do a test evaluation form submission and validate it arrives to the retrospective board (almost immediately)
492

493
### Code reviewer
494
495
496
497
498

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
499
  *PR expectations* part of the [pull request process](processes/pull_request.md)
500
  section - if not, I will ask them to fix that before I start the review.
Kshitij Sobti's avatar
Kshitij Sobti committed
501
* (When reviewing non-OpenCraft work): If I get pinged to review a PR, I will
502
503
504
  respond to it within 24 hours. If it is for a ticket in the current sprint, I
  will ensure that I review it within 24 hours, or at least indicate to the
  author when they can expect a review.
Kshitij Sobti's avatar
Kshitij Sobti committed
505
506
* I will aim to minimize review cycles (especially when reviewing non-OpenCraft
  PRs) by leaving as complete a review as possible. Ideally it should point
507
  authors to the exact changes needed for their PR to be accepted.
508
509
510
511
* When reviewing work (or discussing it with the assignee before coding even
  begins), I will make sure that the assignee is not introducing code drift,
  i.e. that everything which could be upstreamed is (planned to be) upstreamed
  as part of the work.
512
513
514
515
516
517
518
* I will always read through the code diff, considering things like:
    * Is the code easily understandable by humans?
    * Is the code of high quality?
    * Are all relevant coding standards followed?
    * Are all UX / a11y / i18n considerations addressed?
    * Is this introducing tech debt?
    * Is the new code well covered by tests?
519
* I will always test the code manually, either locally or on a sandbox, unless there is no
520
521
522
523
524
525
526
527
528
529
530
  reasonable way to do so.
* I will always check if any updates to the software's documentation are required,
  and either ask the author to update the docs, or ensure the relevant documentation team is pinged.
* If there is any part of the code that I am not confident in reviewing,
  I will indicate that in my comments.
* If there is any part of the code or PR that I particularly like, I will say so - we want to reinforce
  good practice as well as flagging issues.
* I will
  [set up the following template as a "Saved Reply" in GitHub](https://github.com/settings/replies)
  and use it for the "stamp of approval" on all PRs I review:

531
532
```markdown
:+1:
533

534
535
536
537
538
539
- [ ] I tested this: (describe what you tested)
- [ ] I read through the code
- [ ] I checked for accessibility issues
- [ ] Includes documentation
- [ ] I made sure any change in configuration variables is reflected in the corresponding client's `configuration-secure` repository.
```
540

541
542
543
  Here is a screenshot showing how to conveniently access this template
  when completing a code review using the dropdown button in the top right
  of the review panel (on the "Conversation" tab only):
544

545
  ![Review template](images/review-template.png)
546

547
548
549
* If I'm the assigned reviewer for someone who is new to OpenCraft,
  I will reserve extra time to provide additional mentoring and support,
  and I will be especially responsive to questions.
550
551
552
  I will also provide feedback to the newcomer which will assist them during their trial period, and raise any major
  issues with their mentor.
* If the assignee is clearly behind the schedule and doesn't respond at all to pings on the ticket or Mattermost within
553
554
  48 hours, the code reviewer should determine whether this ticket is urgent. If it is, ask the
  [firefighter](#firefighter) for help to reduce the risk of spillover.
555

556
### Newcomer
557
558
559

If I'm **new to the team**, I will:

560
561
562
563
* Not commit to more than [3 story points](task_workflows.md#general-tasks) of tasks during my first week, or 5 points
  my second week (so no more than a total of 8 points for the first sprint).  It's really easy to over-commit at first,
  so keep your commitments manageable. You can always take on more work later in the sprint if you finish early.
* Discuss general issues like time management and sprint planning with my mentor.
564
* I'll prepare for every 121 with my mentor based on the [newcomer 121 checklist](#newcomer-121-checklist)
565
* Tag my task reviewer(s) with task-specific questions on the ticket, or if I'm completely blocked, try using
566
  Mattermost to contact my [reviewer](#code-reviewer), [mentor](#mentor), [sprint firefighter](#firefighter), or other people working on the same project.
567
  Reviewers have time allocated to help during Onboarding, so it's ok to reach out!
568
* Ask my Reviewer questions **early in the sprint** if there is missing information or if the requirements are unclear.
569
  [Newcomer-friendly tasks](task_workflows.md#newcomer-friendly-tasks) have a minimum set of information that should be included in the
570
  task description, but if this isn't complete, ask the task creator and/or your reviewer to do it.
571
572
* Provide lots of updates to my assigned reviewer/mentor for each task,
  so they can provide timely help.
573
574
575
576
577
578
* Assign myself as [reviewer](#code-reviewer) for core team member tasks to learn about the various projects and systems
  that we support.
* Log time spent "onboarding" (reading documentation, learning new systems, setting up devstacks) to my onboarding task.
  Time spent completing the work described in a task can be logged to the task itself, but please take care not to
  exceed the estimated time without **approval from the owner of the parent epic**.  Some leeway will likely exist
  within the epic budget, but it's best to check to be sure.
579

580
581
582
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.

583
See the [Process: Onboarding & Evaluation](processes/recruitment.md) page for more advice on the onboarding, the evaluation
584
585
process and criteria.

586
587
588
589
590
591
592
593
594
595
#### Newcomer 121 checklist

* Ask my reviewers for feedback in the ticket's comments once it's moved to the "Deployed & Delivered" status
* Review feedbacks received on tickets
* Review tickets assigned to me for the next sprint
* Review my onboarding budget
* Ask for feedback about my strengths and the areas I can improve in
* Check if any upcoming tickets lie in the areas I need to improve in, so I can showcase my progress
* Collect issues/blockers to discuss with my mentor

596
#### Onboarding epic ownership
597
598

As a newcomers, I am the owner of my onboarding project, and will:
599

600
* Keep time spent by me and my mentor on the onboarding epic to less than 80 hours for the initial 2 month trial period, and less than 130h over the whole trial period in case of extensions.
Jillian Vogel's avatar
Jillian Vogel committed
601

602
* The remaining hours of my onboarding budget must be preserved for the core team reviews, and/or onboarding time once accepted to the core team, for a maximum total of 195h.
603

604
605
606
  Expect around 15 hours to be spent by the core team on the screening and end-of-trial reviews during the initial 2 month
  trial period.  For example, if the screening review requires 2 hours and the end of trial review requires 2 hours for
  each core team member and there are 6 of them, 14 hours (2 + 6*2) is required for those activities.
Jillian Vogel's avatar
Jillian Vogel committed
607

608
* Treat my onboarding epic as a proper epic and manage it like an [epic owner](#epic-owner).
609

610
611
  The epic and the budget also includes my onboarding ticket, my mentor's mentoring ticket and any other tickets created
  specifically for my onboarding like the ones for my screening review and the end-of-trial review.
612

613
614
  In the onboarding epic task, there is a `Summary Panel` section on the right side, which shows various details about
  the budget, logged and available time etc. See the below screenshot for an example.
615

616
  ![Summary Panel](./images/epic_summary_panel.png)
617

618
  Hover over the Time numbers below the progress bar to see an explanation.
Jillian Vogel's avatar
Jillian Vogel committed
619

620
621
* I will create tasks under this epic for distinct pieces of work, set estimates and schedule them with the help of my
  mentor.
622

623
624
  This will help us to track if a particular onboarding/learning task is taking too much time. Since the onboarding
  budget is limited, all the learning time I log on the onboarding epic will be related to the tasks that I work on.
Jillian Vogel's avatar
Jillian Vogel committed
625

626
627
628
629
630
631
632
633
* Log my time with detailed descriptions about the work performed.  For example:

    "Reviewed task and asked questions on ticket, requested repo access, started setting up devstack."

    Or as an example where logging "onboarding" time spent on another task on my onboarding ticket:

    "Onboarding for SE-123: read XBlock Tutorial and configured XBlocks in my devstack"

634
### Mentor
Paulo Viadanna's avatar
Paulo Viadanna committed
635

Paulo Viadanna's avatar
Paulo Viadanna committed
636
* I will make sure to inform the team I'll mentor a newcomer before their first day.
637
* I will familiarize myself with the current [onboarding & evaluation process](processes/recruitment.md), so I can
638
  answer questions and help the newcomer through the process.
639
* I will allocate sufficient time in my sprint, especially at the beginning, to assist and mentor the newcomer.
640
* 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).
641
642
* 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
643
  [the mentor checklists page](https://handbook.opencraft.com/en/latest/roles/#mentor-checklists) for the topics to go through.
644
* For the first 121 with the newcomer, I'll prepare a few interview questions to help in the screening process.
645
* During every 121 with the newcomer, I'll go through the [mentoring 121 checklist](#mentor-121-checklist) checklist
646
* I will participate on the screening and developer review tasks, taking into account these
647
  [evaluation criteria](https://handbook.opencraft.com/en/latest/processes/#evaluation-criteria).
648
649
650
651
652
653
* 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.
* I will also explain to the newcomer, the guidelines to manage the onboarding epic and its budget like
  any other epic that we work on and point them to the relevant items in the [newcomer](#newcomer) section.

654
655
656
657
658
659
660
661
662
663
664
#### Mentor 121 checklist

* Review the work done by the newcomer since the past mentoring session in prior to the meeting
* Review the onboarding budget status
* Provide feedback about strengths
* Provide feedback about areas of improvement, and suggest methods for improvement
* Review tickets assigned to the newcomer for the upcoming sprint
* Help find tickets for the upcoming sprint if needed
* Discuss current issues/blockers if there are any
* Ask for feedback about the processes and the ease of onboarding; if an issue comes up, open a [GitLab issue](https://gitlab.com/opencraft/documentation/public/-/issues)

665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
#### How to select tasks for new members

Selecting the right tasks for the trail period is very important. The goals are:

* In the first 2 weeks when the new member is trying to understand the different stacks they will need easier tasks to start with.
* From the second sprint they should be picking up at least a couple of moderately complex (5 points) tasks.
* By the end of the trial period there should be sufficient number of (5+) complex tasks to showcase the new member's skills and learning abilities.
* There should be variety in the tasks to allow evaluation for the different types of skills. It is particularly
  important to have 3-4 reasonably complex dev tasks (historically this has been a weak point) and 2+ ops tasks.
* While lines of code is not a measure of complexity having 2-3 thousand lines of code makes it much easier for reviewers to do their evaluation.

* Before the new member's first day they should be assigned a 2 or 3 point task from one of the main projects of the cell. This will allow them to get familiar with the relevant project and be able to pick up more complex tasks in the next sprints.
* The backlog of [Newcomer-friendly tasks](task_workflows.md#newcomer-friendly-tasks) is a good place to look at first.
* If newcomer-friendly tasks are not available in the backlog, ping the main epic owners of the cell on the onboarding epic asking them if they can prepare suitable tasks. Remind them if needed.
* The evaluation of a new member's skills is incredibly important so feel free to take tasks assigned to any other team member and re-assign them to the new member (unless it looks urgent or has a tight budget).
* If none of the above work can create tasks from the [INCR project](https://openedx.atlassian.net/projects/INCR/issues/INCR-4?filter=allopenissues) (preferable) or [Byte-Sized Bugs](https://openedx.atlassian.net/browse/TNL-5801?filter=12810) upstream boards.
* It is okay to assign very small discoveries, which do not result in a standalone epic. (See [Newcomer-friendly tasks discussion](https://forum.opencraft.com/t/newcomer-friendly-tasks/318))
* Tasks which require access to production systems are not recommended for new members. If a task requires deployment, one option is that the reviewer does the deployment, but lets the newcomer know what they’re doing at each step, to help them learn for the future. Any additional access granted needs to be documented in the Onboarding checklist and accesses granted document on their onboarding epic so they may be rotated in case the new member does not make it to the core team.
* During each sprint planning remember the tasks complexity and variety goals.
* If none of the above work, escalate the issue to the [recruitment manager](#cell-recruitment-manager).

* If the new member does not make it to the core and it is their last sprint it is definitely better to assign them tasks that they might be able to complete without wasting budget hours, even if it's from the onboarding budget, but if this type of task isn't available, we can then focus on giving them tasks that aren't urgent, ie that can be rescheduled for the following sprint when they leave, to limit the impact on the rest of the team.

688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
#### Mentor checklists

##### Week before

The week before the newcomer first day, the mentor is tasked with finding or creating a meaningful task for the first sprint.

We must ensure the newcomer has a task with enough complexity in his first sprint for a screening review. While this task won't be enough to evaluate the all the different abilities required such as frontend, backend, devops, epic management etc, it should be complex enough to show the newcomer can work independently and deal with technologies we use on our day-to-day.

The newcomer should create a PR as soon as possible and push to it daily, at least, so we can better help when stuck and review the work progress.

One example of such task is one fixing a bug in the master branch of edx-platform. It involves reading and understanding code, provisioning the master devstack, running tests, creating a PR and discussing with the reviewer.

We might not have such a task in our Backlog, so make sure to ping epic owners if you can't find one. The [INCR](https://openedx.atlassian.net/projects/INCR/issues) and [CRI](https://openedx.atlassian.net/projects/CRI/issues) upstream projects are excellent sources of tasks as well.

##### Initial 121

This meeting objective is to get the mentor to know better about the newcomer capabilities and help in the screening process. Here are some example questions to help with that:

* Are you comfortable working in a POSIX environment?
* Do you have experience coding in Python? How many years?
* What is your skill level in frontend development? Do you have experience with any frameworks?
* How do you feel working 100% remotely? Is this your first experience?

##### Weekly 121s

These meetings will be used mostly for answer questions, both technical or related to OpenCraft processes.

* Evaluate the newcomer's current sprint and tasks currently at risk of spilling over.
At-risk tasks should be flagged with the sprint firefighter, to avoid missing delivery deadlines.
* Help the newcomer prioritize work and check if there are any difficulties working remotely.
* Provide feedback, both on technical and other skills such as communication, time management etc. This feedback may come from other team members, or from my observations on the newcomer's assigned tasks.
* Help the newcomer use accurate task statuses during their sprints to ensure the Sprint Commitments spreadsheet for
their cell is accurate when it comes time to do the developer review. If there are any issues with what is recorded
there, let the [Sprint manager for your cell](cells.md) know.

723
### Firefighter
724

Kshitij Sobti's avatar
Kshitij Sobti committed
725
726
727
728
There are two firefighters per cell for each sprint and they are designated as Firefighter 1 and 2.
Besides minor differences who leads which sprint meeting, these roles have exactly the same
responsibilities.

729
730
As a **sprint firefighter**:

Xavier Antoviaque's avatar
Xavier Antoviaque committed
731
* I will keep at least 15 hours of time for sprint firefighter duties as
732
  described below, and will proactively pursue those duties.
733
* I will assign tasks for the rest of my sprint hours normally, but I will also ensure a few additional tasks
Xavier Antoviaque's avatar
Xavier Antoviaque committed
734
  are left either in the "stretch goals" or the following sprint during sprint planning, in case there
Xavier Antoviaque's avatar
Xavier Antoviaque committed
735
  isn't enough firefighting work to fill my hours. I will only pull these tasks into the current sprint
Xavier Antoviaque's avatar
Xavier Antoviaque committed
736
737
  if I am confident that I will have time to finish them in addition to the firefighting. These tasks
  should be assigned to me and have a reviewer, to be ready to pull in.
Paulo Viadanna's avatar
Paulo Viadanna committed
738
* I will not record any time on the Sprint Firefighter
739
740
  task directly (always use a dedicated client story/bug/epic ticket).
* I will be subscribed to the
741
  [help](https://mail.opencraft.com/postorius/lists/help.opencraft.com/)
742
  and
743
  [urgent](https://mail.opencraft.com/postorius/lists/urgent.opencraft.com/)
744
745
746
747
  mailing lists (be sure to filter them to a separate folder
  to look at them only when you need to - but also make sure
  that if any such emails also explicitly include you in the To/CC,
  then they will arrive in your inbox).
748
* I will [add myself to the pager rotation](https://courses.opencraft.com/courses/course-v1:OpenCraft+onboarding+course/jump_to/block-v1:OpenCraft+onboarding+course+type@vertical+block@first_steps_as_a_core_team_member_firefighting_pager_setup), at least during my work hours the weeks
749
  I am firefighter, plus any additional time I optionally want to help cover.
750
751
752
753
* I will work on the following, listed by decreasing priority:
    * Handle emergencies from other team members
      (reported by team members directly to me or to the other sprint
      firefighter, with Braden arbitrating priorities)
754
    * Handle emergencies reported by clients from the cell--these will come in through the
755
      help@opencraft.com mailing list, which everyone receives.
756
757
      Firefighters triage and prioritize these issues, asking other cell members for advice
      as needed, and escalating to Braden/Xavier if everything else fails.
758
759
    * Handle critical bugs reported by QA
    * Deploying hotfixes/security fixes on client instances
760
761
    * Follow up on issues affecting [periodic build](https://manage.opencraft.com/admin/instance/openedxinstance/?q=periodic+build) instances
      as necessary (when prompted by the team member responsible for [Community Liaison](#community-liaison)).
762
763
764
765
766
767
768
769
770
771
    * Provide reviews for tasks that are missing a reviewer.
    * Complete any personal spillover from the previous sprint
    * Work on client requests that can't wait until the next sprint, in particular in
      the first week of a sprint.
    * Help ensuring a clean sprint by helping other team members, in particular in the
      second week of a sprint.
    * Being available on the Open edX Slack (#general), answering questions and
      responding to emergencies reported there (log time on OC-1017)
    * Watch over sandboxes (ie keep an eye on the instance manager
      on a regular basis, few times a day, to ensure they build correctly, and debugging if needed)
772
    * [Document incidents as they happen](https://forum.opencraft.com/t/learning-devops-refresher-tasks/472/23) and post
Tim Krones's avatar
Tim Krones committed
773
      a summary to the [OpenCraft Ops Review forum thread](https://forum.opencraft.com/t/opencraft-ops-review/533).
774

775
#### Dependency upgrades for security issues
776
777
778
779
780
781
782
783
784

  GitHub sends the security alerts by scanning (by default, all public repositories are scanned; for private repositories, the admins have to explicitly permit the scanning) the repository dependencies, and based on the severity levels:

  * `Critical and High level` severity vulnerabilities: As there could be a risk of compromise or significant downtime for users, these vulnerabilities must be patched as soon as possible. The FFs should create the tasks for applying the patch and start working on them right away.
  * `Medium level` severity vulnerabilities: Report them and create tasks for patching them so that team is aware of them. These tasks can be scheduled for the next sprint and if any of the FFs have time, they can work ahead on these tasks.
  * `Low level` severity vulnerabilities: These vulnerabilities should be reported and tasks for patching them created with a lower priority. These tasks can be scheduled for a future sprint and prioritized by the epic owner as appropriate.
  * `Undefined or unclear` severity: Vulnerabilities or security fixes whose severity is unknown should be reported and discussed with team before we can take any action.
  * `Dependabot PRs`: Dependabot PRs for bumping the version of vulnerable dependencies or security fixes should be handled by the FFs based on the process mentioned above for various severity levels.

785
  The severity level mentioned in a vulnerability report may not always match our own assessment (`critical issues` in a disabled feature may not be `critical`). Hence the processes around categorization of the security vulnerabilities and the assessment of their severity levels need to be expanded and improved over time.
786
787

* Work on additional tasks from the backlog if additional time is available
788
* Well before the sprint planning meeting at the start of a new sprint (every
789
790
  second Monday), I will remind the epic owners to get every ticket in the upcoming sprint
  "green" (has an assignee, reviewer, and points) by pinging people as needed,
791
792
793
  and I will help make sure all tickets are green before the start of the sprint planning meeting.
  If my timezone makes this challenging, I will coordinate with Firefighter 2 to finish up on Monday.
  The time spent getting a ticket to green will be logged on the ticket.
794
795
796
797
* If I am Firefighter 1, I will lead the sprint planning meeting at the start of
  the sprint. If I am Firefighter 2, I will take notes during this meeting. For the
  mid-sprint meeting these roles are reversed, Firefighter 2 will lead the meeting
  and Firefighter 1 will take notes.
798
799
800
801
802
* On Friday or Monday well before the mid-sprint meeting, I will do a sprint checkin
  on all "backlog" and "In progress" tickets (this means to post a comment
  on each ticket to ask how the assignee is doing and if they need help,
  and/or asking them to update the status of the ticket if it is not clear).

803
### Community Relations
804

805
806
807
808
One of OpenCraft's most important core values is community involvement.  To reflect this, three roles are defined. In
increasing order of time commitment per sprint, they are:

#### Community Support
Xavier Antoviaque's avatar
Xavier Antoviaque committed
809
810

 * Rotating role, assigned to two cell members each sprint.
811
812
813
814
815
816
817
818
819
820
 * Keep 1h/sprint for providing support to the Open edX community via the following channels:
     * Open edX [forum](https://discuss.openedx.org/)
     * Open edX [Slack](http://openedx.slack.com/), in particular the [#opencraft channel](https://openedx.slack.com/archives/C0F63UDL0)
     * OpenCraft's public repos ([GitHub](https://github.com/open-craft?q=&type=public&language=), [GitLab](https://gitlab.com/explore?sort=latest_activity_desc&visibility_level=20)):
         * [List of open issues](https://github.com/search?q=org:open-craft+is:public+is:issue+state:open) (GitHub)
         * [List of open PRs](https://github.com/search?q=org:open-craft+is:public+is:pr+state:open) (GitHub)
         * [List of open issues](https://gitlab.com/groups/opencraft/-/issues) (GitLab)
         * [List of open PRs](https://gitlab.com/groups/opencraft/-/merge_requests) (GitLab)
 * In general:
     * Monitor these channels for technical questions (e.g. about our XBlocks) and answer them.
821
822
823
824
825
       Generally favor helping one person more fully, over having many smaller contributions to more threads.  It should
       give a feeling of what a support task with a 1h timebox gives.  If it takes less than 1h to solve, you can help
       someone else with another problem with the remaining time.  But otherwise spend that time on a single
       question/issue - one that you think you can contribute something useful to many, or that you're especially suited
       for.
826
     * If you run out of time, simply stop answering - someone else from the community can take over.
827
     * If you think it would be helpful to go beyond 1h in some cases, check for a timebox extension with the [cell sustainability manager](#cell-sustainability-manager)
828
829
 * For Slack:
     * To make it easier to stay in the loop on what's happening there, consider changing your Slack settings for the #opencraft channel to "Notify on every message" while on rotation for this role.
830
     * If edX reports any urgent issues via the #opencraft channel, make sure that the [firefighters](#firefighter) are aware so these issues can be followed up on in a timely manner.
831
 * Time must be logged on a ticket dedicated to the role each week - see [SE-1567](https://tasks.opencraft.com/browse/SE-1567) or [BB-1692](https://tasks.opencraft.com/browse/BB-1692) for examples.
832

833
#### OSPR Liaison
Jillian Vogel's avatar
Jillian Vogel committed
834

835
836
This is a permanent role, assigned to one member of each cell.

Jillian Vogel's avatar
Jillian Vogel committed
837
838
839
840
841
* Keep 1h/week available to prioritize Open OSPRs for review by edX.
* Maintain the prioritized list in a document shared with the OSCM team:
  [OSPR priorities from OpenCraft](https://docs.google.com/document/d/1FigwxhOwBpt7B-d5IBBmkFIgBLZQDdgsX6LFWR_90Ew/edit?usp=sharing)
* Send the top 3 on the list to the edX OSCM team (usually Natalia) once a week.
* Log time on [SE-1631](https://tasks.opencraft.com/browse/SE-1631).
Kshitij Sobti's avatar
Kshitij Sobti committed
842
843
844
845
846
* Keeep 0.5hrs/week available to handle any PR sandbox requests by edX.
* Someone (likely [Ned](https://github.com/nedbat) or [Natalia](https://github.com/natabene)) will ping you on a PR targeting an older release branch (currently limited to Hawthorn and later).
* Make sure the PR has a reviewer assigned. If not, request that one be assigned before continuing with the next step.
* Create a new sandbox for the PR, and link the sandbox URLs to the PR.
  * To do this you can use the ``setup_pr_sandbox`` Ocim management command and provide it the URL of the edx-platform PR.
847
* In case there isn't sufficient time, create a ticket and ping the [firefighter](#firefighter) to do the actual sandbox creation steps.
Kshitij Sobti's avatar
Kshitij Sobti committed
848
* You can give SSH access to the reviewer by adding their GitHub ID to ``COMMON_USER_INFO`` in the PR sandbox's config:
849
850
851

```yaml
COMMON_USER_INFO:
Kshitij Sobti's avatar
Kshitij Sobti committed
852
853
854
  - github: true
    name: github_id
    type: admin
855
856
```

Kshitij Sobti's avatar
Kshitij Sobti committed
857
* You can ask the PR author to add the standard setting section to the PR description with the above config. Otherwise you may need to add this back each time the sandbox is updated from the PR.
Jillian Vogel's avatar
Jillian Vogel committed
858

859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
#### Official Forum Moderator

This is a permanent role, assigned to one member of each cell.

It isn't about knowing the answers to questions - though it never hurts, and you can also provide support at the same
time if it makes sense - but Ned defines it as "being involved with the forum in a way that makes it productive and
useful for people."

Specifically, when moderating the official forum the Official Forum Moderator will:

* Welcome new posters
* Help people use the forums well, including giving advice where applicable to:
    * Choose the right categories, and move/split/concatenate threads when needed.
    * Provide enough information about their situation - we can help them to refine their questions, asking them
      questions to make their requests more precise
    * Use existing resources or documentation
* Review posts flagged automatically by Discourse (for example, someone finishing a post too quickly after creating
  their account)
* Make sure "Open edX" is spelled (and capitalized) correctly in post titles. Don't bother with the body of posts, but
  the topic lists should show only show the correct usage.
* Set the right tone for discussions and, in general, be a model Open edX citizen

Moderation rights need to be requested from Ned Batchelder when starting on the role.

#### Community Liaison

This role involves the heaviest commitment of the Community Relations roles, at **8 hours a week**, and is meant to be
taken by a single person across all cells.

Work on the role is to be assigned by default to the "Community Relations" non-cell account, so as to alleviate the
budget burden on the Community Liaison's cell.  However, the following applies:

* Whenever possible the Liaison should assign individual tasks to other accounts, using the "Community Relations" only as a backup.
* The "Community Relations" account can only be used on tasks assigned to the Community Liaison themselves.  In other
  words, it should **not** be used for the [community support](#community-support) work ticket, or, for example, for
  other cell members to attend community meetings - these would still come from internal cell budgets.

The role has been historically held by Xavier, and its specification is derived from his original responsibilities:

##### General community relations

Tim Krones's avatar
Tim Krones committed
900
The Community Liaison will both engage in and help coordinate community-facing efforts in the company as needed, across
901
902
903
904
905
all contact points.  Specific duties include:

* Coordinating and serving as second reviewer on the other Community Relations roles
* Acting as an additional [official forum moderator](#official-forum-moderator)
* Monitoring OEPs, ADRs, and community discussions on forum, ensuring OpenCraft participates in relevant ones
906
907
908
* Keeping an eye on the [build-test-release CI notifications](https://groups.google.com/g/open-edx-btr-notifications),
  forwarding issues to firefighters as necessary, and ensuring we post replies on failures, either explaining them when
  we fixed or caused them, or otherwise asking for help to fix them.
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
* Ensuring that bug reports, PRs (see the list of repositories to watch in the [Community Support role description](#community-support)),
  and other communication directly submitted to us by the community gets a prompt answer and review.  "Prompt" is
  defined as:
    * **24 hours** for direct acknowledgement by the Liaison.  The Liaison should set up a communication filter so that they
      are immediately notified of incoming communication from the community (as opposed to OpenCraft's own chatter in
      PRs and issues.)
    * In case of a bug report or pull request, the Liaison will also create an internal task upon acknowledgement and
      set a deadline of **2 weeks** from creation for the team to review and, if possible, fix the bug or merge the PR.
      A firefighter will be assigned to the task upon creation so that work on it can start immediately.  (Yes, this
      should be treated as a fire: contributions are rare enough that it's worth acting quickly to encourage them.) If
      the task is complex or requires domain knowledge, the firefighter will do a first superficial pass immediately to
      show the contributor that we care, and then mention that another pass by someone else will need to happen, and
      when. Even in these cases, though, an early sprint deadline will be set for the review, and the assignee will be
      asked to remain reactive to subsequent updates and comments from the contributor.
* Making themselves available as an community reference ("Talk to Ned about this, Felipe about that") not only
  internally at OpenCraft, but also for the community itself.

##### Attending community meetups

Involvement is expected in the following community meetups as noted:

* [Biweekly Contributor's Meetup](https://discuss.openedx.org/t/open-edx-contributors-meetup/1450): organize the
    meeting, including scheduling it, announcing it in the forum, preparing the agenda, holding the meeting, and finally
    posting the recorded video.
* [Monthly Community Hangout](https://openedx.atlassian.net/wiki/spaces/COMM/pages/590184858/Online+Community+Meetups):
    in addition to attending the meeting itself, organize OpenCraft's participation, including suggesting topics and
    inviting members of the team to speak when the opportunity arises.

##### Community project management

The Community Liaison is expected to follow-up on and otherwise refine tasks (i.e., do project management for the
community) in the following boards.  This is not limited to tasks where OpenCraft is directly involved, but should also
include tasks created by or assigned to other community members:

* [Community working group board](https://trello.com/b/d8oWzNoy/community-working-group)
* [Core committer program board](https://github.com/orgs/edx/projects/1)

##### The Core Committer Program

The Community Liaison also takes ownership of the [core committer program epic](https://tasks.opencraft.com/browse/SE-2700).
If the Liaison is not yet a core commiter, they must work to become one, so that they can credibly help manage the program.

951
### Ops reviewer
952
953
954

1. Receive ops@opencraft.com and the pager alerts - check alerts/emails to ensure the alerts
   have been properly handled by the other recipients and nothing has slipped through.
955
1. Be a backup on the pager (alerts sent first to the other(s) recipient(s), but escalated if not
956
957
   acknowledged within 30 minutes).
1. If none of the other recipients are around and an issue is left unsolved, and it either is sent
958
   to urgent@, or was sent more than 12h ago to ops@opencraft.com and needs to handled
959
   quickly, warn the [sprint firefighter](#firefighter) about it: create a ticket about the issue and assign it.
960
961
962
963

Note that keeping an eye on [build-test-release CI notifications](https://groups.google.com/g/open-edx-btr-notifications)
triggered by periodic builds and following up as necessary is part of the [Community Liaison](#community-liaison) role,
and out of scope here.
964

965
### Discovery duty assignee
966
967
968
969
970
971
972
973

As the **week's discovery duty assignee**:

* I will make sure I am the right person to take on a specific discovery, if I feel I am not
  I will exchange work with other people from the sprint, to get someone else
  to do it, while I help them with their tasks. It is very important to be able to estimate a
  task well, we should make a conscious effort to assign the task to the person who can best
  handle it, if possible (if the person is available and willing to do the work).
974
* I will keep at least 5 hours of my time to do discovery work on any small leads/client
975
  requests that come up during the week. I may still plan some tasks to pull into the sprint
976
  if no fires pop up. Before pulling tasks in the sprint, I will use these hours to help others finishing
977
  their sprint commitments.
978
* If I do some discovery tasks, I will ping the [sprint firefighters](#firefighter) to review the result.
979
980
981
982
983
* As always, if I do the discovery, I understand that I would be expected to complete the epic
  work later on if the client accepts it.
  (To avoid people being forced to commit to being the owner of big epics, any
  huge discovery stories should always be scheduled into future sprints rather
  than directly assigned to the discovery duty assignee.)
984
985
* I will ensure an additional task is left either in the "stretch goals" or the following sprint
  during sprint planning, in case there isn't enough discovery duty work to fill my hours. I will
Xavier Antoviaque's avatar
Xavier Antoviaque committed
986
  only pull this task into the current sprint if I am confident that I will have time to finish it
987
988
  in addition to the discovery duty. This task should be assigned to me and have a reviewer, to
  be ready to pull in.
989

990
### Specialist roles
991
992
993
994
995

Specialists are people in the cell with more context and understanding about a certain topic, such as DevOps, Ocim, or Analytics/Insights.
The goal of having this role is to allow cells to self-sustain and run its own projects without being blocked on context from people from another cell.

While specialists have priority on taking tasks related to its specialty, there's no restriction on other team members and taking tasks is encouraged to spread knowledge around the cell.
996
Specialists should always be at least the 2nd reviewer so they are in a position to track the ticket and provide help.
997
998
999
1000
1001

Specialists are not only responsible for handling tasks within the cell, but also for coordinating with other specialists to discuss and schedule improvements when necessary.

The next sections cover specific tasks to be done by each type of specialist:

1002
#### DevOps Specialist
1003
1004
1005
1006
1007
1008
1009
1010

The specialist should always be involved in some way in the devops tasks of the cell, if not as the assignee, then as a reviewer or 2nd reviewer.

 They also have priority to take DevOps tasks as assignee as much as they want, they don't have to take everything (neither should they try), but they should be able to use the context of tasks, especially client tasks, to implement useful work for the infrastructure as a whole.

 Client owners are still responsible for handling DevOps tasks of their client's instance. The specialist should help, advise and review the tasks, while the epic/client owner creates the tasks and handles getting them assigned.

Responsibilities within its cell:
1011

1012
1013
1014
1015
1. Assign, take or review DevOps related tasks.
1. Support team members on DevOps related tasks, provide information about deployment mechanisms, sidecar services, and any particular detail that might affect the outcome of the task.

Responsibilities shared between DevOps specialists across cells:
1016

1017
1018
1019
1. Create tickets to maintain and update common server infrastructure and its related deployment mechanisms (MySQL, MongoDB, Consul, Vault, Prometheus, etc).
1. Create discovery tickets and epics to improve infrastructure, taking into account the current epic schedule and throughput available for non billable DevOps work.

1020
#### Technical Security Manager
1021
1022
1023
1024
1025
1026

* Responsible for the **technical security** of the work we do, our platform and OpenCraft as
  a whole.
* Responsible for **[OpenCraft's Security policy](http://opencraft.com/doc/handbook/security_policy/)**.
* **Offboarding** of team members who have left.

1027
### Epic owner
1028
1029
1030

As an **epic owner**:

1031
* I will make sure the epic has tasks with time estimates and a global budget. A discovery will likely be required for this - read the [estimates](how_to_do_estimates.md) section and follow the steps listed there.
1032
1033
1034
1035
1036
* I will ensure the "Timeline" section of the description and the epic due date
  are kept up to date. The "Timeline" section should include a list of
  milestones and deadlines for each (these milestones could be as simple as
  "check in with client"). The due date should be set to the closest
  deadline, and must be revised once each deadline is past/updated.
1037
1038
1039
1040
1041
1042
1043
1044
1045
* I will keep clients updated on the status of tickets
  (for clients with long term monthly contracts, this means updating
  their JIRA or Trello boards as work progresses).
* I will attend meetings with the client about the project as required,
  e.g. weekly scrum meetings.
  (We try to limit these sort of meetings to once a week per client at the most.)
* I will create tickets on OpenCraft's JIRA board for upcoming work,
  and place them into the appropriate upcoming sprints
  so that we can get the work done well ahead of applicable deadlines.
1046
1047
1048
    * If a ticket without point estimates is scheduled for the upcoming sprint,
      and an estimation session is open, I will make sure to add it to that session,
      so everyone on the team can help estimate it.
1049
* I will aim to split out any suitable newcomer-friendly work into separate tasks, flag them as
1050
  [Newcomer-friendly tasks](task_workflows.md#newcomer-friendly-tasks) in the Backlog, and ensure they contain the required information.
1051
  To guard the epic budget, "onboarding" time can be logged against the newcomer's epic.
1052
1053
1054
1055
1056
1057
* If applicable, I will create corresponding tickets on clients' JIRA or Trello boards
  and link to those tickets from the description of internal tickets as necessary.
  (In many cases, a single internal ticket from OpenCraft's JIRA
  will correspond to a single ticket from a client's JIRA or Trello board.
  But there are also cases where a single internal ticket might map to
  multiple external tickets or vice versa.)
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
* I will set the "Original Estimate" of each ticket to the number of hours
  listed in the discovery document. If a ticket covers a larger story
  from the discovery document only partially, I will set its "Original Estimate"
  to an appropriate fraction of the number of hours listed in the discovery document.
  For any ticket that does not directly correspond to a story from the discovery document,
  I will set the "Original Estimate" based on the amount of time that I think
  will be required to complete the work, taking into account the number of hours
  that remain in the epic's budget at that point in time.
* On Thursday in the second week of a sprint, I will post an epic update
  that answers these questions:

1069
1070
```text
h5. Epic Update (Sprint ???)
1071

1072
h6. What's the status of the hours budget for this epic?
1073

Demid's avatar
Demid committed
1074
We've used __ hours of the __ hour budget.
1075

1076
h6. What's left to do? (Is it on track to be done before the deadline and within the hours budget?)
1077

1078
(describe)
1079

1080
h6. Are the deadlines in the "Timeline" section of this epic's description correct?
1081

1082
(/) or (x)
1083

1084
h6. Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint?
1085