support.rst (9500B)
1 .. 2 This file is part of GNU TALER. 3 Copyright (C) 2026 Taler Systems SA 4 5 TALER is free software; you can redistribute it and/or modify it under the 6 terms of the GNU Affero General Public License as published by the Free Software 7 Foundation; either version 2.1, or (at your option) any later version. 8 9 TALER is distributed in the hope that it will be useful, but WITHOUT ANY 10 WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR 11 A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. 12 13 You should have received a copy of the GNU Affero General Public License along with 14 TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/> 15 16 @author Christian Grothoff 17 18 Support Process 19 ############### 20 21 This chapter documents the main support proess for GNU Taler users. 22 The goal is to ensure customers are kept in the loop and receive 23 timely feedback and quality resolutions. 24 25 26 Incoming 27 ======== 28 29 There are several ways how users may reach us for support: 30 31 - Filing bugs at https://bugs.taler.net (Mantis) 32 - Contacting us via e-mail, usually support@taler.net or 33 a dedicated support e-mail address of the respective 34 Taler operator. 35 - Contacting us via e-mail at sales@taler.net or 36 a dedicated sales e-mail address of the respective 37 Taler operator. Those should soon be routed directly into the ERP. 38 - Phone calls (usually to the respective Taler operator). 39 For these, we should eventually set up an automatic 40 cascade. 41 42 The next steps depend a bit on the type of issue, channel used 43 and the type of customer. 44 45 Bugtracker 46 ---------- 47 48 If an issue was raised in the bugtracker, that is perfect and 49 it basically immediately goes into the analysis stage. 50 51 Support E-mail 52 -------------- 53 54 If raised via e-mail, there recipient should do some initial 55 triage. 56 57 - If the request is likely to be an actionable bug in the documentation, software or 58 operations, a bug report should be filed on Mantis without personally 59 identifiable information about the user. If such information is critical to 60 the issue, it could be added as as a "private" note. If the issue could have 61 serious negative implications if disclosed to the public prematurely (like a 62 security problem on our end), it should be set to "private". 63 - If the request relates to needs for onboarding and commercial support, 64 a record for the merchant or bank should be created in the ERP and 65 the communication added there (if the support e-mail did not already 66 arrive into the ERP). The process continues with the "Sales" stage. 67 - If the support request is answered by existing documentation, the 68 e-mail should be answered by pointing to the existing documentation and 69 asking the user politely if that answers their question. If the user is 70 unhappy with the documentation or if them not finding it happens 71 frequently for a particular question, a bug should be opened indicating that 72 the documentation or its discoverability need to be improved. 73 (In this case, the user does NOT need to be pointed to that bug.) 74 If existing documentation does not answer the user, this is an 75 actionable bug (see above) and should be treated as a documentation 76 bug. 77 78 Issues in the bugtracker added on behalf of customers 79 should always be filed in state "new" and not already be assigned. 80 They should be tagged with "Customer". 81 82 83 Support phone 84 ------------- 85 86 When receiving a customer call via phone, it is important to note the 87 following: 88 89 - Name of the customer 90 - Type of customer (user, merchant, bank, other?) 91 - Contact information (e-mail? phone number!) 92 - Anything about the actual issue 93 - Date of the call 94 95 These should be added to the bug tracker (if we have a problem) or 96 the ERP (if related to onboarding / sales) respectively. 97 98 During the first phone call, focus on listening to the customer to make sure 99 you understand their issue as best as you can. You may point them already to 100 existing documentation, but should not promise that particular issues will be 101 fixed or within a certain timeline unless you are very sure that the timeline 102 can be met and will have management approval. If in doubt, you may forward 103 the customer to management. 104 105 106 Sales E-mail 107 ------------ 108 109 Sales E-mails should be added to the ERP under the respective customer. 110 The process then continues with the "Sales" stage. 111 112 113 Sales 114 ===== 115 116 The sales process follows the usual ERP processes from leads to conversion. In 117 general, it is important to identify blockers for the customer (such as 118 missing features) early on and to proceed once we are ready to follow through. 119 120 If technical issues (incl. feature requests) arise during the sales process, 121 management should be consulted about making a commercial offer, addressing the 122 issue gratis, or refusing to address the request. If the customer accepts the 123 offer (or if management decided to address it gratis), a respective issue 124 should be opened on the bug tracker. 125 126 127 Analysis 128 ======== 129 130 Initial analysis of all incoming bugs is generally done by the management; 131 some executive will look over NEW bugs and assign a priority and set a staff 132 member to look into the issue. Developers may self-assign ("grab") incoming 133 issues that are clearly in their domain if they consider them clearly urgent 134 and suitable for fast resolution. However, any interference with customer 135 accounts or data (such as re-setting passwords) always requires prior 136 assignment of the issue to the staff member by management. 137 138 The bug is first set to "feedback". At this stage, the developer MUST urgently 139 respond if the problem (and path to resolution) is clear, and what they think 140 is a realistic and conservative (!) timeline for fixing the issue. If the 141 issue is complex and likely to require changes in other subsystems, sub-bugs 142 may need to be opened by the developer, which may in turn require feedback 143 from other developers as well (so they should be assigned with "feedback" to 144 the other developers). After the feedback has been collected, the bug status 145 should be set back to "NEW". This even applies if the developer already fixed 146 the issue; if the issue has aready been resolved it should be noted where (in 147 Git? in testing? in production? which version?). 148 149 Afterwards, management will determine a timeline for resolution based on the 150 feedback and either directly respond to the reporter or ask a suitable staff 151 member to communicate a response to the user (for reports received via phone 152 or e-mail). In general, the user must receive an answer that we are 153 "investigating the issue" including a link to the bug (unless it is set to 154 "private" and would thus not be visible to the user). The bug(s) are set to 155 "confirmed" and the request then proceeds to the action stage. 156 157 158 Action 159 ====== 160 161 Staff generally promote tasks from "confirmed" to "assigned" when they start 162 to work on them. In general, this should happen by checking the target release 163 and/or bug priority, but developers may have good reasons (context, 164 dependencies, etc.) to make adjustments. If it becomes likely (!) that 165 deadlines cannot be met, staff will put this in writing with the impacted 166 issues. In general, the subject of the bug should contain the amount of time 167 needed that is left for fixing the issue, and a deadline ([4h, 168 14.3.2034]). These numbers should be updated whenever predictions change or 169 work progresses. 170 171 After the developer has fixed the issue, they draft a response to the customer 172 as a bug note. The general tone of the response should always be "we fixed", 173 not "I fixed", never put any blame on the user, and acknowledge mistakes 174 appropriately. The issue should then be scheduled for review by assigning the 175 bug to another staff member for "feedback". 176 177 178 Review 179 ====== 180 181 When receiving a (presumably) resolved bug for feedback, the staff member is 182 supposed to try to reproduce the original issue and check if is now 183 absent. This may again require sub-tasks such as packaging and deployment 184 (into staging systems) to be performed. Review does not have to be done in a 185 big QC session, but especially for complex issues it is recommended to look 186 into them during a QC session. 187 188 If the issue is not addressed fully, it should go back into the "Action" 189 stage, otherwise it is assigned (status: assigned) to the staff member 190 responsible for communicating the resolution to the customer. It should be 191 noted that this only applies to bugs opened by customers, if no customer is 192 involved the bug may simply be marked as "resolved" directly. 193 194 195 Resolution 196 ========== 197 198 In this phase, the same staff member (if possible) who responded to the 199 customer during the analysis phase writes a brief notification to the customer 200 about the issue having been fixed based on the draft provided by the 201 developer. Depending on the customer, this may happen after confirmed fix is 202 in Git, deployed to staging or is available in production. The staff member 203 should consider when to send out the notification on a case-by-case basis, but 204 in general earlier is better as long as the infomation is useful for the 205 customer. Technical information may be shared, but the amount of sharing 206 should be tailored to what we believe the customer would want to comprehend. 207 208 If the issue originated from a sales process, the ERP must also be 209 updated and (if applicable) the invoicing / billing process be 210 initiated. In this case, the response should be sent via the ERP. 211 212 Afterwards the issue should be marked as "resolved" and is finally closed 213 by management with the next release cycle. 214 215 216