commit c5abdc459008578f9ed28008c152370b8d81f77e
parent fd942ad7d6e2c74a46c3116ac224c94474fa1b82
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Wed, 15 Apr 2026 10:29:10 +0200
draft new support process
Diffstat:
3 files changed, 220 insertions(+), 1 deletion(-)
diff --git a/developer/taler-developer-manual.rst b/developer/taler-developer-manual.rst
@@ -234,7 +234,9 @@ We use the following conventions for the bug states:
* 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).
+ the feedback). If a bug is on feedback, it automatically should be
+ considered to be high-priority to give the feedback (as it is
+ blocking someone else!).
* ACKNOWLEDGED: The bug has been reviewed, but no decision about
what action to take has been made yet. Should not be worked on
diff --git a/system-administration/index.rst b/system-administration/index.rst
@@ -26,6 +26,7 @@ Internal System Administration
uptime-kuma
taler-monitoring-infrastructure
backups
+ support
prometheus
prometheus-alerts
nginx-prometheus-exporter
diff --git a/system-administration/support.rst b/system-administration/support.rst
@@ -0,0 +1,216 @@
+..
+ This file is part of GNU TALER.
+ Copyright (C) 2026 Taler Systems SA
+
+ TALER is free software; you can redistribute it and/or modify it under the
+ terms of the GNU Affero General Public License as published by the Free Software
+ Foundation; either version 2.1, or (at your option) any later version.
+
+ TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+ WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+ A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
+
+ You should have received a copy of the GNU Affero General Public License along with
+ TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
+
+ @author Christian Grothoff
+
+Support Process
+###############
+
+This chapter documents the main support proess for GNU Taler users.
+The goal is to ensure customers are kept in the loop and receive
+timely feedback and quality resolutions.
+
+
+Incoming
+========
+
+There are several ways how users may reach us for support:
+
+- Filing bugs at https://bugs.taler.net (Mantis)
+- Contacting us via e-mail, usually support@taler.net or
+ a dedicated support e-mail address of the respective
+ Taler operator.
+- Contacting us via e-mail at sales@taler.net or
+ a dedicated sales e-mail address of the respective
+ Taler operator. Those should soon be routed directly into the ERP.
+- Phone calls (usually to the respective Taler operator).
+ For these, we should eventually set up an automatic
+ cascade.
+
+The next steps depend a bit on the type of issue, channel used
+and the type of customer.
+
+Bugtracker
+----------
+
+If an issue was raised in the bugtracker, that is perfect and
+it basically immediately goes into the analysis stage.
+
+Support E-mail
+--------------
+
+If raised via e-mail, there recipient should do some initial
+triage.
+
+- If the request is likely to be an actionable bug in the documentation, software or
+ operations, a bug report should be filed on Mantis without personally
+ identifiable information about the user. If such information is critical to
+ the issue, it could be added as as a "private" note. If the issue could have
+ serious negative implications if disclosed to the public prematurely (like a
+ security problem on our end), it should be set to "private".
+- If the request relates to needs for onboarding and commercial support,
+ a record for the merchant or bank should be created in the ERP and
+ the communication added there (if the support e-mail did not already
+ arrive into the ERP). The process continues with the "Sales" stage.
+- If the support request is answered by existing documentation, the
+ e-mail should be answered by pointing to the existing documentation and
+ asking the user politely if that answers their question. If the user is
+ unhappy with the documentation or if them not finding it happens
+ frequently for a particular question, a bug should be opened indicating that
+ the documentation or its discoverability need to be improved.
+ (In this case, the user does NOT need to be pointed to that bug.)
+ If existing documentation does not answer the user, this is an
+ actionable bug (see above) and should be treated as a documentation
+ bug.
+
+Issues in the bugtracker added on behalf of customers
+should always be filed in state "new" and not already be assigned.
+They should be tagged with "Customer".
+
+
+Support phone
+-------------
+
+When receiving a customer call via phone, it is important to note the
+following:
+
+- Name of the customer
+- Type of customer (user, merchant, bank, other?)
+- Contact information (e-mail? phone number!)
+- Anything about the actual issue
+- Date of the call
+
+These should be added to the bug tracker (if we have a problem) or
+the ERP (if related to onboarding / sales) respectively.
+
+During the first phone call, focus on listening to the customer to make sure
+you understand their issue as best as you can. You may point them already to
+existing documentation, but should not promise that particular issues will be
+fixed or within a certain timeline unless you are very sure that the timeline
+can be met and will have management approval. If in doubt, you may forward
+the customer to management.
+
+
+Sales E-mail
+------------
+
+Sales E-mails should be added to the ERP under the respective customer.
+The process then continues with the "Sales" stage.
+
+
+Sales
+=====
+
+The sales process follows the usual ERP processes from leads to conversion. In
+general, it is important to identify blockers for the customer (such as
+missing features) early on and to proceed once we are ready to follow through.
+
+If technical issues (incl. feature requests) arise during the sales process,
+management should be consulted about making a commercial offer, addressing the
+issue gratis, or refusing to address the request. If the customer accepts the
+offer (or if management decided to address it gratis), a respective issue
+should be opened on the bug tracker.
+
+
+Analysis
+========
+
+Initial analysis of all incoming bugs is generally done by the management;
+some executive will look over NEW bugs and assign a priority and set a staff
+member to look into the issue. Developers may self-assign ("grab") incoming
+issues that are clearly in their domain if they consider them clearly urgent
+and suitable for fast resolution. However, any interference with customer
+accounts or data (such as re-setting passwords) always requires prior
+assignment of the issue to the staff member by management.
+
+The bug is first set to "feedback". At this stage, the developer MUST urgently
+respond if the problem (and path to resolution) is clear, and what they think
+is a realistic and conservative (!) timeline for fixing the issue. If the
+issue is complex and likely to require changes in other subsystems, sub-bugs
+may need to be opened by the developer, which may in turn require feedback
+from other developers as well (so they should be assigned with "feedback" to
+the other developers). After the feedback has been collected, the bug status
+should be set back to "NEW". This even applies if the developer already fixed
+the issue; if the issue has aready been resolved it should be noted where (in
+Git? in testing? in production? which version?).
+
+Afterwards, management will determine a timeline for resolution based on the
+feedback and either directly respond to the reporter or ask a suitable staff
+member to communicate a response to the user (for reports received via phone
+or e-mail). In general, the user must receive an answer that we are
+"investigating the issue" including a link to the bug (unless it is set to
+"private" and would thus not be visible to the user). The bug(s) are set to
+"confirmed" and the request then proceeds to the action stage.
+
+
+Action
+======
+
+Staff generally promote tasks from "confirmed" to "assigned" when they start
+to work on them. In general, this should happen by checking the target release
+and/or bug priority, but developers may have good reasons (context,
+dependencies, etc.) to make adjustments. If it becomes likely (!) that
+deadlines cannot be met, staff will put this in writing with the impacted
+issues. In general, the subject of the bug should contain the amount of time
+needed that is left for fixing the issue, and a deadline ([4h,
+14.3.2034]). These numbers should be updated whenever predictions change or
+work progresses.
+
+After the developer has fixed the issue, they draft a response to the customer
+as a bug note. The general tone of the response should always be "we fixed",
+not "I fixed", never put any blame on the user, and acknowledge mistakes
+appropriately. The issue should then be scheduled for review by assigning the
+bug to another staff member for "feedback".
+
+
+Review
+======
+
+When receiving a (presumably) resolved bug for feedback, the staff member is
+supposed to try to reproduce the original issue and check if is now
+absent. This may again require sub-tasks such as packaging and deployment
+(into staging systems) to be performed. Review does not have to be done in a
+big QC session, but especially for complex issues it is recommended to look
+into them during a QC session.
+
+If the issue is not addressed fully, it should go back into the "Action"
+stage, otherwise it is assigned (status: assigned) to the staff member
+responsible for communicating the resolution to the customer. It should be
+noted that this only applies to bugs opened by customers, if no customer is
+involved the bug may simply be marked as "resolved" directly.
+
+
+Resolution
+==========
+
+In this phase, the same staff member (if possible) who responded to the
+customer during the analysis phase writes a brief notification to the customer
+about the issue having been fixed based on the draft provided by the
+developer. Depending on the customer, this may happen after confirmed fix is
+in Git, deployed to staging or is available in production. The staff member
+should consider when to send out the notification on a case-by-case basis, but
+in general earlier is better as long as the infomation is useful for the
+customer. Technical information may be shared, but the amount of sharing
+should be tailored to what we believe the customer would want to comprehend.
+
+If the issue originated from a sales process, the ERP must also be
+updated and (if applicable) the invoicing / billing process be
+initiated. In this case, the response should be sent via the ERP.
+
+Afterwards the issue should be marked as "resolved" and is finally closed
+by management with the next release cycle.
+
+
+
