Skip to content

Developer experience maintenance process

Jump to bottom
Ondřej Chrastina edited this page Jan 31, 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.

Triage

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

Triage means understanding what the issue is about and decide 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 (the 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 a "bug" task. These ones are prioritized on weekly basis. Just keep in mind bug priority is affected by the project License (which is MIT).
      • New feature - the feature request will be filed as an issue in GitHub, grouped using GitHub Milestones, and prioritized against other product feature priorities.
        • New feature in the REST API - see (New REST API feature)[#new-rest-api-feature]
    • 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.

New REST API features

SDK implementation is part of the feature opportunity. The new functionality should be covered by tests and reviewed by the maintainers (ideally primary contact) defined in the CODEOWNERS file in the SDK repo.

Ideal process of the submission

Let's image a new entity in Kontent - let's call it a "note". As a part of the opportunity, the development team wants to introduce new endpoints connected to this entity to Delivery REST API (to allow fetching user's notes) and adjust one other endpoint connected to the new entity - user entity will have a list of notes' IDs in the response. The ideal workflow would look like this:

  • Development team decide to implement new opportunity
  • Dev team contact the maintainers of the respective SDKs. In this case .NET and JS SDKs.
    • They introduce the idea to the maintainer to get early feedback and information about SDK implementation.
  • Once the feature is defined and the REST API contract is known (not implemented), the development team submits the GitHub issue based on feature request template describing the new feature and assigns people for implementing it.
  • After the implementation part is done - the maintainer will handle the release process.

Implementation checklist

Based on https://github.com/Kentico/repo-template/blob/master/.github/PULL_REQUEST_TEMPLATE.md

  • Code follows coding conventions held in this repo
  • Automated tests have been added
  • Ideal state is to have the code fully covered (happy and unhappy path).
  • Sufficient state is that happy path is covered.
  • We do not test implementation of the REST API itself, it is possible to use Mocked server responses.
  • Repositories might contain tests for Documentation code samples
  • Docs have been updated
    • If new functionality in REST API is being showcased in API reference - provide code samples
    • Validate whether there is a need for adjusting README
  • Temporary settings (e.g. variables used during development and testing) have been reverted to defaults
    • no sensitive keys have been committed to the codebase
    • no temporary project ID is being set in the pull request

Release process

The release process consists of two steps:

  1. Publishing new version on the package manager (in .NET case it is Nuget)
  2. Ensuring the proper announcement
  • New feature is described in release changelog
  • Decide whether to announce new version in product changelog/discord/newsletter
  • If there are any new code samples to be published - create a pull request for Docs code samples repository
Clone this wiki locally