Label used to indicate issue found during M12 milestone

Label used to indicate issue found during M11 milestone

Label used to indicate issue found during M10 Patch milestone

Label used to indicate issue found during M10 milestone

These are the activities that have been prioritized to start next

Issue life cycle label: These are activities that have been placed on hold, either because of a blocking factor or displaced by a higher priority

Issue life cycle label: This is where the work is happening

Issue life cycle label: These are activities that have been completed

Issue life cycle label: Label applied to indicate that issues are confirmed, but no active work are in progress. Pending volunteers to pick up.

This issue needs to be confirmed if this is the intended behavior of the service

This issue relates to improving or introducing unit testing, integration, or automation in code testing

A task is an issue where developers use to track the ongoing activities, e.g. could be a clean up. Not necessarily a defect or backlog.

Issue regarding work related to code clean ups/refactoring/optimization

A decision record (DR) is a result of an process inefficiency where a new OSDU practice that has agreed to address the existing process inefficiency (perhaps requiring new process, operation patterns)

This issue has been reviewed and confirmed that it is not an issue but rather an intended behavior/operational issue/basic query.

This issue requires further information but lack of responses from submitter. Close after inactivity for more than 6 months.

A feature request is an issue that is either a new requirement that needs software changes, new feature development (perhaps requiring new repos, sub-projects or new PMC projects). This request needs to follow an ADR that provides enough clarity on the requirement, the definition of done, impact of changes and other necessary attributes so the issue can be curated and moved up in life cycle. May require an entry in Aha portal.

An enhancement may be made to address specific user needs or requests, or they may be made to address broader goals, such as increasing the efficiency or effectiveness of the software. May or may not require an ADR depending on the nature of the change. This applies to improving or enhancing existing software behavior only, without introducing new features.