Jump to content

[Archived] Reporting bugs and requesting features

George Peppard

Recommended Posts

This post is now superseded by 


We try and keep the bugs in the platform to a minimum, but the extensiveness of it and the wide variety of use cases means it is almost inevitable that at some point you will experience a bug. This article describes how to report bugs accurately and correctly so that we can fix them as soon as possible.

What is Bugzilla?

Bugzilla is our installation of the upstream software of the same name. We now use it to track unconfirmed and confirmed bugs through from when they are reported all the way to resolution. We previously used YouTrack and Jira to handle this. We plan to soon migrate idea tracking to Bugzilla in some form, although how this will be done remains to be seen.

vAMSYS developers have full access to Bugzilla - that is, they can do everything. vAMSYS community support staff have an elevated level of access to Bugzilla that allows them to edit all bugs, regardless of who reported them. All other users can view and comment on all bugs, can submit new bugs, but cannot edit bugs that do not belong to them.


The anatomy of a bug

Bugs in Bugzilla have the following information associated with them:

  • the product is the root level project that the bug is associated with; for most bugs this will be "vAMSYS"
  • the component is the part of the product that the bug is associated with
  • the version is the version in which the bug is exhibited - as we do not track versions for most products, this will usually be "rolling"
  • the status can be one of UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED; some statuses have more information associated with them (for example, an issue can be RESOLVED FIXED or also RESOLVED WONTFIX); for non-staff users, this will be set to UNCONFIRMED until it is reviewed by staff
  • the severity is a measure of how "important" a bug is; it's important to think in terms of overall importance and not just how important a certain bug is to you (an exception to this rule is the severity "enhancement" is used to represent new features or ideas)
  • the hardware and OS can be used to capture information about the platform you are seeing a bug on
  • the assignee is the person who is held accountable for the resolution of this bug - by default this will be the vAMSYS developer who has overall accountability for the component you selected, but the assignee of an issue is often changed later to the developer who is working on the bug
  • the CC field allows you to specify any other users who are key stakeholders in the bug
  • the orig. est field allows you to specify an original estimate in hours for how long the issue will take to resolve
  • the deadline specifies the date by which the bug should be resolved
  • the URL can be filled to include a URL to link the bug to
  • the summary and description allow you to describe the bug; the summary field should contain a brief summary of the issue and the description field can be used to elaborate further
  • you may add an attachment to a bug
  • depends on, blocks and see also allow related bugs to be specified
  • the priority of an issue is populated after the issue is filed, and represents how high priority the issue is to be resolved

Not all fields must be filled (in fact only a product, component, version and summary are actually required). You may not have permission in your role to edit some (or most) of these fields - do not worry, fields you cannot edit will be populated by the staff member that carries out the triage for your issue (that is, checks over the issue and confirms it, as well as assigning it a priority and severity).


Submitting a good bug report

The most bugs can get the most timely attention if users adhere to good practice when submitting bugs. Bugzilla already has a fairly comprehensive set of guidelines on reporting bugs, which we encourage all reporters to read. In general, reporting bugs generally follows down to some principles:

  • Be precise - remember we don't see what you can see, so we need to have precise information in order to find the bug in the first place!
  • Be clear - explain the bug so it can be reproduced
  • One bug per report
  • No bug is too trivial - small bugs may hide big bugs
  • Clearly separate fact from speculation

and some preliminaries:

  • Check before you report the bug that you can reproduce it - it may have been fixed
  • Search to see if the bug has already been reported!

If you've reproduced the bug and can't find it on Bugzilla already, then this is how you can go about reporting a new issue.

  1. Choose Enter a new bug.
  2. Select the product in which the bug is located (for most bugs, this is "vAMSYS"). You may be automatically sent past this step.
  3. Select the Component the bug relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General")
  4. Enter a summary, describing the bug in 60 characters or less. A good summary should quickly and uniquely describe a bug report. It should explain the problem, not the solution.
  5. Enter the details of the problem report in the description field, including
    1. A more detailed reinstatement of the summary.
    2. Steps to reproduce the bug including the URL of the page the bug occurs on.
    3. Actual results (what the application did when you performed the steps)
    4. Expected results (what the application should have done if the bug was not present)
    5. Any other useful information - for example - if it only applies to one VA - note which one.
  6. Double check your bug report for any errors or omissions then press Commit.

Your bug is now in the database, and (provided you are not a Bugzilla moderator) is awaiting triage in the UNCONFIRMED state. You will receive emails when the status of the bug changes.

You can always leave comments on a bug if you wish for additional information to be noted, or edit the bug.

Submitting an idea or feature request

vAMSYS VA owners (or their staff) are able to request the addition of new functionality to the platform. Previously this was accomplished via a dedicated "ideas" platform, however in order to consolidate information on changes to the platform we have moved this process also to Bugzilla. Feature requests are created as bugs, but must be created with the "enhancement" severity.

Please note that if you do not hold a VA staff position, or are not a VA owner, then your feature request will be automatically dismissed. You should contact your VA staff and ask them to consider raising the request on your behalf. VA staff should note that when raising a request on behalf of their VA, it is considered the VAs opinion that the requested feature should be added. If a VA does not agree with the request put forward by a user, they are within their rights (and we recommend that they do) to politely decline. If this is the case, no Bugzilla entry needs to be created. Feature requests require a VA sponsor to be considered.

When requesting functionality we suggest you follow these tips:

  • Be clear and concise, but include the required details.
  • Tell us why this change would benefit your VA.
  • If you have any ideas about how the feature would work, then please include them! Even if our implementation is slightly different, this is helpful for us.
  • Most importantly, make sure your VA owner is aware of the fact you are raising this request! It is their VA that will be sponsoring the change, and they probably won't be happy if their name is attributed to something they had no idea about!

To request new functionality is included in the platform, follow these instructions:

  1. Search for the feature request on Bugzilla! If it has already been created, you may wish to add a comment expressing your support. See Supporting a feature request for more information.
  2. Choose Enter a new bug.
  3. Select the product in which the feature will be located (for most requests, this is "vAMSYS"). You may be automatically sent past this step.
  4. Select the Component the feature relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General"; if your feature request would add a new component, then please select the component that would "contain" this new one if possible)
  5. Enter a summary, describing the request in 60 characters or less. A good summary should quickly and uniquely describe the requested feature, and should not include any suggestions for implementation. It should describe what you would like to be achieved, not how to get there.
  6. Enter the details of the suggestion in the description field, including
    1. A more detailed reinstatement of the summary.
    2. What group of people within your VA this change would benefit, and why.
    3. Roughly what proportion of your VAs users (or staff, if this is a request for staff-only functionality) the change would benefit.
    4. Any background relating to the change request. For example, did you previously have this functionality on another platform?
    5. Any additional information you think would be pertinent.
  7. Enter the Feature request sponsor VA's three letter pilot ID prefix (for example, if you are VAM0002, the prefix is VAM). Please only enter the prefix of a VA in which you are staff. If you do not see this field, then you have not selected enhancement as the severity. Go back and select this now, then complete this field.
  8. Double check your suggestion for any errors or omissions then press Commit.

Supporting a feature request

Previously, it was possible to vote for an idea to express support. The intention of this was good, but often manifested in a VA getting their entire staff team to vote for their idea, artificially inflating the popularity of a given idea. This led many VA owners and staff to feel that this "canvassing" was necessary to get an idea through to implementation, which left many owners with negative opinions of the system. This also presented issues for vAMSYS developers - we had no idea how the feature would impact a certain VA, or what VAs it would impact.

To try and curb these issues, and mainly to try and encourage a healthy debate around the inclusion of new functionality, we have removed the previous "voting" system, instead allowing members to comment on a feature request on Bugzilla to express their support. There is no direct relationship between "votes" (or in this case comments) and implementation, and instead the entire request (including comments) will be reviewed holistically in order to gauge popularity.

Therefore, if this functionality will benefit your VA, we invite you to leave a comment on the feature request on Bugzilla explaining why your VA would also like the feature implemented. This need not be any longer than a couple of sentences, but you may wish to (and of course, you are welcome to) elaborate further, for example if you have further suggestions or requirements for the implementation.

  • Like 1

George Peppard
Systems and Infrastructure Advisor to vAMSYS, ex-Infrastructure Director

Link to comment
Share on other sites

  • George Peppard changed the title to Reporting bugs and requesting features
  • Lukas Jankauskas changed the title to [Archived] Reporting bugs and requesting features
This topic is now closed to further replies.
  • Create New...