Skip to content

Development process

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

Introduction

Welcome to the issue tracking and pull request (PR) process for the Firely Team. This document provides an overview of how we handle issues, meetings, and PRs within our development workflow.

Issues

When we mention "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 visit the issues tab on our GitHub repository and click on the "New Issue" button. You will be presented with two options:

  1. Bug report: Select this option if there is unexpected behavior or malfunctioning code.
  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 accessed here. The SDK team is responsible for reviewing, accepting, and prioritizing these issues accordingly.

Issues labeled as "Firely Favorite" will receive priority over other issues. Only members of the Firely team can assign this label.

Meetings

Standup

Every Thursday morning, the SDK team holds a one-hour standup meeting to discuss the progress of the current sprint and any related updates.

Refinement

[Still to come]

Retrospective

[Still to come]

Pull Request

Every change made to the develop branch must go through a pull request (PR) process. When a PR is ready, it can be reviewed and merged by another member of the SDK team. However, if a PR is marked as a draft, reviewers can disregard it. The author will remove the draft status when they believe the PR is ready for production and requires review.

If you have small PRs that require prompt review (due to waiting on them), please notify us in the firely-net-sdk-standup Slack channel.

When a reviewer is dissatisfied with or requires additional information regarding a PR, they will set the PR to the "Request Changes" state. This prompts the author of the PR to make the necessary modifications.

Once a reviewer is satisfied with a PR, they will approve it and merge the changes into the target branch, typically develop.

As the author, please ensure you provide the following information about the PR:

  • A concise title describing the new functionality or bug fix. This title will be included in the release notes.
  • Indicate which issue the PR resolves using the format: This PR resolves #1234.
  • A description of the new functionality or bug fix.
  • Which unit tests are created or used to prove the stability of the PR.

Code Style

[still to come]

Clone this wiki locally