Viewing Debrief Issues in GitHub
Viewing an Issue in Debrief/GitHub is very easy to do and though it’s not necessary to log into GitHub to view issues it is required if you wish to raise an issue.
- Navigate to the Debrief repository:
- Click on the Issues tab to view the list of all current issues. The total number of issues is shown on the tab:
Of course, it’s likely that your issue might not be at the top of the list, or even on the first page, as there can be a number of open issues at any given time.
Need Priority Support?
Please remember, basic support for Debrief is free and our support team will address basic support issues in turn. Naturally, more complex issues will take longer than normal to resolve, so there may be some delay on getting to yours. We do appreciate your patience in this.
However, if you either have a large team or an increased number of issues, and you require speedier resolution, then it may be beneficial to you to upgrade to either our support basic or support plus plans: one of the many benefits to you and your organisation is priority turnaround on your bug fixes.
This quick turnaround will ensure that you’re not suffering delays from unresolved fixes, your team aren’t hanging around, and you’re not wasting unnecessary time and money waiting for your issue to be resolved.
If You Can See Your Issue in the List
- If your issue is visible in the list, click on the subject line to open it:
- The screen will refresh and the issue will display:
You can see the present status of the issue, how close it is to being solved, and who’s in charge of this here. If you’d like to add your thoughts and recommendations to the discussion you can comment on the thread. Commenting on the issue is straightforward, but we’ll cover it later in another post.
If You Can’t See Your Issue in the List
If you cannot see your issue in the list, rather than scrolling through and scanning individual pages, it’s much quicker and easier to apply a filter to the issues list. To do this:
- Click on the drop-down arrow in the Filters box at the top of the issues list. A drop-down list will display:
- Select Your issues from the list and all issues you have raised – both open and closed – will be shown:
As you can see, I have raised just the 1 issue (for documentation purposes).
- With the filtered results, click on the issue subject line you wish to view and the screen will refresh and you can view your issue.
Viewing Closed Issues
If you need to view closed issues, for example to review the outcome of the issue, when it was closed, etc., GitHub maintains the history to allow you to do this. To view a closed issue:
- Click on the ‘Closed’ text link at the top of the issues grid:
The screen will refresh and all closed issues will show.
- Click on the Filters drop-down arrow and select Your Issues to show only those you’ve created.
Comments or Feedback
This concludes the brief tutorial about viewing issues in Debrief/GitHub; we hope it’s been useful to you? If you have any feedback or have something else to contribute to this post/discussion, please let us know by leaving a reply in the box below. We appreciate your feedback and contribution.
Benefits of a Debrief Support Plan
These plans are cost-effective and based on what your organisation needs. There are many benefits, including:
- Responsive user support to analysts – this ensures they are focussed on delivering output. As you may be aware, a knowledge worker “in the zone” is capable of delivering amazing insight. Unfortunately though, the lack of a support contract can mean that an analyst has to defer exploring a hypothesis – with the result that it may never be investigated.
- Immediate access to Debrief updates delivered in an enterprise-friendly form – these updates include all new features and are packaged as an MSI installer (.msi). This has the dual effect of reducing the workload on both analysts and the IT support infrastructure.
- Direct access to the software team to discuss new features & working practices – this means you are actively involved in making Debrief’s evolution. We’ve been working on this for 20-years now, and it’s active involvement from others that keeps making it so good.
- Quick turnaround feature requests / bug fixes ( typically delivered within two working days) – it can take many days for an analyst to fully engage with the context of a trial/operation, to get into the mindset of the participants. Once broken this concentration can take considerable time to re-engage. However, if they’re allocated to your feature request, this dedicated resource ensures the fastest turnaround.
- Getting started support, including training & support for importing two in-house ASCII file types – we want you up to speed with Debrief as fast as possible (as we’re sure you do), and we can only provide this level of coverage to our most important customers.
|Previous Post||Post Home||Next Post|