Skip to content
Matthew Maxwell edited this page Mar 22, 2022 · 1 revision

Learn how we are using Issues in Firefly to manage our work and tasks. Anybody is free to create an issue, but we ask everyone to follow this guide; keeping the project organised and maintainable.

You will find a rota of official IF developers assigned to monitoring and triaging new issues for a given week here: Issues Triage Guide. Feel free to reach out to the developers directly on discord to discuss your issue.

Opening Issues

When to open an issue

An issue should represent a discrete piece work that that requires effort to close. I.e. a task to implement a new feature or a bug to debug and squash. Therefor, we ask that an issue is only opened for work that will be done.

We are currently using issues to manage:

  • developer related tasks
  • ux related tasks
  • bugs reports that need investigating

When not to open an issue

Issues are not being used to manage:

  • feature requests
  • support requests
  • feedback
  • general discussions

Please use Discussions to discuss any of the above.

Please don't open an issue for security vulnerabilities, instead visit our security policy to responsibly disclose.

Creating a new issue

First visit our open issues and search to make sure the issues doesn't already exist. If you find that the issue already exists, feel free to leave a comment and add to the discussion.

If the issue does not exist, then create a new issue filling in the respective template, and assign the appropriate labels and priority level.

We ask that all issues are written in English.

Issue Priority

We can use the below priority levels to categorize issues:

  • Priority 1: A complete application down situation or single critical system down with potentially high financial impact.
  • Priority 2: A major component of the user's ability to operate the application is affected. Some aspects of the application can continue but it's a major problem.
  • Priority 3: The core functionality is unaffected but the issue is affecting efficient operation by one or more people.
  • Priority 4: The issue is an inconvenience or annoying but there are clear workarounds or alternates.
  • Priority 5: The issue is a background or planned task and will be addressed when time permits or on the planned date.

Use the below matrix to help you determine the priority level of an issue:

High Urgency Medium Urgency Low Urgency
High Impact Priority 1 Priority 1 Priority 2
Medium Impact Priority 2 Priority 3 Priority 3
Low Impact Priority 3 Priority 4 Priority 4

Issue Labels

Please ensure all issues have a type label, additional labels can be added where deemed appropriate.

Type Labels

Type labels describe the kind of workbeing done in the issue or PR:

  • type:chore: Housekeeping-like tasks such as modifying dependencies
  • type:documentation: Add or update documentation
  • type:enhancement: Enhancement of an existing feature
  • type:feature: Adding a new feature or functionality
  • type:fix: Fix for a bug
  • type:hotfix: Hotfix for a bug
  • type:refactor: Refactoring existing code
  • type:tests: Add or modify tests
  • type:ux:concept: To design concepts as part of discovery
  • type:ux:design: To design part of the product
  • type:ux:support: To support developer implementing a design
  • type:ux:validation: To validate previous designs

Platform Labels

Platform labels indicate if this issue or PR is for a specific platform:

  • platform:desktop: Desktop application
  • platform:mobile: Mobile application
  • platform:web: Web application

Context Labels

Context labels indicate which part of the application this issue or PR is about:

  • context:onboarding: Onboarding
  • context:navigation: Navigation
  • context:settings: Settings
  • context:wallet: Wallet tab
  • context:staking: Staking tab
  • context:voting: Voting tab

Priority Labels

Priority labels describe the immediacy of attention required for issues and PRs:

  • priority:1: Priority level 1
  • priority:2: Priority level 2
  • priority:3: Priority level 3
  • priority:4: Priority level 4
  • priority:5: Priority level 5

Status Labels

Status labels help to describe the decision state of the issue or pull request:

  • status:approved: This issue or pull request has been approved
  • status:blocked: The issue or pull request is blocked
  • status:donotmerge: Do not merge this pull request
  • status:duplicate: This issue or pull request already exists
  • status:inactive: The issue or pull request is inactive or stale
  • status:invalid: The issue or pull request is not valid
  • status:wontfix: This issue will not be worked on

Package Labels

Package labels can be used if you want to indicate which areas of the code base have been affected; useful for refactoring tasks:

  • package:backend: Affects shared package
  • package:core: Affects shared package
  • package:common: Affects shared package
  • package:desktop: Affects UX
  • package:mobile: Affects UX
  • package:shared: Affects shared package

OS Labels

Labels for each of the OS we support can be used to add further context; specifically if a bug is only affecting some operating systems:

  • os:android: Affects Android
  • os:ios: Affects
  • os:linux: Affects Linux
  • os:mac: Affects MacOS
  • os:windows: Affects windows

Scope

Additional scope labels:

  • scope:ci: Affects CI tasks
  • scope:dependencies: Affects dependencies
  • scope:ledger: Affects ledger
  • scope:security: Affects security

Auxiliary Labels

Other labels not related to development tasks:

  • bug report: Something isn't working as intended and needs investigating or fixing
  • support request: Support request from user
  • good first issue: Good for newcomers
  • help wanted: Help the team improve Firefly

Working on Issues

When working on an issue you need to:

  • Assign yourself to the issue
  • Ensure labels are correct
  • Ensure priority level is correct

Closing Issues

When to close an issue

Close an issue and guide author to correct place; if:

  • The issue is a feature requests, feedback, or general discussions
  • The issue is a disclosure of a security vulnerability

Close a task issue labeled feat, enhancement, refactor or chore etc.; if:

  • The task has been completed and associated PR has been merged
  • The task will no longer be completed and deemed unnecessary
  • The task is a duplicate of an existing issue

Close an issue labeled bug report; if:

  • The bug has been fixed and associated PR has been merged
  • The bug will not be fixed
  • The investigation is complete and bug is deemed not repeatable