commit 59c5bb0f2004eed2c7432100aea54c1b4d337500
parent 99ac48e1e36b60facc27f84bc50d525be429a42e
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 22 Apr 2025 14:05:43 +0200
summarize mantis discussion
Diffstat:
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
@@ -1416,7 +1416,7 @@ Getting statistics
**Request:**
:query by: *Optional*. If set to "BUCKET", only statistics by bucket will be returned. If set to "INTERVAL", only statistics kept by interval will be returned. If not set or set to "ANY", both will be returned.
-
+
**Response:**
:http:statuscode:`200 Ok`:
@@ -1663,10 +1663,12 @@ KYC status checks
// o "no-exchange-keys": we do not (yet) have the /keys of the exchange
// - "kyc-wire-impossible": KYC auth transfer needed but not possible
// @ "kyc-wire-required": KYC auth transfer still needed and possible
- // @ "kyc-required": merchant must supply KYC data to proceed
+ // @ "kyc-required": merchant must supply KYC data to proceed (incl.
+ // in case of exposed zero-limits on deposit/aggregation)
// + "awaiting-aml-review": account under review by payment provider
// + "ready": everything is fine, account can be fully used
// - "logic-bug": merchant backend logic bug
+ // o "merchant-internal-error": merchant had an internal error
// o "exchange-internal-error": exchange had an internal error
// o "exchange-gateway-timeout": network timeout at gateway
// o "exchange-unreachable": exchange did not respond at all
diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst
@@ -200,6 +200,63 @@ is available at `<https://bugs.taler.net>`_. A registration on the Web site is
needed in order to use the bug tracker, only read access is granted without a
login.
+We use the following conventions for the bug states:
+
+* NEW: Incoming bugs are in 'new' so that management (or developers)
+ can easily identify those that need to be checked (report correct?
+ something we want to fix?), prioritized and targeted for releases.
+ "NEW" bugs are never assigned to a developer.
+
+* FEEDBACK: When blocked on feedback from reporter or other developer.
+ Assigned to other developer (but cannot be assigned to reporter,
+ in this case MAY remain associated with the developer who expects
+ the feedback).
+
+* ACKNOWLEDGED: The bug has been reviewed, but no decision about
+ what action to take has been made yet. Should not be worked on
+ until management (or a developer) comes up with a plan.
+ "ACKNOWLEDGED" bugs should NOT be assigned to a developer.
+
+* CONFIRMED: This is a real issue that should be worked on, but
+ is not yet actively worked on. If working on this bug requires
+ other bugs to be fixed first, they should be added as
+ child-bugs (via relationships). Developers are always welcome
+ to self-assign bugs that are "CONFIRMED" if they start to work
+ on a bug. "CONFIRMED" bugs should NOT be assigned to a developer.
+
+* ASSIGNED: The specific developer the bug is assigned to is
+ **actively** working on the issue. Developers should strive to
+ not have more than 5-10 bugs assigned to them at any time.
+ Only having one assigned to you is totally OK!
+ Developers should aggressively un-assign bugs that they are
+ blocked on, cannot make progress on, or are no longer actively
+ working on (but of course, better *resolve* them before
+ moving on if possible). If the bug remains open, it probably
+ should go back to "CONFIRMED" or "ACKNOWLEDGED".
+
+* RESOLVED: The bug has been fixed in Git.
+
+* CLOSED: An official release was made with the fix in it.
+
+When developers want to keep an eye on certain bugs, they should
+**monitor** them. Multiple developers can be monitoring a bug, but
+it can only be assigned to one. Developers should also keep an
+eye on the roadmap (by release), bug categories they care about,
+and of course priorities / severities.
+
+We use **tags** to categorize bugs. Common tags that also imply
+some urgency include (in alphabetical order):
+
+* accounting: issues required for accounting (such as taxes by merchants)
+* compliance: issues related to regulatory compliance
+* $CUSTOMER: issues requested by a particular customer
+* performance: performance problems or ideas for improvement
+* security: security issues (including planned improvements to security)
+* UX: user experience issues
+
+These tags **should** be attached to "NEW" bugs if they apply.
+
+
Code Repositories
-----------------
