Skip to content

Roles and Expectations

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, we use roles, and all people in the organization share a set of expectations.

What is expected from everyone

The general expectations for anyone working at OpenCraft:

  • I can work from wherever I want, provided I have access to a reliable high-bandwidth internet connection good enough for video calls.
  • I can set my own work schedule, and work when I want during the week, as long as I remain available to answer to others (please see: the Communication section below)
  • (In general) I am not expected to work weekends (unless I'm behind on my commitments), which should remain an exception, not the rule! If you find yourself forced to work on week ends more than once per month, that likely reflects an issue with your time management that needs fixing. If I work week ends as a personal choice, I will not expect other team members to also work week ends.
  • I will make sure my cell's responsibilities are continuously being properly taken care of, by reviewing their status at least once per week.
  • I will work at least the amount of hours per week that is specified in my contract (e.g. 40 hours/week), averaged over each month, excluding scheduled holiday time.
  • 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 section.
  • 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 to take over my duties.
  • I will provide my own hardware (laptop).
  • I will keep my computer(s) secure and up to date as described in the security policy.
  • 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).
  • I will attend the Open edX Conference every year, unless exceptional and important personal 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).
  • As a conference attendee, I will submit a talk proposal and present it. If my talk isn't accepted, I will co-present a talk with someone else from OpenCraft.

Communication

  • If any client email is addressed to me, I will respond to it within 24 hours (excluding weekend days), or ensure that someone else on my cell does.
    • 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.
    • If I can't answer immediately, I will at least send a quick reply to let them know we're working on a response, and when they should expect it.
  • 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.
  • I will respond to pings on GitHub or GitLab within 24 hours (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 the current sprint, I will respond to the ping with an estimate for when they can expect a full response.
  • I will read and respond to forum threads:
    • On the announcements forum: within 24h, excluding week-ends & time off;
    • On the rest of the forums, within 2 weeks, except for the off topic forum, which doesn't need to be read or replied to at all.
  • 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 where necessary.

Sprint tasks

  • I will follow the process and expectations outlined in the pull request process section.
  • I will never add my code (even DevOps code!) to a production branch directly - I will always 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:
    • Small Open edX environment tweaks (example)
    • Minor/bugfix package version bumps (example)
  • I will only commit to work each sprint that I believe I can comfortably complete within the allotted sprint time (two weeks). Here, "complete" means "get to external review or get merged, deployed, and delivered."
  • As a core team member, I will avoid taking newcomer-friendly tasks unless they are urgent 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.
  • I will get all of my tasks ready for internal review (by someone else on the OpenCraft team) by the end of Wednesday in the second week of the sprint at the latest. This will ensure that 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:
    1. When do each step of the task need to be completed?
    2. Which days will you work on which task?
    3. When do individual parts need to be completed to be on time?
  • It's also important to keep some margin on the sprint, in case something doesn't go as expected.
  • I will get my tasks to at least External Review (or "Deployed & Delivered" if no external review is required) by one hour before 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, I will inform the sprint firefighters (and epic owner) as early as possible, 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.

Roles

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.

Changing Roles

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.

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 Technical Security Manager 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.

Types of OpenCraft members

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 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 where they often have to take on some additional roles, including Sprint Firefighter and Discovery Duty.

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.

Recruitment manager

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 role is intended as a support role that would provide recruitment work for all the other cells. This includes:

  • Selection of newcomers (see the recruitment checklist):
  • 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;
  • Onboarding and offboarding of newcomers, including:
  • Starting the onboarding process;
  • Creation of their accounts on the OpenCraft tools & granting rights;
  • Creation of their onboarding epic and tasks;
  • Ensure the newcomers have good conditions to work: ahead of a newcomer start date and before assigning them to a cell, ensure the cell has a mentor assigned and can guarantee a good line up of tasks.
  • And after, ensure the trial goes well, implement changes like the trial projects, etc.
  • The role would be responsible, overall, for increasing the number of newcomers who become core team members
  • Organization of the review and confirmation of core developers:
  • 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;
  • Regularly review recruitment trial results for interview selection accuracy.

We will have a single backup for the recruitment manager (in cases of unavailability).

Cell management

The coordination on each of the cell management roles listed below is to be assigned to an individual member of the cell as a recurring epic. However, the way that each role is handled beyond what is described in this handbook is the responsibility of the cell as a whole, with all of its members being considered as weekly reviewers:

If desired, each role can be handled via multiple tasks assigned to different owners, as long as the overall responsibility for coordinating the work involved in a specific role is assigned to a single person.

Unless otherwise stated, all of these roles should exist on any type of cell:

Sprint Planning Manager

This role is different from the Sprint Manager, though both roles can be taken by the same person if desired.

The planning steps and their schedule are described in more detail in Sprint Planning Process, but here is an overview:

  • Task Estimation Session: Each sprint an estimation session for tasks that are scheduled for the following sprint is created automatically in JIRA. Towards the end of the sprint the estimation session is closed and story points are assigned to tickets based on estimates that team members provided. This step also happens automatically. The only manual step that the Sprint Planning Manager needs to complete is to add epic owners as Scrum Masters to the estimation session so that they can update the session with any tickets that did not exist prior to the initial launch of the session, and that need to be included in the upcoming sprint.
  • Prioritization: Each cell is closest to the needs of its clients and knows best the work that needs to be performed in the coming weeks or months, so it's in the best position to prioritize its own backlog accordingly. As part of this step, tasks should be arranged in the following order (decreasing priority):
    1. Client work to ensure that the clients' needs are met, and that they are happy with our work.
    2. 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.
    3. Internal projects flagged by the management as priorities.
    4. 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 budgets remain a good practice to follow, but the amount of internal work scheduled for a given sprint doesn't require approval from management.)
  • Task Insertion: See Sprint Planning Process > Task insertion for details.
  • Sprint Preparation
    • Make sure that your cell and its members aren't overcommitted, and work with epic owners to push tasks out to Stretch Goals if necessary.
    • Make sure that tickets for next sprint are green (i.e., that they have an estimate, an assignee, and a reviewer). Follow up with team members on tickets that aren't green, and push unassigned tickets out to Stretch Goals.
    • Lastly, complete the current sprint and start the new one.

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.

Sprint Manager

Each cell has its own sprint board and tickets, and is responsible for managing the sprint, including necessary preparations and wrapping up completed sprints.

  • Sprint Preparation: Every Monday before the start of the new sprint:
    • Double-check if any of the people assigned to a rotation in the upcoming sprint are off, and if so that a backup will be available (e.g. that at least one firefighter will be present).
  • Assigning Firefighter Rotations. The Sprint Manager should keep the firefighter assignments in the Weekly Rotations Schedule up-to-date.
    • This can happen at any time during the sprint, as long as the spreadsheet is checked at least once per sprint, and updated as necessary.
  • Mid-sprint updates:
    • Confirm that all members of your cell have posted a mid-sprint update (text only), and follow up with people as necessary via your cell's Sprint Updates thread until everyone's posts are available.
  • Sprint Wrap-Up:
    • Confirm that the spillovers spreadsheet for your cell contains explanations for all spillovers listed for the previous sprint. It is updated by SprintCraft at the end of each sprint.
    • Create the Sprint Retrospective forum post/poll and create new entries in the retrospective spreadsheet for the new sprint.
    • Confirm that all members of your cell have posted an end-of-sprint video update, and follow up with people as necessary via your cell's Sprint Updates thread until everyone's posts are available.
    • Review sprint deliveries: Move tasks from Deployed & Delivered to Done, after double-checking that all the criteria for calling it "Done" have been met.
  • Meetings: For cells, such as the business cell, which don't have an asynchronous planning session, the Sprint Manager leads the sprint planning meeting.

Epic Planning and Sustainability Manager

See Processes > Epic Planning and Sustainability Management for additional information about the responsibilities listed below.

Epic Planning

Every sprint:

  • Review and evaluate status changes of individual epics from the past sprint.
    • Make sure that:
      • Each epic that is In Development has an epic update.
      • The Epics board correctly reflects the status of each epic.
      • The "Time / Estimates" section of the epic planning spreadsheet is up-to-date with info on new and completed epics.
    • In case of any doubt about the correct status for an epic leave a comment on the epic.
  • Compare the Epics board for your cell with the epic planning spreadsheet and update the spreadsheet as necessary.
  • Add/Update team member availability in the epic planning spreadsheet.
  • Handle requests from cell members to change their weekly hour commitments.
  • Record information about upcoming vacations in the epic planning spreadsheet.
  • Update Role statistics for your cell.
  • Bring the Discovery Duty rotations in the Weekly Rotations Schedule up-to-date.
  • Adjust capacity allocations for coming months as necessary.
  • Ensure delivery and bugfix deadlines for individual epics are on target.
  • Coordinate with the team's recruitment manager to slow down/speed up recruitment as necessary.
  • Post an update on the "Epic planning and sustainability management - <your cell>" epic with the following checklist:
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    h3. Epic planning and sustainability update (Sprint ???)
    
    h4. Epic status
    
    * ( ) Review and update epic statuses as needed.
    ** ( ) New epics ("Prospect", "Offer / Waiting on client", "Accepted"):
    *** ( ) Add an entry to the [Time / Estimates|https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit#gid=841714444&range=A1] sheet of the epic planning spreadsheet.
    *** ( ) Move to "In Development" if work has started.
    ** ( ) In development:
    *** ( ) Make sure epic updates are posted by epic owner/reviewer.
    *** ( ) Move epics that have become blocked on the client to "Offer / Waiting on client".
    ** ( ) Delivered epics:
    *** ( ) Move to "Delivered to client / QA".
    ** ( ) Completed epics:
    *** ( ) Move to "Done".
    *** ( ) Update corresponding entries on the [Time / Estimates|https://docs.google.com/spreadsheets/d/1j-fOflCXRyC8qL8yp7zPcbklQqdeMTQnvrVS-7E0aWE/edit#gid=841714444&range=A1] sheet of the epic planning spreadsheet.
    
    * ( ) Compare the Epics board with the epic planning spreadsheet and update the spreadsheet as necessary.
    
    h4. Availability updates (recruitment, weekly commitments, vacations)
    
    * ( ) Follow up on pings from the team's recruitment manager:
    ** ( ) For people joining the team, add availability and onboarding hours for the coming months to the epic planning spreadsheet.
    ** ( ) For people leaving the team:
    *** ( ) Update their availability for the coming months.
    *** ( ) Help find new owners for their responsibilities (roles, clients, epics).
    
    * ( ) Handle requests from cell members to change their weekly hour commitments.
    
    * ( ) 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.
    
    * ( ) Update [Role statistics|https://docs.google.com/spreadsheets/d/1i1BOjiikB_zFvd8PgB4pteNVYI5tmE7DNbrE8JQI7UQ/edit] for your cell.
    
    * ( ) Update the Discovery Duty assignments in the [Weekly Rotations Schedule|https://docs.google.com/spreadsheets/d/1ix68BsU2hJ2ikexXWeBcqFysfoF4l7IKRghIDQgyfPs/edit#gid=1068304496]. If this is the first sprint where no team members are available for discovery duty, inform Xavier so he can verify no internal projects should be paused.
    
    h4. Capacity requirements
    
    _For in-progress epics:_
    
    * ( ) Evaluate the amount of time required to complete the accepted project scope over the next months and update capacity allocations in the epic planning spreadsheet.
    * ( ) Ensure delivery and bugfix deadlines of individual epics are on target (or are being actively discussed on the epics). If that's not the case, 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.
    * ( ) Coordinate with the team's recruitment manager to slow down/speed up recruitment as necessary.
    
    h4. Client updates
    
    * ( ) 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.)
    
    h4. Budgeting
    
    _Once per sprint:_
    
    * ( ) *Monday of W3:* Review amount of billable and non-billable work scheduled for next sprint, and post update on your cell's epic planning and sustainability epic.
    
    _Once per month:_
    
    * ( ) *Before the 5th of the month:* Check that tasks from previous month use correct accounts, and post update on your cell's epic planning and sustainability epic.
    * ( ) Add actuals for previous month to epic planning spreadsheet.
    * ( ) Adjust client budgets for sustainability dashboard as necessary.
    
    _Once per quarter:_
    
    * ( ) Post update about cell's sustainability on forum.
    * ( ) Review and update budgets for non-billable cell accounts.
    
    h4. Notes
    
    ...
    

Every month:

  • Add actuals for the previous month to the epic planning spreadsheet.
  • Adjust client budgets in SprintCraft as necessary to keep the sustainability dashboard for your cell up-to-date.
Sustainability Management

The sustainability manager of a cell is responsible for ensuring that the cell keeps the amount of non-billable hours logged in check. In particular, the sustainability manager must monitor the cell's sustainability ratio and make sure that the cell hits its current sustainability target (as listed under Cell-Specific Rules).

To help with this, the sustainability manager must perform the following activities:

Every sprint:

  • Monday of W3: Compile and post sustainability preview for the upcoming sprint, using the following template:
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    h4. Sustainability preview for Sprint <next> (<cell name>):
    
    * Period selected: Tue <date> (beginning of Sprint <current>) -- Mon <date> (end of Sprint <next>)
    * Total number of billable hours estimated: h (left this sprint) + h (next sprint) = h
    * Total number of non-billable hours estimated: h (left this sprint) + h (next sprint) = h
    * Resulting sustainability ratio (non-billable / (billable + non-billable)): **%, {lower,higher} than last sprint.
    * Notes:
    ** ...
    * Questions:
    ** ...
    
  • Follow up with epic owners about budget issues as necessary.

Every month:

  • Before the 5th of the month: Check that tasks worked on over the course of the previous month use correct accounts, and post an update on your cell's epic planning and sustainability epic. You can use the following template:
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    h3. Accounts review for <month> <year> (<cell name>):
    
    h4. Client accounts
    
    h5. Updates applied
    
    * <ticket>: Changed account from <previous> to <new>.
    
    h5. Open questions
    
    * <ticket>: ...
    
    h4. Internal accounts (non-cell)
    
    h5. Updates applied
    
    * <ticket>: Changed account from <previous> to <new>.
    
    h5. Open questions
    
    * <ticket>: ...
    
    h4. Internal accounts (cell)
    
    h5. Updates applied
    
    * <ticket>: Changed account from <previous> to <new>.
    
    h5. Open questions
    
    * <ticket>: ...
    
    ---
    
    CC <Administrative Specialist>
    

Every quarter:

  • In January/April/July/October: Compile and post sustainability update on the forum, choosing from the templates listed below.

    • If your cell is currently sustainable, the following format works well for the quarterly sustainability update:

      (click to expand)

       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      # <cell name> - {January,April,July,October} <year> ({Q1,Q2,Q3,Q4} <year> update)
      
      You can log time spent reading and responding to sustainability updates on the sustainability epic of the corresponding cell:
      
      * [BB-284](https://tasks.opencraft.com/browse/BB-284) for Bebop updates
      * [FAL-49](https://tasks.opencraft.com/browse/FAL-49) for Falcon updates
      * [SE-248](https://tasks.opencraft.com/browse/SE-248) for Serenity updates
      
      ## Goal
      
      <cell name> unlocked the <new target>% limit to non-billable work in <month> of <year>, which means that the goal from <next month> <year> forward is keeping the sustainability ratio below <new target>%.
      
      ## Sustainability Ratio
      
      ### Entire reference period (<month> <year> -- <month> <year>)
      
      The sustainability ratio for the period <yyyy-mm-dd> -- <yyyy-mm-dd> is **<percent>%**.
      
      ### {Q1,Q2,Q3,Q4} only (<month> <year> -- <month> <year>)
      
      The sustainability ratio for the period <yyyy-mm-dd> -- <yyyy-mm-dd> is **<percent>%**.
      
      ## Billable Hours ({Q1,Q2,Q3,Q4})
      
      The largest source of our billable hours is <client>.
      
      Top contributors of billable hours by account:
      
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * ...
      
      ## Non-Billable Hours ({Q1,Q2,Q3,Q4})
      
      Top contributors of non-billable hours by account:
      
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * ...
      
      ## Projections for (the rest of) <year>
      
      ...
      

    • If your cell is currently above its sustainability target, you'll probably want to go into a bit more detail with your review and use the following format for the quarterly sustainability update:

      (click to expand)

       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      82
      83
      84
      85
      86
      87
      # <cell name> - {January,April,July,October} <year> ({Q1,Q2,Q3,Q4} <year> update)
      
      You can log time spent reading and responding to sustainability updates on the sustainability epic of the corresponding cell:
      
      * [BB-284](https://tasks.opencraft.com/browse/BB-284) for Bebop updates
      * [FAL-49](https://tasks.opencraft.com/browse/FAL-49) for Falcon updates
      * [SE-248](https://tasks.opencraft.com/browse/SE-248) for Serenity updates
      
      ## Previous updates
      
      To see where <cell name>'s budgets stood at the end of {Q1,Q2,Q3,Q4}, see the latest sustainability report from [<month> <year>](<forum link>).
      
      At that time <cell name> had a sustainability ratio of **<percent>%** for the <start year>-<current year> period.
      
      ## Goal
      
      <cell name> has yet to unlock the <new target>% limit to non-billable work, which means that <cell name> must continue to target a sustainability ratio of **<current target>%** in the coming months.
      
      ## {Q1,Q2,Q3,Q4} <year> Sustainability Ratio
      
      At the end of **{Q1,Q2,Q3,Q4} <year>**, <cell name>'s sustainability ratio for the entire reference period (<yyyy-mm-dd> to <last day of quarter under review>) is **<percent>%** (an {increase,decrease} of <percent>% since last update).
      
      Detailed breakdown:
      
      ### Sustainability numbers from *<day> <month> <year> to <last day of quarter under review>* (entire reference period)
      
      | Total hours | Non-cell hours | Billable cell hours | Non-billable cell hours | % non-billable cell hours | Remaining non-billable hours |
      |---|---|---|---|---|---|
      | <hours> | <hours> | <hours> | <hours> | **<percent>%** (max <current target>%) | **-<hours>** |
      
      ### Sustainability numbers from *1 Jan <year> to <last day of quarter under review>* (Q1-{Q1,Q2,Q3,Q4} of <current year>)
      
      | Total hours | Non-cell hours | Billable cell hours | Non-billable cell hours | % non-billable cell hours | Remaining non-billable hours |
      |---|---|---|---|---|---|
      | <hours> | <hours> | <hours> | <hours> | **<percent>%** (max <current target>%) | **-<hours>** |
      
      ### Sustainability numbers from *1 Sep 2021 to 31 Dec 2021* (Q4 only)
      
      | Total hours | Non-cell hours | Billable cell hours | Non-billable cell hours | % non-billable cell hours | Remaining non-billable hours |
      |---|---|---|---|---|---|
      | <hours> | <hours> | <hours> | <hours> | **<percent>%** (max <current target>%) | **-<hours>** |
      
      ## Billable Hours ({Q1,Q2,Q3,Q4})
      
      The largest source of our billable hours is <client>.
      
      Top contributors of billable hours by account:
      
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * ...
      
      ## Non-Billable Hours ({Q1,Q2,Q3,Q4})
      
      Top contributors of non-billable hours by account:
      
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * **<account name>**: <period spent>h
      * ...
      
      ### Changes since previous update
      
      The sustainability ratio for the previous quarter ({Q1,Q2,Q3,Q4}) was **<percent>%**, so {Q1,Q2,Q3,Q4} brought with it a noticable {increase,decrease} in the ratio of non-billable hours.
      
      <List reasons for changes.>
      
      ## Changes affecting sustainability over the entire reference period
      
      Aside from the {Q1,Q2,Q3,Q4}-specific changes described above, there's a few additional factors that affected <cell name>'s sustainability ratio for the entire reference period (i.e., <month> <year> -- <month> <year>):
      
      <List changes (if any) or delete this section.>
      
      ## Other notes
      
      <List notes (if any) or delete this section.>
      
      ## Projections for (the rest of) <year>
      
      ...
      
      ## Plans for improving sustainability
      
      ...
      

  • Review and update budgets for non-billable cell accounts in SprintCraft, coordinating with epic owners as necessary.

Cell creation manager

A temporary role to manage the creation of a new cell, where the assignee:

General information on the life cycle of cells, including how and why they're born, can be found in the cell life cycle page.

Code reviewer

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 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 will ensure that I review it within 24 hours, or at least indicate to the author when they can expect a review.
  • 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 authors to the exact changes needed for their PR to be accepted.
  • 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.
  • 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?
  • I will always test the code manually, either locally or on a sandbox, unless there is no 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 and use it for the "stamp of approval" on all PRs I review:
1
2
3
4
5
6
7
:+1:

- [ ] 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.

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):

Review template

  • 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. 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 48 hours, the code reviewer should determine whether this ticket is urgent. If it is, ask the firefighter for help to reduce the risk of spillover.

Newcomer

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

  • Not commit to more than 3 story points 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.
  • I'll prepare for every 121 with my mentor based on the newcomer 121 checklist
  • Tag my task reviewer(s) with task-specific questions on the ticket, or if I'm completely blocked, try using Mattermost to contact my reviewer, mentor, sprint firefighter, or other people working on the same project. Reviewers have time allocated to help during Onboarding, so it's ok to reach out!
  • Ask my Reviewer questions early in the sprint if there is missing information or if the requirements are unclear. Newcomer-friendly tasks have a minimum set of information that should be included in the task description, but if this isn't complete, ask the task creator and/or your reviewer to do it.
  • Provide lots of updates to my assigned reviewer/mentor for each task, so they can provide timely help.
  • Assign myself as 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.

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 page for more advice on the onboarding, the evaluation process and criteria.

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

Onboarding epic ownership

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

  • 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.

  • 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.

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.

  • Treat my onboarding epic as a proper epic and manage it like an epic owner.

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.

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.

Summary Panel

Hover over the Time numbers below the progress bar to see an explanation.

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

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.

  • 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"

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, 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.
  • 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 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.
  • During every 121 with the newcomer, I'll go through the mentoring 121 checklist checklist
  • I will participate on the screening and developer review tasks, taking into account these 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.
  • 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 section.

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

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 (preferably from client maintenance epics).
  • 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 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, you can create community contribution tasks.
  • It is okay to assign very small discoveries, which do not result in a standalone epic. (See Newcomer-friendly tasks discussion)
  • 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 goals of assigning varied tasks, of increasing complexity.
  • If none of the above work, escalate the issue to the 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.

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 and CRI 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 know.

Firefighter

See Processes > Firefighting for general rules about firefighting and guidelines for triaging issues.

As a sprint firefighter:

In general

  • I will make sure that the pager is always able to interrupt me while I am on call.
    • 💡 For example, you should keep your phone within audible radius or have it on your body if it is on vibration. Further measures for minimizing the likelihood of missing pager alerts will depend on your notification settings.
  • I will snooze pager alerts rather than acknowledge them.
    • 💡 Unlike acknowledged alerts, snoozed alerts will start sending notifications again after the snooze period ends, making them less likely to be forgotten and left without proper resolution.
  • If I am the first team member to act on a given pager alert, I will assign the alert to myself and monitor for escalation (or at least make sure that another team member does the same).
  • I will not record any time on my firefighting ticket for the current sprint; instead I will always use a dedicated ticket (or appropriate epic) for logging my time.
  • I will be subscribed to the help and urgent mailing lists.
    • 💡 Be sure to filter messages from these lists to a separate folder to look at them only when you need to - but also make sure that if any such emails explicitly include you in To/CC, they *will* arrive in your inbox).
  • I will mind triage guidelines when handling incoming emergencies.
  • I will reserve the required number of firefighting hours for my cell for fulfilling the duties listed below, and will proactively pursue those duties.

Before the sprint

  • I will add myself to the pager rotation, making sure that:
    • My on-call times cover at least my working hours.
      • (Optional) If I want to help cover any additional hours, I will adjust my pager schedule accordingly.
    • My on-call times include each day I will be working over the course of the entire sprint.
  • If available, I will pick up some CAT-2 tickets1 and add them to the upcoming sprint, with a total estimated effort that roughly matches my firefighting hours. 💡 This will help me make additional room for firefighting more easily during the sprint in case the amount of firefighting work that comes up exceeds what I can handle within the number of hours allocated to my firefighting ticket.
    • To limit sustainability impact of this practice, I will generally prefer CAT-2 tickets from client epics over CAT-2 tickets from internal epics.
    • I understand that in some situations there might not be enough CAT-2 work available to allow all firefighters to do this, and/or the amount of CAT-1 work that needs to be completed in the upcoming sprint might be too large to fit in one or more CAT-2 tickets (without jeopardizing deadlines of important projects).
  • I will assign tickets for the rest of my committed hours to myself as I normally would, but I will also make sure that a few additional tickets are left either in Stretch Goals or in the following sprint. 💡 This will keep me from running out of work in case there isn't enough firefighting work to fill my hours.
    • I will assign these tickets to myself and find a reviewer for them so that they are ready to pull into the sprint if necessary.
  • If I am Firefighter 1 (FF1), I will check the OpenCraft calendar for the time and day of the next Social Chat for my cell and make any necessary adjustments. I'll also post a topic for the social chat on the forum.

1: CAT-2 tickets generally don't have an end-of-sprint deadline, so they can usually be swapped out of the sprint without a lot of discussion and/or coordination with other cell members.

During the sprint

  • I will work on the following, listed by decreasing priority:
    • Handling emergencies from other team members (reported by team members directly to me or to the other sprint firefighter(s), with Braden arbitrating priorities).
    • Handling emergencies reported by clients from my cell, via the help@opencraft.com and/or urgent@opencraft.com mailing lists that I subscribed to previously.
      • I will help triage and prioritize these issues, asking other team members for advice as needed, and escalating to Braden/Xavier if all else fails.
        • If a client misuses urgent@opencraft.com for requests that turn out to be non-urgent, I will politely remind them that this e-mail address is reserved for critical and major incidents as defined in OpenCraft's SLA.
      • I will inform clients about critical issues immediately, or reply to them if they reported the issues themselves.
        • I will remove urgent@opencraft.com from the list of recipients when replying to clients, to avoid triggering repeated pages for the same issue.
      • I will update clients on the current status of relevant investigations regularly, and look out for additional messages (containing follow-up questions and/or information) from them.
      • I will ask clients for final confirmation that all issues have been fixed before closing any alerts.
    • Handling critical bugs reported by QA teams.
    • Deploying hotfixes and security patches on client instances.
    • Following up on issues affecting periodic build instances as necessary (when prompted by the team member responsible for Community Liaison).
    • Providing reviews for tasks from the current sprint that are missing a reviewer.
    • Completing any personal spillover from the previous sprint.
    • Working on client requests that can't wait until the next sprint, in particular in the first week of a sprint.
    • Ensuring a clean sprint by helping other team members with their tasks, in particular in the second week of a sprint.
    • Additional tasks from Stretch Goals or the following sprint that I lined up for myself before the sprint.
      • I will only pull these tickets into the current sprint if I am confident that I will have time to finish them in addition to the firefighting.
  • I will document incidents as they happen and post a summary to the OpenCraft Ops Review forum thread at the end of the sprint.
  • If necessary, I will swap some CAT-2 tickets out of my sprint to make additional room for addressing fires.

Community Relations

One of OpenCraft's most important core values is community involvement. To reflect this, we have three roles that are focused on community involvement:

Core Contributor

edX has a Core Contributor Program which allows people outside of edX to review and merge OSPRs, contribute to platform development in other ways (e.g. by reviewing translations), mentor new community members, and participate in the strategy and direction of the platform.

Our goal is for every OpenCraft member to eventually become a Core Contributor and for every Core Contributor to spend a minimum of 20 hours per month on contributions -- assuming that their total hourly commitment per month reasonably supports this. For team members with commitments below 120h/month (30h/week), joining the Core Contributor program would require making adjustments to the expected volume of monthly contribution hours. This is not possible based on current rules of the program. However, organizational commitments for the Core Contributor program are under discussion and requirements may change going forward. When in doubt, team members looking to join the Core Contributor program in the near future can reach out to the owner of the Core Contributor epic to get the latest information on the number of contribution hours they would be expected to put in per month.

Priorities for Core Contributor Work

We set priorities that we want our team's Core Contributors to focus on - see the section on "Priorities for Core Contributor Work" in the description of the Core Contributor Program epic for details.

Other Responsibilities

Aside from current priorities, it's important for Core Contributors to spend time on community engagement and technical upkeep. Responsibilities include:

Open edX Forum Moderation
  • Help moderate the official Open edX forum:
    • Welcome new posters.
    • Help community members use the forums well, for example by giving them advice (where applicable) about:
      • Choosing the right categories for their posts, and moving/splitting/concatenating threads when needed.
      • Providing enough information about their situation. (If they make their requests more precise they may get better answers, and more quickly.)
      • Using 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.
  • Monitor OEPs, ADRs, and community discussions on the forum, and ensure that OpenCraft participates in relevant ones.
  • Answer questions from the community.
    • Note that you should generally favor helping one person more fully, over having many smaller contributions to more threads.
Communication via Other Channels
  • Monitor the Open edX Slack, in particular the #opencraft channel. Follow up on community questions that pop up there, and mentor other community members as needed.
Technical Upkeep

This involves tasks such as updating documentation, fixing bugs, updating packages, and improving developer onboarding.

Community Liaison

This role involves the largest 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 account (which is an internal non-billable account). However, the following applies:

  • Whenever possible the Community Liaison should assign individual tasks to other accounts, using the Community Relations account only as a fallback.
  • The Community Relations account can only be used on tasks that are either assigned to the Community Liaison themselves, or to the OSPR Liaison. In other words, it should not be used for Core Contributor tasks, or, for example, for other team members to attend community meetings.

Responsibilities of the Community Liaison role include:

Engaging OpenCraft's Open Source Community
  • Monitor OpenCraft's public repos; specifically, the following areas on GitHub and GitLab:
  • Watch these channels for technical questions (e.g. about our XBlocks) and answer them.
  • Watch for bug reports and pull requests submitted by the community and make sure that they get a prompt answer and/or review:
    • Acknowledge the contribution within 24 hours (i.e., within the same time frame that we generally set for external and internal communication).
      • To help with this, set up appropriate e-mail filters so that you are immediately aware of incoming communication from the community.
    • If circumstances allow (i.e., if you have time and a reasonable amount of relevant context), you may fix the reported bug or review and merge the submitted PR yourself.
    • If circumstances do not allow you to fix the bug or review and merge the PR yourself (i.e., if you're lacking time and/or relevant context), you will:
      • Create an internal ticket for proper follow-up.
      • Set a deadline of 2 weeks (from creation of the ticket) for completing the work.
      • Set a timebox for the work based on guidelines from Running a Free Software project.
      • Assign the ticket to a firefighter 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, the Liaison should set an early deadline for the first review, and the assignee of the ticket must remain reactive to subsequent updates and comments from the contributor.
      • Let the contributor know that next steps have been scheduled.
  • Monitor OpenCraft's forums for posts from people external to the team, and follow up on them as necessary.
Open edX Community Engagement

Complementing the work that Core Contributors do, the Community Liaison will both engage in and help coordinate company efforts pertaining to the Open edX community as needed, across all contact points. Specific duties include:

  • Keeping an eye on the build-test-release CI notifications.
    • Forward issues to firefighters as necessary, and ensure we post replies on failures, either explaining them when we fixed or caused them, or otherwise asking for help to fix them.
  • Being available as a community reference ("Talk to Ned about this, Felipe about that"), not only internally at OpenCraft, but also for the community itself.
Attending Community Meetups

The Community Liaison is expected to attend the following community meetups:

  • Open edX Contributors Meetup (bi-weekly)
  • Online Community Meetup (no specific schedule)
    • 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) on the boards listed below. This activity is not limited to tasks where OpenCraft is directly involved, but should also include tasks created by or assigned to other community members:

OSPR Liaison

This role involves a commitment of 1 hour per sprint, per cell. (For example, if there are 3 cells the total commitment per sprint for this role will be 3 hours.)

Like the Community Liaison role, it is a company-wide role and uses the Community Relations account. Specifically, time spent working on responsibilities listed below should be logged on SE-4942.

The OSPR Liaison is responsible for coordinating OSPR reviews. This involves:

  • Maintaining a prioritized list of PRs in a document shared with edX's community management team: OSPR priorities from OpenCraft
  • Sending the top 3 PRs on the list to the community management team (usually Natalia) once a week.
  • Keeping 0.5h/week available to handle any PR sandbox requests from edX/tCRIL:
    • Someone (likely Ned or Natalia) will ping you on a PR targeting an older release branch.
    • 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 OCIM's setup_pr_sandbox management command and provide it the URL of the edx-platform PR.
    • You can give SSH access to the reviewer by adding their GitHub ID to COMMON_USER_INFO in the PR sandbox's config:
      1
      2
      3
      4
      COMMON_USER_INFO:
        - github: true
          name: github_id
          type: admin
      
    • You can ask the PR author to add the standard settings 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.

In case there isn't sufficient time, create a ticket and ping a firefighter to take care of the actual sandbox creation steps.

Miscellaneous Contributions

All team members, irrespective of whether they hold Core Contributor status or not, are encouraged to be involved in the Open edX community on the forum and help with platform maintenance as described above: If you spend some time on community involvement and it doesn't fall under the scope of one of your current tickets or roles, just create a ticket for it in your sprint (e.g. "Answer XBlock question on forum") and put it on the Contributions account.

Note that time logged against the Contributions account is non-billable. So for larger contributions, team members without Core Contributor status should reach out to their cell's sustainability manager before starting to work on them and confirm that the cell can spare the necessary number of non-billable hours.

Ops reviewer

  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.
  2. Be a backup on the pager (alerts sent first to the other(s) recipient(s), but escalated if not acknowledged within 30 minutes).
  3. If none of the other recipients are around and an issue is left unsolved, and it either is sent to urgent@, or was sent more than 12h ago to ops@opencraft.com and needs to handled quickly, warn the sprint firefighter about it: create a ticket about the issue and assign it.

Note that keeping an eye on build-test-release CI notifications triggered by periodic builds and following up as necessary is part of the Community Liaison role, and out of scope here.

Discovery duty assignee

This role is specific to a generalist cell: because of the focus on a single client, project cells need not have a developer on standby for new prospects.

Discovery Duty is only handed to team members that have room to take clients or epics. Typically, this will be newer team members, or team members whose clients have recently closed their contracts.

If no team member has room for additional epics or clients, the cell will be closed to taking on new clients until such room opens up via additional recruitment or client departure. In this case, the role will not be assigned.

As the week's discovery duty assignee:

  • If I have doubts on my ability to estimate a discovery accurately, I will find a reviewer who is more familiar with the technologies involved and make them aware of my concerns, asking for an especially close review.
  • I will keep at least 5 hours of my time to do discovery work on any small leads/client requests that come up during the week.
  • If I do some discovery tasks, I will ping the sprint firefighters to review the result (unless the above note about estimate accuracy applies-- then I shall ping the appropriate reviewer.)
  • 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. In the case that no team member can take the work, the person assigning the Discovery task must either coordinate a solution to free up a team member, or else we will decline the work.)
  • 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 only pull this task into the current sprint if I am confident that I will have time to finish it in addition to the discovery duty. For the task to be ready to pull in, it should be assigned to me and have a reviewer.
    • Before pulling the task into the sprint, I will first check if I could instead use my discovery hours to help others finish their sprint commitments.

Specialist roles

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

While specialists have priority when it comes to taking tasks related to their specialty, there's no restriction on other team members and taking "specialty" tasks is encouraged to spread knowledge around the cell. However, specialists should always take at least the role of 2nd reviewer so they are in a position to track progress and provide help.

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.

Specialist roles and corresponding responsibilities include:

Technical Security Manager

  • Responsible for the technical security of the work we do, our platform and OpenCraft as a whole.
  • Responsible for OpenCraft's Security policy.
  • Offboarding of team members who have left.

Epic owner

As an epic owner:

  • 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 section and follow the steps listed there.
  • 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.
  • 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.
    • 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.
  • I will aim to split out any suitable newcomer-friendly work into separate tasks, flag them as Newcomer-friendly tasks in the Backlog, and ensure they contain the required information. To guard the epic budget, "onboarding" time can be logged against the newcomer's epic.
  • 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.)
  • 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:
    • For epics with a fixed scope/budget:
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      h2. Epic Update -- fixed scope / fixed budget (Sprint ???)
      
      h3. Budgeting
      
      h4. What's the status of the hour budget for this epic?
      
      We've used __ hours of the __ hour budget.
      
      h4. Will it be possible to complete the remaining work within the hour budget?
      
      {color:#c1c7d0}
      * Make sure to set the _Original Estimate_ on each ticket based on the corresponding estimate(s) from the discovery. This will help you detect potential savings or -- more importantly -- potential cases of budget excess if the assignee of a ticket specifies a different estimate via the _Remaining Estimate_ field later on.
      {color}
      
      (/) or (x)
      
      *If not:*
      
      h5. {color:#de350b}How many additional hours will be required to complete the remaining work?{color}
      
      (specify)
      
      h5. {color:#de350b}Has the client agreed to pay for any hours exceeding the current budget (and if so, how many)?{color}
      
      {color:#c1c7d0}
      * For internal epics using non-billable accounts, Xavier is the client. Have a conversation with him and your cell's sustainability manager about the possibility of allocating additional budget to this epic.
      * If additional budget is made available, specify it below.
      {color}
      
      (/), (specify) or (x)
      
      h3. Capacity planning
      
      h4. Will it be possible to complete the remaining work before the deadline?
      
      {color:#c1c7d0}
      * Create tickets for items listed in the discovery and spread them out across upcoming sprints. (Or, if the tickets already exist, simply adjust the scheduling for upcoming sprints as necessary). Use the epic description for this if you need to schedule tickets for future sprints that don't exist in JIRA yet. This will help you determine whether the epic is on track progress-wise.
      {color}
      
      (/) or (x)
      
      *If not:*
      
      h5. {color:#de350b}Has the client approved a new deadline for completing the remaining work (and if so, what is the new deadline)?{color}
      
      {color:#c1c7d0}
      * For internal epics using non-billable accounts, Xavier is the client. Specify the new deadline that Xavier approved (if applicable).
      {color}
      
      (/), (specify) or (x)
      
      h5. {color:#de350b}How many hours will we need to allocate to this epic in the coming months to complete the remaining work?{color}
      
      (specify)
      
      h3. Epic management
      
      h4. Are the deadlines in the "Timeline" section of the epic description correct?
      
      (/) or (x)
      
      h4. Are relevant details mentioned in the remaining sections of the epic description up-to-date?
      
      (/) or (x)
      
      h4. Is the status of each story in the epic correct?
      
      (/) or (x)
      
      h3. Sprint planning
      
      h4. Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint?
      
      (/) or (x)
      
      h3. Other Notes
      
      ...
      
    • For epics with recurring monthly budgets:
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      h2. Epic Update -- dynamic scope / monthly budget (Sprint ???)
      
      h3. Budgeting
      
      h4. What's the status of the monthly hour budget for this epic?
      
      We've used __ hours of the monthly __ hour budget.
      
      h4. Will it be possible to complete the remaining work for this month within the monthly hour budget?
      
      (/) or (x)
      
      *If not:*
      
      h5. {color:#de350b}How many additional hours will be required to complete the remaining work?{color}
      
      (specify)
      
      h5. {color:#de350b}How are we going to deal with this?{color}
      
      +Scope reduction+: We will *adjust the volume of work* for the coming month(s) to make up for this month's increased budget usage.
      
      or
      
      +One-time budget extension+: We will ask the client to pay for hours logged in excess of the budget cap *this month*.
      
      or
      
      +Permanent budget extension+: The volume of work requested by the client is generally increasing, so we will ask for a *permanent increase* of the monthly budget.
      
      h5. {color:#de350b}Has the client agreed to the selected measures (scope reduction and/or budget extension)?{color}
      
      {color:#c1c7d0}
      * For internal epics using non-billable accounts, coordinate with Xavier and your cell's sustainability manager.
      {color}
      
      (/) or (x)
      
      h3. Capacity planning
      
      h4. Will we need to significantly increase or decrease the hour allocations for this epic in the coming months to handle the volume of work?
      
      (/) or (x)
      
      *If so:*
      
      h5. {color:#de350b} How many hours should we allocate to this epic from next month on?{color}
      
      (specify)
      
      h3. Epic management
      
      h4. Are the deadlines in the "Timeline" section of the epic description correct (if any)?
      
      (/) or (x) or N/A
      
      h4. Are relevant details mentioned in the remaining sections of the epic description up-to-date?
      
      (/) or (x)
      
      h4. Is the status of each story in the epic correct?
      
      (/) or (x)
      
      h3. Sprint planning
      
      h4. What's going on this sprint?
      
      (describe)
      
      h4. What's going to be worked on next?
      
      (describe)
      
      h4. Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint?
      
      (/) or (x)
      
      h3. Other Notes
      
      ...
      
    • For ad-hoc support epics:
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      h2. Epic Update -- dynamic scope / no specific budget (Sprint ???)
      
      h3. Budgeting
      
      h4. Are all hours that we logged against this epic's account last month billable?
      
      {color:#c1c7d0}
      * Hours may be non-billable if they exceed agreed-upon budgets for specific tasks: If the client approved a specific budget for a task or set of tasks, we need to stop and ask for a budget extension before spending more time on the task(s). If we ask for retroactive approval, there is a chance that the client won't agree to pay for any/all hours exceeding the original budget, which will make these hours non-billable.
      {color}
      
      (/) or (x)
      
      *If not:*
      
      h5. {color:#de350b}How many non-billable hours did we log last month?{color}
      
      (specify)
      
      h3. Capacity planning
      
      h4. Will we need to significantly increase or decrease the hour allocations for this epic in the coming months to handle the volume of support requests?
      
      (/) or (x)
      
      *If so:*
      
      h5. {color:#de350b} How many hours should we allocate to this epic from next month on?{color}
      
      (specify)
      
      h3. Epic management
      
      h4. Are relevant details mentioned in the epic description up-to-date?
      
      (/) or (x)
      
      h4. Is the status of each story in the epic correct?
      
      (/) or (x)
      
      h3. Sprint planning
      
      h4. What's going on this sprint?
      
      (describe)
      
      h4. What's going to be worked on next?
      
      (describe)
      
      h4. Are all upcoming stories that we should work on in the next week or two created and in the correct upcoming sprint?
      
      (/) or (x)
      
      h3. Other Notes
      
      ...
      
      Other Notes is for any concerns, questions, upcoming vacations, or anything else that you think is worth mentioning because it could affect planning of the next sprint or two.
  • 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, and hand off my responsibilities for my epic to Epic Reviewer.

Epic Reviewer

Epic reviewers are assigned to the 'Reviewer' field on an Epic ticket. As an epic reviewer:

  • I will keep up to date on the progress of the epic.
  • I will review discoveries, planning, budget, and documentation written at the top level of the epic.
  • I will read each epic update and give feedback as needed.
  • I will be ready to perform the tasks and duties of an epic owner in case they go on vacation or are otherwise unavailable for an extended period.

Client owner

  • Client owners manage their relationship with their clients. All the epics and tasks from a given client are done within a single cell, the one the client owner belongs to, but see cross-cell collaboration for some nuances around 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 and Value Propositions up to date.
  • For client epics (epics labeled client-epic), approximately once a quarter, a task will be scheduled automatically, timeboxed to three hours, where client owners review the briefing, current epics, and value proposition, looking for patterns. If they see an opportunity for a new project with the client, they should propose spending a few hours of discovery to the client on the project idea. If the client accepts, they shall schedule a discovery with one of the team members on Discovery Duty.

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 client. The client owner is designated in OpenCraft's CRM, along with the contact details and background for the client.

In general, regardless of which email address the client sent their question to, the client owner should be the one who replies, though they may hand off any conversation to anyone on the team as needed (such as their cell's firefighter). If someone else received the email, please "Reply All" to pass the message on to the client owner for them to reply (add the client owner to the "To" field, and add "OpenCraft help@opencraft.com" to the CC field, and say something like "Passing this on to (client owner name)").

There are a few exceptions:

  • If it's an urgent problem, whoever sees it first should reply and CC the firefighters, help@opencraft.com, and the client owner. One of the firefighters should respond.
  • If it's a general issue/question:
    • If the email is related to a specific project/epic with a different epic owner, that epic owner can reply directly (make sure the client owner and help@opencraft.com are CC'd).
    • If the client owner is away, their designated backup person (usually the reviewer on the "Support" epic/ticket for that client) should take over this role. (Or the firefighters if no backup person was planned.)

We have a few clients with monthly development budgets. For those clients, the assigned client owner is also responsible for reviewing the monthly budget before and during each sprint, to ensure that we are not going too far above or below the budget. They should refer to SprintCraft which can monitor and project the status of each budget as of the end of the upcoming sprint.

When we get a new client, or when the client owner changes (or we start working with a new person coordinating things on the client's side), we send them a welcome email explaining who the client owner is and how to contact us.

Client owners are in a prime position to anticipate the needs of our clients, which can help us start new projects with them. Read the (private) Sales Opportunity: developer stories forum thread for examples of how we've created solid client relationships and handled challenging situations. Client owners are also advised to read the Strategic Client Management Guide. Take a bit of time each sprint thinking about new ways we might create value for our clients.

Cell Supporter

Role type: This is a full time role, dedicated to helping the members of other cells.

Description: The main purpose of the Cell Supporter role is to help lighten the load of management work that cell members have to take care of, so that they can focus more on coding/DevOps, and on handling their clients/epics. The purpose of this role is not to take away cell members’ autonomy in making decisions about their projects, nor to introduce another layer of management between them and their clients, nor to centralize cell-level decision making in a single role. As mentioned previously, we believe that the people who are closest to a given client or project are in the best position to make decisions about how to handle and progress that project.

Note that cell supporters are not project managers, and they also do not manage client relationships.

These duties are part of epic ownership and client ownership, which are responsibilities to be taken on by core team members of individual cells.

Responsibilities

Responsibilities of a cell supporter include:

Cell management support
  • Helping cells by taking on cell management roles that they are currently unable to fill themselves (e.g. due to lack of interest or capacity).
    • Cell members who express interest in taking these roles get precedence over cell supporters when it comes to assigning cell management roles.
    • Cell supporters should not take all cell management roles for a specific cell, even if it would be possible to do so without impacting a cell supporter's capacity for fulfilling the remaining responsibilities listed below.
    • As a cell’s capacity and/or interests change, cell supporters may hand cell management roles back to the cell. To make sure that cell management roles do not remain assigned to cell supporters indefinitely, they perform a quarterly check-in to see if cells wish to take back any of their delegated roles, and if there are other roles that the cells need to delegate instead.
  • Coordinating training initiatives for cell management roles, and making sure documentation on cell management roles is kept up-to-date.
    • For example, prior to a pending cell split, cell members that will be taking on a cell management role for the first time should get a chance to familiarize themselves with the new role before having to jump in head-first and being expected to handle the role according to our standards.
  • Helping cell managers address specific challenges requiring cross-cell coordination.
    • For example, if more than one cell is facing capacity issues, it may be necessary to shuffle projects around between cells. The effort involved in leading this type of cross-cell coordination goes beyond the amount of work that is usually involved in epic planning (and when capacity is low it may be especially difficult to find time for additional planning work), so cells may decide to delegate this work to a cell supporter.

Notes on capacity and budgeting:

  • As indicated above, the amount of cell management support that a cell supporter commits to should leave room for fulfilling the remaining responsibilities listed below.
  • Cell management epics and tickets will stay with their respective cells, even if they are temporarily delegated to a cell supporter. This means that in terms of sustainability impact there is no difference between having cell members handle cell management roles and delegating them to cell supporters.
Process improvements
  • Conducting process reviews, ideally at regular intervals, with the goal of keeping "process debt" in check.
  • Coordinating work on implementing process improvements based on results of process reviews.
  • Addressing individual shortcomings of internal processes that surface over time (such as sustainability blocking development, how to deal with sustainability in the context of cell splits, and improving coordination between cells and business development/marketing).
Cross-cell planning
  • Taking care of scheduling upgrade epics:
    • Keeping track of the rotation of responsibility for upgrades between cells.
    • Informing epic planning managers of cells ahead of time that their cell’s turn is coming up, and that they’ll need to work on freeing up capacity as necessary.
Other responsibilities

Business Development Specialist

As a business development specialist:

  • I will ensure clear and prompt communication with prospects, leads and clients.
  • I will answer emails sent to contact@opencraft.com.
  • I will answer leads sent to our CRM web-to-lead form.
  • I will coordinate with the Epic Planning and Sustainability Manager of each cell to determine availability for new clients and new client projects.
  • I will serve in an advisory role to client owners looking to propose new projects to existing clients.
  • I will regularly look out for business opportunities. Strategy and time spent on these tasks should be discussed with the cell sponsoring the prospect work, and possibly Xavier for key prospects.
  • When a lead becomes a prospect, I will follow up by providing information, drafting quotes, creating epics and issues and documenting in Jira so the team can follow what’s happening. I will include the template in the epic description ("Context, Scope, Budget, Timeline") and set the time budget on the epic ticket.
  • 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 and Value Propositions 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 clients, I will always make sure there is either contact@, help@, or billing@ CC'd:
    • anything related to leads, prospects, and quotes should be shared with contact@opencraft.com
    • anything related to invoices and billing should be shared with billing@opencraft.com
    • the rest (anything non-financial) should be shared with help@opencraft.com
  • I will check completed discoveries for any estimates that can be reused for future discoveries and quotes, add them to the Price list sheet of the epic planning spreadsheet, and add/update price items in Proposify as necessary.

UX Designer

Responsibilities of a UX Designer include:

  • UX Discovery: Informing engineers of the expected hours required to design a component, page, or interface.
  • Wireframe Design: Designing accessible, consistent interfaces as intuitively as possible.
  • UX Testing: Validating UX designs through user testing.

Product Manager

Responsibilities of a Product Manager include:

  • Product Design
    • Working in partnership with (or as) the UX Designer to create the workflows for a product.
    • Setting vision for the features and user stories of a project.
  • User Validation
    • Validating product design choices through user feedback and testing.

Developer Advocate

Responsibilities of a Developer Advocate include:

  • Monitoring the well-being of team members.
  • Checking for indicators of burnout.
  • Proposing and designing solutions to improve personal satisfaction and work-life balance for team members.

Sales Mentor

Responsibilities of a Sales Mentor include:

  • Reviewing sales metrics.
  • Designing sales and related training curriculum for team members.
  • Developing proposals to increase sales performance.

Chief Technology Officer (CTO)

  • Technical Arbiter
    • Final arbiter for technical decisions
  • Technical Excellence
    • Ensuring technical & product quality of everything we do
    • Ensuring software we produce is as open as possible and everything that can be contributed upstream is
    • Championing and improving processes (like our code review process) to improve the quality and efficiency of our software development
    • Reviewing code (in addition to the regular code review process), mentoring developers
    • Being aware of the "big picture" to help developers avoid duplicating each other's work
    • Being available on call 24/7 to respond to emergencies, if regular firefighters are not available
  • Epic/Client Owner Coach
    • Supporting epic and client owners in client meetings, discussions, and in turning requirements into actionable plans/epics
    • Reviewing all discovery stories and estimates
  • Security Manager
    • Ultimately responsible for security of our software, both proactively improving it and responding to incidents effectively

The CTO isn't part of a cell, but can review and participate in any cell's work as needed.

Chief Executive Officer (CEO)

  • Business development:
    • Additional relationship with key clients and prospects
    • Support role for the epic owner, in difficult situations or contract negotiations
    • Reviewer of quotes
    • Initiator for opportunities that are strategically important for OpenCraft, either because of size or side effects
  • Financials:
    • Accounting
    • Invoicing (clients & team)
    • Forecasting
  • Admin:
    • Holidays reviews
  • Legal:
    • Relationship with lawyers
    • Contracts drafting and signature (team and clients)
    • Ownership of legal projects
  • Management:
    • Management of non-technical matters for all cells
    • Management of CTO
    • 121 meetings: continuous rotation of all employees, at 2-3 meetings/week
    • Handle reports of performance issues & process to address it, including firing if needed
  • Hiring:
    • Review of candidate selections by the team's recruitment manager
    • Contract negotiation with accepted candidates
  • Sprint management:
    • Occasional second review of sprint deliverables, sprint planning & epics management on any cell
  • Strategy: evolution of the company
  • Ocim: product management and some code
  • Spreading the word (mailing lists, conferences, opencraft.com)

Marketing Specialist

As a marketing specialist:

  • I will discuss and plan marketing strategies with the business development specialist, the CEO, and external marketing contractors
  • I will schedule and coordinate tasks related to the agreed-upon marketing strategies
  • I am responsible for coordinating maintenance, improvement, and all tasks related to the OpenCraft website
  • I am responsible for coordinating the publication of articles on OpenCraft's blog

Administrative Specialist

As an administrative specialist:

  • I will coordinate and execute all administrative tasks that are related to team member billing, client billing, invoice payments, bookkeeping, and other accounting-related matters at OpenCraft
  • I will participate in the recruitment and onboarding process of new team members, and collect all necessary information to set up their invoicing process

Last update: 2022-08-15