Reporting of critical incidents that occur in internal test flights is crucial for tracking our product reliability and should be done through Hubspot tickets.
When?
- The incident has to be ‘user-relevant’, meaning that there is NO clear evidence that it was caused by unreleased code or hardware.
Note that by default all CT flights and InOp flights are counted towards our reliability statistics. Any other flight campaigns with a significant number of flights and a user-relevant setup are also added manually. - Every incident that falls into the criticality levels 1-4 has to be reported on Hubspot. (Not familiar with criticality levels?)
- Guidlines for reporting:
- A single incident should have a single ticket and vice versa!
- Please report within 1 week of the incident occurrence!
Who?
Everyone can and should open a ticket if it fulfils the above criteria, but there is one main responsible to keep an overview and make sure no incident in their domain is left unreported.
- CT flights: Alex & Yi Hao
- InOp flights / P&I: Fabian
- HW Dev flights: Jonas / Constantin
- SW Dev flights: Youssef
How?
- Create a new ticket on Hubspot, by the orange button on the top right.
- Make sure the following fields are filled in as follows:
- Ticket name: "[CT] Short description"
Please use [CT], [InOp] or [Dev] for better visibility of internal tickets - Pipeline: Technical support
- Ticket main category: Product issue / Malfunction
- Ticket status: Waiting on Dev (Analysing)
- Product criticality: It is very important to use accurate classification here! If unsure, check these guidelines.
- Incident Date: Exact day the incident occurred!
- Ticket description:
- A short description is always helpful
- If there is a GH issue already tracking the investigation, it is sufficient to simply link that one.
- Addressability:
- Assign the team(s) most likely to be able to address the problem. It is often better to assign multiple teams (e.g. SW + HW), especially when the cause is not clear yet.
- Ticket name: "[CT] Short description"
-
- WingtraOne ID: XXXX
- Software version: vX.X.X
Choose the closest release version from the list, i.e. if on v1.9.6rcX choose v1.9.5. - Company: Wingtra (wingtra.com)
- After creating the ticket:
- Add a direct link to the .ulg file in the field: "Link to flight logs"
- If there is already a related Github issue add to "Link to related Github issue"
- Assign a "Ticket engineering owner" according to the type of issue:
- The updated list of experts is located here.
- Battery hardware issues (not charging, shutting off): Marco Job
- Drive-train (motor, ESC, propeller): Ronny Panier
- PPK Hardware: Ronny Panier
- PPK connectivity: Bharat Tak
- Telemetry or RC: Constantin Jung
- Flap or Servos: Constantin Jung
- Camera issues: Severin Scherrer
- Flight behavior, crashes: Sebastian Verling
- Preflight issues, no logs, flight path: Michal Stasiak
- WingtraPilot: Andreas Bircher
- WingtraHub, data workflows: Julian Surber
- Industrialization, test bench, sourcing (SCM): Victor Chaubert
- Production, Quality Control, Fulfillment: Michael Weber or John Hinterberger
-
-
- If unsure or Dev is not reacting: Youssef Demitri
-
Post-reporting responsibilities (Ticket Engineering Owner)
Once you have reported your ticket, the responsibility for further processing is with the assigned "Ticket Engineering Owner".
- Dev investigation: The investigations for different incidents are handled internally within the teams, which make sure every case is tracked and documented in Github (or Hubspot) with a clear outcome.
- Ticket classification: The ticket engineering owner has to fill in R&D classification, write a note on outcome of the investigation and close the ticket, by changing the ticket status at the top left to "Closed". The following properties are not relevant for internal tickets and can be filled out as shown below:
- Warranty assessment: Not applicable
- Warranty expired?: -
- DoA case?: No
- Time to first reply from message: -