Handling Bug Reports is a vital part of the Application Life-Cycle, and receiving such reports is an expected joy for the Development Team
If you like our software, please consider making a donation. Donations help greatly to maintain the Massively Modified network and continued support of our open source offerings:
Table of Contents
- Documentation Topics
- Making Bug Reports
- Bug Reports via Email
- Become a Member (coming soon!)
- Contribute Code
- Test Code
- Adhere to Our Coding Standards
- Adhere to Our CSS Naming Conventions
- Make a Donation
Making Bug Reports
Making a Bug Report is a simple process, and very similar to making Feature & Enhancement Requests
Regardless of whether its a Feature, Feature Enhancement, Bug, or Vulnerability, it's an issue. Issues are the central element of any Gitlab project, and the Massively Modified Application Life-Cycle follows an Issue-First approach (for the most part, anyways).
Therefore, to begin you'll want to visit the issues list (
The Issues Interface
Upon loading the issues interface, you can fill out the form in a way such that developer involvement is minimized
The title is very important. Here are some points to help you through creating a good title:
👓The more clear and to the point that the title is, the better.
✍Punctuate as best you can, so others won't have to spend as much time correcting it. Remember, most developers have OCD with things like that 👓
🎥Unlike Feature - and Feature Enhancement - Requests, Bug Reports should explicitly state the issue. With Bug Reports you'll word the description, rather than the title, from the view point of the user.
Let's say that you're a developer making use of our gulp-bump-version plug-in, and you notice that when you run the coverage test that the coverage output shows 0 for every heading rather than the correct coverage amounts - a good title might be:
The coverage test is not reporting accurate coverage
For another example; Let's pretend that Massively Modified's nk project was ready, and end-users could build a powerful website using the provided CMS extension. You requested a feature in the back-end that shows all back-end user activity and it was implemented. When you try to sort activity by a column heading the sorting only works in ascending order and doesn't reverse upon toggling the header again. A good title in this case would be:
When Sorting the admin user activity log sorting only works in ascending order.
The description is where you get into the Knitty-Gritty. When it comes to Bug Reports, this is where you use perspective, as it helps to express important details that the team would like to know. Let's cover some examples so that you see how it works.
For the first feature request above, a good description would be:
Click to view details
As a developer, I expect that a coverage report would accurately report coverage data for the tests that I run.
However, when running the coverage test, the output I get is the following:
----------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ----------|----------|----------|----------|----------|-------------------| All files | 0 | 0 | 0 | 0 | | ----------|----------|----------|----------|----------|-------------------|
mocha, and the command I'm using to run the test is:
nyc mocha dist/test/test.min.js
For another example, let's say you were writing the second bug report mentioned above:
Click to view details
As an administrator, I expect that I am able to sort the list of user activity present on the dashboard by any of the table headings.
I further expect I can toggle those headings to choose from ascending or descending order.
When I click a table heading a first time, the data will sort by ascending order according to the data in the respective heading. However, upon attempting to toggle the same heading again, the data does not sort in descending order - and in the browser console I receive the following error:
(index):363 Uncaught ReferenceError: sortTableByUserId is not defined.
I will get a slightly different error depending on the heading, but the error is for the most part always the same.
The default sort upon page load is for UserId, and so I get this error on the very first click of the table heading, as its sorted asending by default for that table heading.
I am using the chrome browser, and have verified that issues exists in IE and FireFox as well.
Notice the descriptions cover very specific details. They describe how the user expects things to work normally from their sepcific viewpoint, and then what is happening in place of that.
Details outlining their environment and steps required to replicate the issue are present.
Labels are how we discern the purpose of an issue. Labels are what differentiate an issue as a Feature Request, Feature Enhancement Request, Bug, or vulnerability.
Labels may be stacked as well and can provide supplementary information for an issue, such as severity.
The appropriate label for a Bug Report, would be
bug. If the issues were very bad and resulted in an application crashing, or even worse - a machine crashing, then it would be expected that you would additionally flag the 'critical' label as well.
Both of the reports about would simply include the
bug label, as neither of the bugs mentioned are of the
Submit the Issue
The last step is to submit the issue. Make sure to review your issue in its entirety and ensure that the you've filled out the required fields properly, thoroughly, and with as much clarity as possible.
If you've any attachments you'd like to include with your Bug Report, you may attach them to the issue. These could include screenshots of the issue, such as console output, the result of image compression, or rendered web page views.
The remaining fields are intended for internal use, and we ask that you do not set any other fields other than those which we've described in this documentation.
When you're ready, click the
submit button to submit the issue. You're issue will be assigned an id and you'll be automatically subscribed to the issue.
Report Bugs via Email
If you are absolutely unable to create an issue via your web browser, but happen to have access to email - you could alternatively submit an email to
incoming+mmod/<project-name>@incoming.gitlab.com requesting the team to create a Report for you. Be sure to include, in your message body:
- A title, as explained above
- A description, as explained above
- Any attachments you might want to include
The team will, upon reviewing the issue - which will be automatically created by Gitlab - in our integrated Service Desk, set the appropriate labels.
You'll be able to receive updates and correspond with the comments via your email conversation.
Keep in mind though, that this is not the recommended way to make a Bug Report.
To view the license for the documentation provided by this wiki, please visit the Wiki Homepage