Jira and GitHub Details

Generally, the sooner you can create a ticket in Jira for a bug or any planned development, the better! It helps all Consortium Participants know if an issue already exists, and helps others better understand future development that may dovetail with their own needs.

Jira Issues

Before you create a new Issue in Jira, please remember to search to see if the Issue already exists. This will avoid unnecessary duplication of efforts.

When you create a Jira Issue, you will provide:

• Issue type

  • Bug: Identified malfunction based on error in code

  • Task: Something we know needs to be done but is not causing an error

  • Story: New feature or enhancement, worded as a user story in lay terms

  • Epic: Used to house stories and tasks related to a significant project.

• Summary

• Component: Required software component.

• Description

• Attachments

• Linked Issues: If applicable, please use this especially if an issue blocks or is blocked by another issue. If we should review ME-231 before ME-165 please let us know.

• Epic: If you know the ticket belongs to an existing epic, please add it.

• Assignee: Assign yourself or a teammate only if you are going to work on something; otherwise leave blank.

• Priority: Every issue will default to medium but feel free to change.

• Labels: Use this to indicate your institution. Other institutions may add themselves to show interest in the project.

• Affects Version/s

Once your Issue has been created, the Elentra Consortium Core Team or other Consortium committee members will supply:

• Fix Version: Indicates what release we aim to include this in.

• Sprint: Indicates when we will review / work on something.

• RFC Status: Indicates whether issue is in RFC process.

• PMC Review: Indicates whether PMC will review/discuss.

• ARC Review: Indicates whether ARC will review/discuss.

If you have made a Pull Request in GitHub, the corresponding Jira Issue should automatically be marked Ready for Review. Please unassign yourself and we will assign someone to review the Issue.

Issue Template for Bugs

Please provide the following information for new Issues marked as bug:

• Description: Short description of the issue

• Pre-Condition(s): List of conditions needed to begin

• Steps to Reproduce: List of steps to reproduce issue

• Expected Results: What is expected to happen

• Actual Results: What is happening now

• Add Files: Supply information here like photos, gifs, console logs files or anything that will help the developer recreate the issue.

• Additional details: If you are assigning yourself and can give us an indication of when you’ll be working on something, that is very helpful in preparing to review and test it in a timely fashion. Sample ticket: https://elentra.atlassian.net/browse/ME-864

Issue Template for User Stories

This is the user story: As a <user type> I want to _____ so that _____.

Please provide the following information for user stories:

• Reason: Why is this being implemented?

• Acceptance Criteria or Business Requirements

• Documentation: If you are running something in production and have provided user documentation, please share it with us.

• Add Files: Anything that will help the developer and tester like photos, prototypes, gifs, etc.

• Implementation Notes: If there is something specific that people need to know to make this work, please include it (i.e., this work introduces a new setting which needs to be enabled, work requires migrations, etc.)

• Additional detail that is helpful to us:

  • What kind of code review you did internally if a PR has been made

  • An estimate of when you’ll be working on something if you are creating an issue before development (which we strongly recommend!)

Sample ticket: https://elentra.atlassian.net/browse/ME-763

If a user story represents a substantial change to Elentra ME, it will go through a Request For Change (RFC) process, coordinated by the Product Management Committee. A representative from the PMC will mark which tickets require an RFC.

Jira Issue Status

• New Issue: All newly created tickets will have a New Issue status applied by default. If, when creating a ticket, you know that you will be actioning it immediately, please feel free to update the status to 'In Progress'.

• Deferred: This status is applied to tickets that represent ideas for features but which no one is currently undertaking.

• To Do: Ticket is planned for development but requires additional information (e.g., business requirements, UI designs).

• Ready For Development: Ticket has sufficient detail (e.g., business requirements, UI designs, technical specifications) for development work to begin.

• In Progress: Someone is working on it.

• In Review: A Pull Request has been submitted and the GitHub Issue is linked to the Jira Issue.

  • If you are a developer from a participating school, please unassign yourself when an issue is In Review. The core team will assign someone to review it.

• In Testing: Core Team QA team does this.

• Ready to Merge: Core Team senior developers will do this.

• Merged: Complete or Done and merged into the develop branch.

GitHub Information

When creating a Pull Request in GitHub please observe the following:

• Include the Jira Issue number in the title (e.g. ME-453: As a learner, I want to upload information to my metadata fields so my record is complete.)

• Include a link to the Jira Issue in the description.

• Describe what the Pull Request includes and any relevant details for someone who might do code review or testing (this might be more technical in nature than the description you added to the Jira Issue).

• Do not apply any GitHub labels (these aren't available to all developers so we're just going to stop using them).