Introduction
If you think you have found a bug or you wish to capture a new requirement or improvement suggestion, you can raise a ticket on the Lawmaker Support Portal.
Which ticket category to use
Urgent serious issues
Report an urgent system issue - use this if Lawmaker is not available or malfunctioning in a business critical way.
Bug reporting options
Report a bug - use this if you suspect there is a bug that needs fixing.
Report a performance issue - use this if you are experiencing performance issues when using a particular feature or in general.
Future requirement options
Suggest improvement - use this to log suggestions on how to improve current features.
Suggest new feature - use this if there’s a feature that’s missing and you’d really like Lawmaker to handle.
Other options
Questions and other support - use this if you have a question about a specific feature or anything in general Lawmaker related that the TNA team might be able to help you with.
User Admin - use this to request a new user account or reset an existing account.
Support Portal Access -use this to give users full access to the support portal. You do not need full access to raise tickets in the support portal, but you will need full access to view tickets raised by others in your organisation.
How to write a good bug ticket
When logging suspected bugs and performance issues on the portal, please try to ensure the following information is captured so that this can be investigated expediently. Not all headings below will be appropriate in each case – use some common sense when recording issues:
Title: keep this brief but descriptive where possible
Background/Summary: this is basically an overview of what you were trying to do and why. Sometimes some business context helps the Lawmaker team understand what you were trying to do and where the issue might lie.
URL/Test data/Attachments: Include a URL to your project and also the document in Lawmaker. If you were having issues with a PDF, find the PDF snapshot and select Actions > Download ZIP and attach the downloaded ZIP file to the ticket (the ZIP file will contain the PDF and XML for that snapshot). If you were having issues with an amendment, include the Dnum (e.g. HoL1), or the assigned number to make it quicker/easier for TNA to find the troublesome item.
Test steps: it can often be a needle in a haystack trying to locate issues in the system. If you know how to reproduce the issue, include some basic steps (in a numbered list) to help the Lawmaker team recreate the issue. If you weren’t sure what steps you took and were unable to recreate the issue, consider listing all the activities you were doing around the time that the issue occurred. As much information as you can think of will really help the Lawmaker team investigate the issue.
Actual outcome vs the expected outcome: as part of the test steps, don’t forget to include a brief statement on what actually happened (i.e. the bug) and separately outline what you expected to happen.
Screen shots: screen shots can really help investigate issues e.g. errors on dialog boxes or the specific thing in the PDF that is incorrect. Tip: type “snipping tool” into the start menu (or press shift + windows key + s) to get screen grabs and then use Ctrl + V to paste them into your portal ticket.
Time the issue occurred: particularly useful for performance related issues. Provide the date and time. It doesn’t have to be exact.
Priority ranking: please assign a priority to the ticket which will help the Lawmaker team prioritise it appropriately against other support issues being worked on.
Example:
Title
Line numbering not working correctly in document containing equations
Background/Summary
The line numbering on pages containing equations is not correct and in some cases appearing on the line between text. See for example pages 3, 7, 35 and 64 of the PDF.
URL/test data/attachments
https://lawmaker.staging.legislation.gov.uk/loginLink to the project
Attached ZIP file containing XML and PDF
In this example, there was no need to include test steps, actual outcome vs expected outcome or screenshots. All the information the Lawmaker team need to investigate the issue is in the XML & PDF contained in the attached ZIP file. In some cases, a bug might only manifest itself after a particular sequence of steps which is why supplying test steps are useful.
How to write a good future requirement ticket
Before a future requirement can be implemented, the Lawmaker team will need to write up the requirement as a user story which is written in a specific way to help developers unambiguously implement and test them. If your future requirement ticket is vague or missing key information, the Lawmaker team will be in touch to clarify the requirement and check the implementation with you. To help the Lawmaker team understand your requirement, there are certain bits of information that can help:
Title: keep this brief and to the point
Background/Summary: explain who needs the new feature, what they would like it to allow them to do and why they need this and also what the current workaround is (assuming there is one).
Requirement: explain what it is that you need. In some cases it can be obvious and feel free to suggest an appropriate solution. However, bear in mind that the Product Manager or the development team might identify a better implementation to satisfy your need which is why it’s more important to explain the intended outcome rather than how it should be achieved.
URL/Test data/Attachments: some requirements can be complicated to understand, particularly where they relate to business process or domain knowledge. Including attachments to documents or screenshots on what you want to achieve will help the Lawmaker team understand what the goal of the requirement is and specific details. If the requirement is PDF-related, attaching PDFs of correct format/content will also help.
Example:
Title
Identify page breaks to allow me to easily remove them
Background/Summary
Page break example: page breaks are currently visible in the Editor. However, if the document is large it can be hard to ascertain if it contains page breaks as they aren’t searchable and users have to scroll the whole document instead.
Requirement
Page break example: I would like a quick and easy way to identify if there are any page breaks in my document e.g. like the ‘Delete all J-ref’ option in the upper tool bar’s Insert menu.
Attachments
N/A
In this example, the user has proposed a solution to a problem with identifying and removing page-breaks. The Lawmaker team will review all proposals and may come back with alternative suggestions to meet your requirement or seek clarification of what you’re looking for. In the case above, the proposed alternative solution from the Lawmaker team, which may be quicker and easier (think: cheaper) to implement, was to include a new document check which will jump to the page break in the document allowing the user to easily remove them if required.
These kinds of ticket does not need to be highly detailed; they can be fairly high-level. They can be treated a bit like a placeholder until the feature is prioritised for a future release. At that point, the Lawmaker team will work with you and other users to confirm the detail of what is required and the best way to implement it.