Where to Create a JIRA ticket

A Snap shot for how to create a JIRA.

JIRA Guideline for Patches Contributions

Issue type corresponds to the type of contributions we are making. The following issue types can be possible for patches contribution
√ Incident - Build failure incident issues with the code verification steps such as Black duck scan, Jenkins verification etc.
√ Bug - Bugs in existing component code. To report a bug, users must create a ticket with type Bug and provide as much information as possible, including:

  • A clear and concise description of the bug
  • Steps to reproduce the bug
  • The expected behavior
  • The actual behavior
  • Any relevant screenshots, logs or videos

√ Task - An individual task which may be part of enhancement of existing feature, etc.
√ Improvement - Improvements such as code refactoring or enhancements in current code.

Summary and Descriptions are mandatory fields need to be filled.

Click on Create button to Create a new JIRA. Sample example is provided below.

JIRA Guideline for New Feature Contribution


A feature contribution should follow after creating an appropriate JIRA project. This will present a clear picture about the architecture, testing details and other information which will be helpful during the acceptance process of the contribution.

Mandatory information

  1. Project

    For Video & build system (Yocto) related contributions, the ticket should be created under RDKDEV. For broadband, the ticket should be created under RDKBDEV project.
  2. Issue Type

    √ New feature - New feature contributions.
  3. Ticket Status

    Status should be initially Open, and transitioned to the appropriate value while the contribution is being worked on.
  4. Summary

    A brief summary about what we are trying to contribute 

  5. Description

    A descriptive information about the contribution should be present so that component developers & architecture team can do assessment of the feature. Below details are desirable if the contribution is a new feature or having an significant impact on the current architecture.

    Solution Overview

    Brief introduction on what the current system lacks & what needs to be done:

    1. Individual task/highlighted point #1 brief description.
    2. Individual task/highlighted point #2 brief description.

    Architecture Checklist
    The following items should be considered/addressed in the documentation for any RDK design initiative
    JIRA Update Checklist
    -----------------------
    The following JIRA fields MUST be filled in to be considered "Definition Complete":
    * RDK SoC, RDK OEM - populate these fields for any user story where we have dependency on OEM and/or SoC to perform work in the completion of this user story. Select all that apply, or “None” if there is no dependency.
    * OEM/SoC Impact Details - description of impact (or "see Solution Overview" if included in the architecture specification)
    * Platforms - ensure correct list of devices
    * Validation - type of testing
    * Regression - is regression required?
    * Impacted Party - Comcast Only, Syndication, etc.
    * Dependency - Internal/External
    * Description - Solution Overview and Architecture Checklist
    
    Testing impact/Guidance
    ------------------------
    * Impacted modules
    * Test process
    
    Automated Testing
    ------------------
    * Automation test procedure.
    
    Diagnostics, Telemetry and Logging
    -----------------------------------
    * N/A
    
    Outbound Network Connections
    ------------------------------
    * Does this component make outbound connection requests? 
    * If yes, do the connection requests retry in the case of failure?
    ** Do the repeated requests use an exponential back-off?
    ** If a maximum back-off has been defined, is it greater than 10 minutes?
    
    Security
    ----------
    * For Security Review - Do feature elements:
    ** make any changes to network port assignments?
    ** change iptables rules?
    ** require credentials, passwords, secret data?
    ** make any changes to our network connections? 
    ** connect to new services or servers?
    ** use data input from users or external tools?
    ** use any cryptographic functions?
    ** create or disclose proprietary or sensitive Co. or device data?
    ** properly log operational and configuration changes? 
    ** If possible describe what could happen if feature elements are:
    *** spoofed?
    *** tampered with?
    *** used by an unauthorized actor?
    ** Advanced questions (optional)
    *** what happens if a record of actions taken is destroyed?
    *** what happens if an attacker attempts to DOS with the feature?
    
    SI Concerns
    -------------
    * Yes/No/Any
    
    Performance expectations
    -------------------------
    * Yes/No/Any
    
    
    Timing consideration
    ----------------------
    * If Any.
    

Supplementary Information

  

  1. Impacted component(s) - Fill in list of impacted RDK components
  2. RDK SI Impact - System Integration impacts
  3. CPE SW Components - Component names.
  4. Test Notes - Describe what tests are performed to validate this contribution and the procedure.
  5. Unit Test Result - Description.


  • No labels