Where to Create a JIRA ticket

• Log in to JIRA https://jira.rdkcentral.com/jira/secure/Dashboard.jspa using rdkcentral credentials
• Create a JIRA ticket under RDKDEV (for Video) or RDKBDEV (for Broadband).
• Click on the Create button

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 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.