Working with Tickets

Working with Tickets

Everything starts with a ticket. We use Jira, developed by Atlassian, as our issue tracking system.  

From Start to Finish:

Creating JIRA Tickets

There are times when you need to create your own JIRA tickets. When you do, please follow these guidelines:

  1. Title should always start with the vendor-os. This way, the kanban board would show up correctly.
    CHKP | PAN | F5 | Radware | Cisco-IOS | Cisco-NXOS | Juniper-SRX | Bluecoat | Fortinet | Crossvendor | Linux
  2. Release notes is an effective way to communicate our product enhancements to customers. If you are working on a ticket that you think we should share the information with customers, please add a label = relnotes. Typically, this is a new feature, a bug or a new network device release such as R80.10. Please provide description in the JIRA ticket simple enough so that a non expert can understand what you have fixed or enhanced with this version of software. Keep the description brief and clear. A bullet list of updates would work fine. Whatever you put in the ticket is what customers will see. Remember release notes is our way to improve customer retention communications. 
  3. Tickets with the label = customer-found are generally higher priority than new development. There is a corresponding new field Customer Name. This field will be populated by indeni employees. Although you won't have visibility to who the customer is, you will know how many customers are impacted by this defect. customer-found labels are for BUGS ONLY (not tasks, improvements, or new features).
  4. Do not populate the Fix Version/s Affects Version/s fields. 
  5. If you are working on a problem that consists of multiple components and requires co-ordination with different consultants, the recommended way is to create an EPIC with multiple subtasks. Each subtask is a JIRA ticket. Create a single branch that can be shared among IKE's. Everyone merges his code into the share branch. A good example would be a new metric that requires a new rule.

Accessing your Tickets 

  1. To view what is assigned to you, go to the Backlog. Click on the Boards drop-down menu button. You will find all the previously To Do tickets in the backlog. You should NOT be working on tickets in the Backlog without consulting with the indeni team.
  2. To view tickets that are in progress, the Kanban board is recommended. Since the Kanban backlog is enabled, the Kanban board is a lot more readable. Notice the Selected for Development column, they contain high priority tickets for you to work on.
  3. When you are ready to work on another ticket and the Selected for Development column is empty, please let your indeni manager know.

Important Guidelines

  1. If the ticket is a duplicate, please create a link and move the ticket to Discard (not Done) and add "DUPLICATE" to the summary. See IKP-964 as an example. 
  2. If ticket is a hotfix, prepend subject line with HOTFIX.
  3. Please be sure to put the JIRA ticket at the right state.
    • Do not move from "Selected for Development" to "In progress" when you're not truly working on the ticket.
    • Do not move from "In Progress" to "In Review" unless you have truly made a Pull Request. And remember to test your code first with a real indeni server before submitting a Pull Request.
    • After your code review is approved, you should expect to see an email notification soon after that your ticket has been merged to the branch you targeted with your pull request.  
    • If your pull request targeted a branch other than Staging, your branch owner will eventually merge your code from that branch into Staging, and at that time, will notfiy you that your code is now in Staging. Regardless, once your code has been merged to Staging, move your ticket from In Review to Staging. Once the Jira ticket is in Staging, this ticket immediately becomes your highest priority so you should test this immediately to make sure that your code still works with the Staging Indeni server in the KDLab. When your test is complete and successful, move the ticket to Done. This is an indication to us that your code is ready to be merged to Master and ultimately, to be sent to customers. 

Why is it important to have the right status?

Our sales, engineering and support team will be using these status to communicate to our customers the status of the defects. 

Some tickets are tagged with the following text in the subject line: internal. These are used for reporting and can safely be ignored.