Skip to content

Development process

Marco Visser edited this page May 24, 2023 · 4 revisions

Introduction

Welcome to the issue tracking process for the Firely Team. This document outlines how we handle bugs and enhancements reported by both our team and external GitHub users.

Issues

When we refer to "issues," we are referring to bugs or enhancements that are identified within our code base. These issues can be reported by the Firely team or any external GitHub user. To report an issue, please navigate to the issues tab on our GitHub repository and click on the "New Issue" button. You will then be presented with two options:

  1. Bug report: Use this option if something within the code is not functioning as expected.
  2. Feature request: Choose this option if you have a new idea or suggestion for our code base.

Once an issue is reported, it is automatically added to our GitHub project board's backlog, which can be found here. It is the responsibility of the SDK team to review, accept, and prioritize these issues accordingly.

Issues that are indicated with the Firely Favorite label will have priority above other issues. This label can only be set by a member of the Firely team.

Meetings

Standup

Every week on Thursday morning the SDK team has 1 hour standup, where we discuss the process of the current sprint and

Refinement

Retrospective

Pull Request

For every change to the develop branch there have to be a pull request (PR). When a pull request (PR) is ready, it can be reviewed and merged by another member of the SDK team immediately. However, if a PR is in draft status, you can ignore it as a reviewer. The author will remove the draft status when they believe the PR is ready for production and should be reviewed.

For small PRs that you would like to have reviewed promptly (because you're waiting on them), please inform us in the firely-net-sdk-standup Slack channel.

When the reviewer is not satisfied or needs extra information, he/she will inform the author by setting the PR to Request Changes state. This is the trigger for the author of the PR to change his/her PR.

When the reviewer is content with the PR, he/she approves the PR and merge the changes into the target branch (mostly develop).

Make sure as an author that you provide the following information about the PR:

  • a short title of the new functionality or bug fix. This title will later be included in the release notes.
  • which issue is this PR relates to? Use format: This PR resolves #1234
Clone this wiki locally