Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-3496

Consolidate naming and structure of SRC example workflow repository

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • SRCnet
    • Hide

      Previous work by coral team saw the use of a small number of workflows to undertake profiling work, which have been gathered in a git repository: https://gitlab.com/ska-telescope/src/src-scientific-use-cases/ . Developing this repository so that it covers a broader range of example workflows, linking to "use cases" (as defined in the use case document), with access to relevant data sets will be valuable for sites and teams across the development work. But, before we surge ahead with more examples, we need to consolidate the repository, discuss and agree its structure and make a scalable plan for data location. This feature addressess that planning and housekeeping aspect.

      Show
      Previous work by coral team saw the use of a small number of workflows to undertake profiling work, which have been gathered in a git repository: https://gitlab.com/ska-telescope/src/src-scientific-use-cases/ . Developing this repository so that it covers a broader range of example workflows, linking to "use cases" (as defined in the use case document), with access to relevant data sets will be valuable for sites and teams across the development work. But, before we surge ahead with more examples, we need to consolidate the repository, discuss and agree its structure and make a scalable plan for data location. This feature addressess that planning and housekeeping aspect.
    • Hide

      AC1: Workshop (zoom) early in PI enabling all interested parties to understand the current structure and discuss their requirements going forward leading to:

      AC2: Plan for the modification of the repository taking into account the status of the repository and the feedback from the workshop. The general idea is to provide a scalable repository (i.e. able to host different kind of wfs), including the code, documentation on how to run it and data/parameters required.

      AC3: Migration of existing content into new format, and guidance note (in repo readme) explaining how repo is structured and what the requirements are for adding new workflow examples.

      Show
      AC1: Workshop (zoom) early in PI enabling all interested parties to understand the current structure and discuss their requirements going forward leading to: AC2: Plan for the modification of the repository taking into account the status of the repository and the feedback from the workshop. The general idea is to provide a scalable repository (i.e. able to host different kind of wfs), including the code, documentation on how to run it and data/parameters required. AC3: Migration of existing content into new format, and guidance note (in repo readme) explaining how repo is structured and what the requirements are for adding new workflow examples.
    • 0.5
    • 0.5
    • 0
    • Team_CORAL
    • Sprint 4
    • Hide

      https://gitlab.com/ska-telescope/src/src-workloads

      Show
      https://gitlab.com/ska-telescope/src/src-workloads
    • 19.6
    • Stories Completed, Outcomes Reviewed, Satisfies Acceptance Criteria, Accepted by FO

    • PI24 - UNCOVERED

    • PI19-PB SRC-Benchmark SRC-CompPlat SRC-Multi-Team Team_CORAL

    Description

      The feature will prepare the repository (consider a rename, how to scale in future as examples grow, how to link to sample and large data products etc) for further development.

      Attachments

        Issue Links

          relates to

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3512 SRC workflow example: Source Classification (not CNN)

          • Not Assigned - Priority is not assigned yet.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3513 SRC workflow example: Spectral line finding and classification

          • Not Assigned - Priority is not assigned yet.
          • Funnel

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3506 SRC workflow example: Mosaicking (SWARP)

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3507 SRC workflow example: Image co-adding

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3516 SRC workflow example: e-MERLIN pipeline

          • Must have - Items labelled as "Must have" are critical to the current delivery timebox in order for it to be a success.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3508 SRC workflow example: Image Convolution

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3509 SRC workflow example: Image cutouts

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3510 SRC workflow example: Source Finding

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3511 SRC workflow example: Source Classification (CNN)

          • Should have - Items labelled as "Should have" are important but not necessary for delivery in the current delivery timebox. While "Should have" items can be as important as "Must have", they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.
          • Done

          Feature - A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). SP-3514 SRC workflow example: RM extraction

          • Could have - Items labelled as "Could have" are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.
          • Done
          mentioned in

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Page Loading...

          Structure

            Activity

              People

                A.Clarke Clarke, Alex
                M.Parra Parra, Manuel
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 0.5

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete47.0
                  Total47.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel