Prioritized Labels

Drag to reorder prioritized labels and change their relative priority.

  • priorityKey
    This issue/MR is key for the associated milestone and must be completed before the deadline of the milestone. Some will be associated with a milestone without this label because they are not blocking the release (e.g. external feature contributions).
    Quantify
  • priorityCritical
    This issue has critical priority and must be worked on ASAP to go into a hotfix release (if necessary). Git cherry-pick or file checkout can be used for this.
    Quantify
  • Other Labels

  • ComponentAnalysis
    Related to the quantify-core analysis.
    Quantify
  • ComponentBackend Qblox
    Related to the quantify-scheduler Qblox hardware backend.
    Quantify
  • ComponentBackend ZI
    Related to the quantify-scheduler Zurich Instruments hardware backend.
    Quantify
  • ComponentCompilation
    Related to the compilation of a schedule from the gate to pulse level, or pulse to backend level.
    Quantify
  • ComponentControl
    Related to the control of experiment, e.g. measurement control, settables and gettables, etc..
    Quantify
  • ComponentData
    Related to quantify dataset and its handling.
    Quantify
  • ComponentDocs
    Related to the documentation, its building, RTD, docstrings, tutorials, etc..
    Quantify
  • ComponentInfrastructure
    Related to aspects not strictly related to code, e.g., problems with CI, GitLab workflow, non-code issues, etc..
    Quantify
  • ComponentVisualization
    Related to realtime plotting or schedules visualization.
    Quantify
  • Good first issue
    Good issue for onboarding new contributors
    Quantify
  • MR State1. In progress...
    [Progress captain: assignee] MR not ready for complete review. Equivalent to Draft/WIP. The assignee is responsible for asking help/advice by tagging relevant people. Next state: "2. Review me!".
    Quantify
  • MR State2. Review me!
    [Progress captain: assignee] MR was submitted and is ready for review. Assignee may tag potential reviewers in the comments. Next state: "3. In review...".
    Quantify
  • MR State3. In review...
    [Progress captain: reviewer] A reviewer with enough expertise is reviewing the MR (the reviewer should self-assign as such). If there are no concerns so far and the reviewer does not have enough expertise, the "2. Review me!" label should be activated again. Next state: "4. Change requested" or "5. Merge me!".
    Quantify
  • MR State4. Change requested
    [Progress captain: assignee] Reviewer's comments need to be addressed (comments/code/test/docs/etc.). Conflict with target branch should be addressed carefully. Next state: "2. Review me!".
    Quantify
  • MR State5. Merge me!
    [Progress captain: assignee & maintainer] MR ready to be merged. Assignee should tag maintainers. Next state: Merged or "4. Change requested".
    Quantify
  • RequestDiscussion in DM
    This is requested to be discussed in a coming weekly Developers Meeting.
    Quantify
  • State1. Needs refinement
    [Progress captain: creator of the issue] The problem in the new issue is not reproducible and/or not clear enough to allow for the design of a solution.
    Quantify
  • State2. Workable (design)
    [Progress captain: None] The problem is recognized and understood. Anyone can pick up the issue.
    Quantify
  • State3. In design...
    [Progress captain: assignee & creator of the issue/project owners/maintainers/.developers/community] The relevant parties are working to propose and converge on a particular solution/implementation. Issue must have at least one assignee.
    Quantify
  • State4. Workable (implementation)
    [Progress captain: assignee] The solution is clear. Anyone can pick up the issue implementation.
    Quantify