Skip to content

Developer experience maintenance process

Ondřej Chrastina edited this page Jan 6, 2022 · 16 revisions

Developer experience maintenance process

Draft

This document describes the process of repositories maintained by @Kentico/developer-experience team.

Some team members have a dedicated "maintenance day" in their workload for handling basic operative work and issue triage. These primary contacts are mentioned explicitly in the CODEOWNERS file. This group of people is called "DevEx OS maintainers".

All Repository Maintainer duties applies for DevEx OS maintainers.

GitHub Issues

Every issue submitted to the repository maintained by DevEx OS maintainers has to be triaged.

Triage

Triage means understanding what the issue is about and deciding whether this is a bug, feature request, or invalid.

Before triage, the maintainer is communicating with the submitter to state that the issue is comprehensible (maintainer is able to describe the issue).

The issue can be resolved as:

  • Valid
    • Small enough - it is possible to handle the issue in the "maintainers day"
    • Out of "maintenance day" scope
      • Bug - the bug will be filed in the internal tracking system (Jira) as an "ad-hoc" task. These ones are prioritized on weekly basis.
      • New feature - the feature request will be filed as in the internal tracking system (Jira) and prioritized against other product features priorities. <DEFINE HOW TO PRIORITIZE - grooming? PO meeting?>
    • Waiting for traction - the issue will remain open with comment informing the issue is waiting for traction.
  • Invalid - the issue was decided not to be implemented.

Every state decision has to be explained in the comments.

Sync

DevEx OS maintainers are attending regular weekly sync meetings with the DevRel leader to share an update between each other about issue statuses. This platform also works as a fallback when issue triage is complicated. This might lead to a longer response time.