User Tools

Site Tools


jira_proposed_changes

DRAFT PAGE - STILL UNDER CONSTRUCTION - Christian

Proposed changes to Jira (March 2017)

Update components

In Jira these components are used right now (number in brackets shows number of open issues): (DONE)

  • Discovery/Expiry (42)
    mixtures of network issues and bridge related tasks
    proposal: rename to Discovery/Connectivity (see below) and keep for network related issues, add a component for the bridges
  • Install/Uninstall (10)
    mainly used for scons related issues
    proposal: keep and rename to build
  • Node.js Bindings (0)
    not used
    proposal: remove
    kept, seems to be needed
  • Other (45)
    issues are build related, build system related, ….
    does it help to have such a component?
    proposal: remove and substitute with meaningful components where needed
  • Documentation (8)
    proposal:keep
  • Reconnect/Failover/Promotion (2)
    used for presence related issues
    proposal: remove and combine with Discovery/Expiry
  • Invitation (1)
    very generic ticket here about thread safety
    proposal: remove and replace by module specific components
  • Remote Access (2)
    2 xmpp related tickets from 2015
    proposal: close old tickets but keep component
  • Sample Application (32)
    proposal: keep
  • SDK (205)
    seems to be the default component for most tickets
    proposal: keep, but make sure that in the future tickets get more specific components
  • Service (29)
    proposal: keep 
  • Transport (31)
    transport related tickets, got a few tickets mixed in that are more general
    proposal: keep for transport related issues

Add components

The idea is to have one component per project. This helps to identify who is in charge to resolve an issue. When a ticket is created related to a specific component, it can be assigned directly to the maintainer of that project (default assignee listed in brackets below).(DONE)
Proposal: add the following components

  • web site (Thiago Macieira)
    issues related to the IoTivity web site or Wiki
  • Discovery/Connectivity (Ashok Babu Channa)
    rename above Discovery/Expiry component
  • Platform Support (Dave Thaler)
    use this when a platform build breaks, or a new platform shall be introduces
  • Primitive Service (Uze Choi)
    used for issues with the basic communication protocol (application-level)
  • IoTivity Cloud (JeeHyeok Kim)
  • Security (Randeep Singh)
  • Bridging (Todd Malsbary)
  • Generic Java (Rick Bell)
  • UPnP Bridge (Rick Bell)
  • AllJoyn-Bridge (Todd Malsbary)
  • IoTivity-Constrained (Kishen Maloor)
  • Notification service (Poovizhi Avudai)

Create own project for Node.js ?

Q:Do we want to create a new Jira project for Node.js named IoTivity-Node? If yes - we should remove the Node.js component

→ kept now the Node.js Component!!!

Start using Constrained Framework project for IOTivity-constrained

DONE

  • rename to IoTivity-constrained
  • start using Jira for IoTivity constrained

Cleanup Fields

Goal is to simplify ticket creation and the overall flow by now asking for information that is either not needed at all, or that could also just go into the Description field: (DONE)

  • remove OIC alignment related field, as it is no longer used
  • Operating System field: simplify the choice to major OS: Ubuntu, Windows, Tizen, Android, Other. This field will not be mandatory
  • remove Transport field
  • remove SDK/Services field
  • remove Operating System Type
  • remove Processor/Architecture field

Remove the example project

DONE

  • remove EXAMPLE

fix version field shall become mandatory

When resolving a bug the fix version field shall be mandatory. This helps to find out in which version/stream the fix was promoted. ← did not find a way to enforce this on the transition :-|

Update Jira to latest version 7.3.2

We should update our Jira version to the latest one. See https://www.atlassian.com/software/jira/update The latest version has the Scrum board included, see https://www.atlassian.com/software/jira

With the Scrum board we could:

  • have Sprints and Sprint planing to better plan out the release schedule
  • have a sorted backlog for the issues
  • each maintainer has an easy drag and drop interface to order the issues regarding the priority

Of course we would not do the daily standups, but also when planing in a scope of 2 or 4 weeks, the Sprint planning is very useful.

More information about the Scrum board can be found here: https://www.atlassian.com/software/jira/agile#scrum

jira_proposed_changes.txt · Last modified: 2017/04/06 11:39 by Christian Gran