When you file an issue on the Asterisk JIRA you might notice that a few people may end up looking and participating in it. The first person, however, is usually just doing triage. What is triage? Well – before a developer looks at an issue it is vetted to ensure that it is a valid issue and that all needed information is available. This ensures that developers can spend their time on fixing the issue instead of tracking down what they need at a later time when the reporter may not have the information handy. Before you file an issue please read the issue guidelines.  Doing your own triage before you submit is a great self-check as it can save everyone some time and get your issue resolved faster. To help with that let’s take a look at some questions a triager asks themselves when triaging issues!

Is this an information request?

If you’re asking a question about Asterisk and not actually describing a problem then the Asterisk JIRA is not the appropriate forum. The Asterisk community site or the asterisk-users mailing list is better suited for that purpose.

Is this a security issue?

If you believe that you’ve found a security issue then following the wiki for how to report one is the way to make the developers aware. This ensures that the vulnerability is not disclosed publicly before a fix is available. If it does not turn out to be a security issue then you will be told to file it as a normal JIRA issue.

Is the version supported and up to date?

This may seem like an obvious thing but many people file issues for older unsupported versions. Since looking into old versions can be time consuming and the issue itself may already be fixed in an up to date version, we generally don’t accept issues for old versions. In fact I would say 25-40% of the time an issue in an old version has been fixed by upgrading.

Is the component set properly?

This is a minor thing but allows for better filtering and to more easily see what issues are filed against what. If you are unsure of what the component should be when filing choose what feels right. It can always be changed later.

Are there any third party modules involved?

Third party modules have not been reviewed by the Asterisk developers and are maintained outside of the project. Since we are not aware of what the code is doing and do not know the quality of it we ask that any issue filed not have a third party module loaded when reproducing the issue. If the issue goes away when the third party module is not loaded, then the issue is likely with the third-party module.  Contact the maintainers of the third party module.

Does an issue exist already?

In the Asterisk issue tracker we don’t accept multiple issues for the same problem. We keep only one issue open. If you think you can provide additional information then attach your information to the open issue and add a comment.

Is the environment described?

When filing an issue include as much information about the environment as possible. This includes the Linux distribution in use as well as the version. If your issue involves VoIP in some way then also describe the network topology and layout. When attempting to reproduce and isolate the issue this can be instrumental.

Are reproduction steps included?

Part of isolating and fixing the problem includes reproducing it. Providing exact steps of how to make it happen goes a long way to getting it fixed. If you don’t have exact steps then provide a general description of what was going on at the time.

Are log files attached?

To facilitate diagnosis of a problem please attach any log files demonstrating the issue.  Don’t worry about attaching any files when you initially create the issue — because you cannot.  Attach any files after the issue is created.

Are configuration files attached?

To facilitate reproducing an issue attach any needed configuration files. Be sure to sanitize them and remove sensitive information.

If it’s a crash or deadlock, is a backtrace attached?

A backtrace provides a glimpse into what is happening in Asterisk when a crash or deadlock happens. We require them for all crashes so we can isolate what is going on.

Has the area of code changed recently?

If the problem seems to come from a specific area and changes have recently been made then marking it as a regression is warranted. It’s okay if you are unaware of changes, the person doing triage may be more aware.

Is this a code contribution?

While code contributions can be submitted on JIRA they are included much faster if they are also published to Gerrit for review. Full details of this process is available on the wiki.

These questions aren’t just limited to issues you are filing. If you would like to help contribute to the project one of the ways you can do so is by doing issue triage. If you see an issue, apply the questions above.  If any information is missing then add a comment expressing your desire for the missing information. If you would like to do this more often you can ask to become a bug marshal. This is an elevated privilege which allows you to change issue states and ask for feedback or close an issue. Join the Asterisk issue triage task force, TODAY!