User Tools

Site Tools



Jira usage guidelines

Issue creation

For most fields there is no further guideline needed, therefore just mentioning the ones here that require special handling:


The component should be set to the corresponding module, if possible. For each module, there is a default assignee, which should be used, if the issue is not created by the developer himself.

  • Android (Rick Bell)
  • AllJoyn-Bridge (Todd Malsbary)
  • Bridging General (Todd Malsbary)
  • Build System (???)
  • Cloud (Jee Hyeok Kim)
  • Discovery/Connectivity (Ashok Babu Channa)
  • Documentation (???) ← do we need this component?
  • Generic Java (Rick Bell)
  • Node.js Bindings (???)
  • Notification service (Poovizhi Avudai)
  • Platform Support (Dave Thaler)
    use this when a platform build breaks, or a new platform shall be introduced
  • Primitive Service (Uze Choi)
    used for issues with the basic communication protocol (application-level)
  • Remote Access (???)
  • Sample Application (???)
  • SDK (Uze Choi)
    Deprecated - do use more specific component if possible
  • Security (Randeep Singh)
  • Transport (???)
  • UPnP Bridge (Rick Bell)
  • web site (Thiago Macieira)
    issues related to the IoTivity web site or Wiki

Bugzilla ID

If there is a relation to an OCF Bugzilla entry, put the URL to the Bugzilla entry here.

← This change has been rejected. The Bugzilla ID shall go here. If a developer is interested in the corresponding Buggzilla bug, open Bugzilla and search for that ID.

Start/Stop progress and re-assign

If the ticket is assigned to a maintainer, it may be re-assigned to a developer. The developer should use “start progress” and “stop progress” to indicate when working on the ticket. If a developer sees that he can not handle the ticket at all, or for quite some time (vacation, …) it should be reassigned back to the maintainer of the module. A ticket should never be unassigned. An unassigned ticket has no owner.

Outdated tickets

Every month we will check for tickets that have not been updated for 3 month. The current ticket assignee will be requested to update the status of this ticket (in general this is either the developer working on the ticket, or the component lead). At this stage it may be elevated in priority. If a ticket is not updated for 6 month there needs to be a final decision if this should be either dealt with short term, or if it should be closed as 'withdrawn'. Again the component lead should take this decision.

Alternative suggestion

Looks like the community feels that asking the current assignee about the ticket status via Jira is not sufficient. Instead there is a proposal to go through all of these tickets in a smaller group and triage the tickets. This would mean that we need to have a meeting/call at least once a month to go through these tickets. The tool that shall be used for this is still tbd. Proposal: Lets first implement the proposal above and check after a while if it is working or not. Introducing triage meetings includes some overhead to define a group for this, setup the meetings, decide on tools to use and finally it is difficult for this group to really check out every ticket as it requires from the group members an overall understanding of all tickets and the related code.

Ticket Status

While working on a ticket, use “start progress” and “stop progress” When the work is done, use “resolve” Question: Who makes the transition from “resolved” to “closed”? Is this done by QA, the devloper, ….? Ideas here? There are right now 471 Tickets in resolved state in Jira!

Proposal: When commiting code to Gerrit, that is related to a Jira ticket, then provide a link to the ticket with the commit (ie: Using Bug: $url convention)

Following pages: contribute, report, community

jira_how_to_use.txt · Last modified: 2017/12/04 14:31 by Phil Coval