Difference between revisions of "Critical bugs"

From Bisq Wiki
Jump to navigation Jump to search
m
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page explains what critical bugs are and covers the workflow for devs willing to solve them.
+
This article explains what '''critical bugs''' are and covers the process for identifying and fixing them.
 +
 
 
__TOC__
 
__TOC__
  
== What are [[Glossary#Critical_Bug|critical bugs]]? ==
+
== What is a critical bug? ==
 
 
Starting with our dev budget, we will focus in a first step on our most critical ''[[Glossary#Core_use_case|core use cases]]''. A ''core use case'' is any set of actions that a user must be able to complete in order to successfully trade and/or manage funds using Bisq.
 
  
A '''critical bug''' is any bug or other issue that:
+
A [[Glossary#Critical_bug|critical bug]] is any bug or other issue that:
  
* impedes users from completing a core use case in Bisq, and/or
+
* impedes users from completing a [[Glossary#Core_use_case|core use case]] in Bisq, and/or
 
* repeatedly lands users in support, and/or
 
* repeatedly lands users in support, and/or
 
* puts user funds or privacy at risk
 
* puts user funds or privacy at risk
  
Bisq maintainers will scan every day the [https://github.com/bisq-network/bisq/issues issues] within the Bisq repository and apply the label '''is:critical bug''' to all issues that fit the description above.
+
Critical bugs are by definition among the most important and highest priority tasks that can be worked on. The goal is to have zero outstanding critical bugs at any given time. Bisq developers should therefore consider working on critical bugs ahead of anything else.
Afterwards they are move to the [https://github.com/orgs/bisq-network/projects/7 critical bugs board] and sorted by priority.
+
 
 +
== Infrastructure ==
 +
 
 +
=== Board ===
 +
 
 +
The critical bugs board can be found at https://github.com/orgs/bisq-network/projects/7.
 +
 
 +
[[File:Critical Bugs Board.png|400px|right|thumb|Critical bugs board]]
 +
 
 +
== Process ==
 +
 
 +
=== Identification ===
 +
 
 +
Bisq maintainers are notified of new issues as they arrive in the [https://github.com/bisq-network/bisq/issues Bisq repository] and should apply the <code>[https://github.com/bisq-network/bisq/labels/is%3Acritical is:critical]</code> label to any issue that fits the definition above.
 +
 
 +
Immediately after labeling a critical bug, the Bisq maintainer should add that issue to the <code>To do</code> column of the board, sorting the issue according to its priority relative to the other issues in that column.
  
[[File:Critical Bugs Board.png|none|1105]]
+
=== Notification ===
  
== I want to work on a critical bug ==
+
''Note (@cbeams): We may want to have maintainers add a comment to newly-indentified critical bugs mentioning <code>@bisq-network/bisq-devs</code> and <code>@bisq-network/support</code> so that those groups are made aware of the issue and are automatically subscribed to any updates on it. @ripcurlx to decide and update this section accordingly.''
  
If you want to tackle one of this important issues please leave a comment that you want to work on it to get officially assigned.
+
=== Assignment ===
  
[[File:Assigned issue.png|none|353]]
+
If you are a developer interested in working on a given critical bug, you should add a comment to the issue asking to be assigned to it. A Bisq maintainer will follow up with you and make the assignment as appropriate and will transition the issue to the <code>In progress</code> column of the board. You should then proceed to put together a pull request that fixes the bug as per the usual [[Development Process]].
  
We do want to prevent that people are working on the same problem at the same time.
+
Once assigned to a critical bug, you should post comments on the issue indicating your progress and post [[standup]] updates about it each day you work on it. This allows other developers to help out if need be and keeps everyone in the loop. These updates also serve as documentation when you submit a compensation request for your work.
When you start working please also to post status updates in our #standup channel on Keybase and do post update comments on your investigations within the issue. This enables other devs to help out if there is need be.
 
Also it is additional documentation on your progress and efforts when you want to post your compensation request.
 
  
== Do I get compensated by the DAO? ==
+
If you stop working on a critical bug before it has been fixed, you should indicate that explicitly via comment on the issue so the maintainer can remove your assignment and transition the issue back to <code>To do</code> as appropriate.
  
Delivered work on critical bugs is up for compensation.
+
=== Compensation ===
In this case delivered work could mean one of the following:
 
* the bug was solved and the fix is merged into master
 
* the bug was investigated and solution is documented, but can't be fixed right now because of an external dependency (e.g. JDK/OpenJFX update required)
 
  
[[Category:Stubs]]
+
[[Glossary#Delivered|Delivered]] work on critical bugs is eligible for [[compensation]] under the Bisq DAO. In this case, delivered work could mean one of the following:
 +
 
 +
* the bug was fixed and the associated pull request has been merged into master
 +
* the bug was investigated and a fix has been documented, but cannot be implemented due to an external dependency e.g.: a JDK / OpenJFX update is required.
 +
 
 +
[[Category:Infrastructure]]
 
[[Category:Processes]]
 
[[Category:Processes]]
[[Category:Infrastructure]]
 

Latest revision as of 05:32, 19 June 2020

This article explains what critical bugs are and covers the process for identifying and fixing them.

What is a critical bug?

A critical bug is any bug or other issue that:

  • impedes users from completing a core use case in Bisq, and/or
  • repeatedly lands users in support, and/or
  • puts user funds or privacy at risk

Critical bugs are by definition among the most important and highest priority tasks that can be worked on. The goal is to have zero outstanding critical bugs at any given time. Bisq developers should therefore consider working on critical bugs ahead of anything else.

Infrastructure

Board

The critical bugs board can be found at https://github.com/orgs/bisq-network/projects/7.

Critical bugs board

Process

Identification

Bisq maintainers are notified of new issues as they arrive in the Bisq repository and should apply the is:critical label to any issue that fits the definition above.

Immediately after labeling a critical bug, the Bisq maintainer should add that issue to the To do column of the board, sorting the issue according to its priority relative to the other issues in that column.

Notification

Note (@cbeams): We may want to have maintainers add a comment to newly-indentified critical bugs mentioning @bisq-network/bisq-devs and @bisq-network/support so that those groups are made aware of the issue and are automatically subscribed to any updates on it. @ripcurlx to decide and update this section accordingly.

Assignment

If you are a developer interested in working on a given critical bug, you should add a comment to the issue asking to be assigned to it. A Bisq maintainer will follow up with you and make the assignment as appropriate and will transition the issue to the In progress column of the board. You should then proceed to put together a pull request that fixes the bug as per the usual Development Process.

Once assigned to a critical bug, you should post comments on the issue indicating your progress and post standup updates about it each day you work on it. This allows other developers to help out if need be and keeps everyone in the loop. These updates also serve as documentation when you submit a compensation request for your work.

If you stop working on a critical bug before it has been fixed, you should indicate that explicitly via comment on the issue so the maintainer can remove your assignment and transition the issue back to To do as appropriate.

Compensation

Delivered work on critical bugs is eligible for compensation under the Bisq DAO. In this case, delivered work could mean one of the following:

  • the bug was fixed and the associated pull request has been merged into master
  • the bug was investigated and a fix has been documented, but cannot be implemented due to an external dependency e.g.: a JDK / OpenJFX update is required.