Introduction
If you think you have found a bug or you wish to capture a future requirement, you should raise a ticket on the Lawmaker Support Portal.
Which ticket category to use
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.
Support related 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 - 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 will be appropriate – use some common sense when recording issues:
Title: keep this brief and to the point
Background/Summary: this is basically an overview of what you were trying to do and why. Sometimes some business context helps TNA or the development 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 (numbered list) to help TNA 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 TNA 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. Tip: type “snipping tool” into the start menu to get screen grabs and 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 TNA decide where it should be positioned alongside existing bug tickets in the support queue.
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
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 TNA 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 by the development team, TNA will need to write up the requirement as a user story which is written in a specific way to help the development team unambiguously implement and test them. If your future requirement ticket is vague or missing key information, TNA will be in touch to clarify the requirement and check the implementation with you. To help TNA 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 TNA 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 the page-break identification and removal problem. The proposed solution from TNA which is far quicker and easier (think: cheaper) is 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. The actual implementation was a little simpler The ticket does not need to be an essay and can be fairly high-level. You can be treat a bit like a placeholder until you prioritise the work with TNA for a future major release. It is the Product Manager's responsibility to fully capture future requirements for the development team and some may need a lot more unpacking than others e.g. where a high-level requirement such as ‘Church Measures’ may be made up of several separate requirements whcih can be individually prioritised and delivered. Some requirements need to be broken down into a number of discrete requirements and then you can work together with TNA’s Product Manager to refine the requirement into a number of discrete requirements that all inter-relate.