This is a living Document. The most recent copy is always available on the Wiki


Spotting and reporting genuine issues in our platform is one of the most accessible ways to contribute but, in equal measure, also the most tricky to do well. If you use this guide as reference when you raise a ticket, it will reduce the chance of delays in it reaching our development team.

Searching Issues

Tickets for outstanding issues often contain workarounds shared by our development team, or links to threads that provide discussions and solutions between our community members. Otherwise, they will tell you when a fix for a issue was created and the build you need to obtain in order to take advantage of it.

It is not necessary to waste time debugging incorrect Kandan behavior that has either already been fixed or has a known workaround. Being familiar with GitHub’s powerful issue search tool, will enable you to easily access this information.

Submitting Issues

The Issue-Reporting Lifecycle

We are keenly-committed to being as open to feedback from our community as possible, to ensure that the platform becomes more stable and featureful in the shortest time. It cannot be underestimated how crucial community-reported bugs are to achieving this goal. Hence, if you find a issue, and you are able to reproduce it reliably with a simple use case, then we will be very grateful if you would report it to us.

That said, the creation of tickets in the Issue Tracker should not be taken lightly. The management of each ticket can consume considerable resources, and so inaccurate or bogus submissions take unnecessary time away from what we would all prefer our development teams to be doing - improving the code.

In addition to accuracy, tickets that are concise, complete, unemotional and objective are the ones our teams appreciate the most.

Issue Tracker Workflow Diagram

GitHub Issue Tracker Workflow

Creating a Use Case

A “use case” is working code or reproduction scenario that reliably reproduces a specific issue. What sets the quality use cases apart from the rest is that they contain the least possible code while still demonstrating the issue. Take pride in your use case; make it an art!

Being in the habit of writing use cases as part of your troubleshooting process can significantly decrease the time we address your issue. This is because it can differentiate user errors from issues in the platform.

Creating a Issue

  • Create a Issue, only after there is no doubt about the issue’s existence, Create one ticket per issue, bearing the following in mind:
    • keep to the point: concise, complete and factual tickets are the most appreciated
    • include all the information: without a use case we probably cannot accept your issue
    • watch your issue


We do not underestimate the time and conscientiousness involved in raising good issues, and we very much appreciate it. Although we’d love to chat with you. Adding a ticket asking how to do XYZ probably isn’t a good idea.

Thank you for all your efforts!