Behaviour and protocol

Code Code reviews Consulting 101 Feedback Good meetings practices How to facilitate team meetings Inclusive language Values

Career

360 review Continuing education policy Engineering manager career ladder Roles Software engineer progression framework Technical skills sheet

Employee manual

Abtion's pomodoro Employee benefits Internal days & community Intro Parental leave policy Safety and security Schedule, time tracking & calendar Sickness & unplanned absence Travelling Vacation & planned time off Work from anywhere policy

Project management

Technical setup when starting a new project Client discontinuing hosting or sla Converting projects from development to maintenance mode Estimating Go live checklist Handoffs Invoicing guidelines Procedure for traffic Sla

Setup

Audio setup Create amazon bucket Database backup setup Gpg signing Pairing setup

Technical practices

Bug triaging Css How and why we do design research Kick off meeting Pair programming Tdd testdriven development Workflow

Templates

Readme.standard

Tools and services

Access and permissions Purchasing licenses and memberships Sharing sensitive information Stack and services Wordpress
=

Project management

SLA

An SLA (Service Level Agreement) gives clients peace of mind, ensuring their solution is fully managed. In short, we handle updates, monitoring, and proactively address issues

Maintenance window goal

When we stop actively working on a project, the project moves to the maintenance phase. Any project that does not have a full-time team on it is considered to be on maintenance. The maintenance window goal is to ensure that the project does not go to a state where we would not want to work on it. The maintenance window also serves as a pragmatic way of bulking tasks to reduce context-switch. The maintenance window is not a tool for moving a project out of the legacy status nor to develop new functionality.

During a planned maintenance window, the DI team will perform tasks such as:

  • Update security vulnerabilities (by Dependabot).
  • Check the Asana board for any reported bugs and fix them.
  • Check error tracking tool and fix small issues. If the bugs are complex to solve, the team will inform the client.
  • Check the Asana board for any small prioritized task
  • Monitor app. Check metrics and add-ons and services. Are add-on plans correct? Do we need to upgrade resources?
  • Check the Asana board for chores.
  • Update programming language
  • Update the main framework
  • Update other libraries (most relevant first)
  • Create new tests

Note that it is not expected that the team performs all actions during a maintenance window. The team will assess what is the most important for the project.

SLAs are paid per hour. If a task cannot be completed on the scheduled maintenance window (like a major framework update, or a tricky bug), we will inform the client.

Estimating a maintenance window.

To get to a first estimate, the team may use a point system based on 4 common factors:

  • Frequent small changes requested
  • Large app
  • High traffic
  • Legacy code / Low test coverage

The project is classified depending on how many items are relevant to the project.

  • High maintenance: 3 or more items. 30 hours monthly
  • Medium maintenance: 2 items: 30 hours quarterly
  • Low maintenance: 0-1 items: 30 hours semi-annually.

The team working on the project should determine the relevant maintenance window based on all the information they have. The above method should be used as a reference, and it is a good conversation starter.

Scheduling the maintenance window

After the customer has approved the maintenance window, the PM will schedule a task on the Digital Infrastructure board.