Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Establish explicit test plan life cycle in working mode #950

Open
mcking65 opened this issue May 31, 2023 · 1 comment
Open

Establish explicit test plan life cycle in working mode #950

mcking65 opened this issue May 31, 2023 · 1 comment
Assignees
@mcking65 @lolaodelola @ccanash
Labels
Agenda+Community Group To discuss in the next workstream summary meeting (usually the last teleconference of the month) documentation Related to documentation about the ARIA-AT project or its deliverables enhancement New feature or request process Related to processes for governing and managing the ARIA-AT project

Comments

@mcking65
Copy link
Contributor

The current version of the working mode does not explicitly define the life cycle path of a version of a test plan. It implies that a plan moves from R&D to Recommended in a straight line but does not explicitly address what happens to a version of a test plan when it is made obsolete by a newer version.

This issue is complete when the working mode and glossary clearly describe how a test plan is versioned and what the full life cycle of a specific version of a test plan is.

Defining test plan version

Recommendation: Define test plan version in the glossary.

Definition proposal:

The version of a test plan is identified by a commit date-time stamp in its test source repository. Each repository that serves as a source of tests has a branch that serves as a test publication branch. A new version of a test plan is created when a commit to the test publication branch changes one of the plan's source files. For example, a new version of an APG pattern test plan is created when a commit to the master branch of the w3c/aria-at repository changes the source of the plan.

Proposal for test plan version life cycle

  • A given test plan may have only one version in the draft, candidate, or recommended phases of the working mode:
    • Advancing a version of a plan into the draft phase replaces the current draft version if one exists.
    • Advancing a version of a plan into the candidate phase replaces the current candidate version if one exists.
    • Advancing a version of a plan into the recommended phase replaces the current recommended version if one exists.
  • When an older version of a plan is replaced by a newer version, the older version is sunset.
@mcking65 mcking65 added enhancement New feature or request Agenda+Community Group To discuss in the next workstream summary meeting (usually the last teleconference of the month) documentation Related to documentation about the ARIA-AT project or its deliverables process Related to processes for governing and managing the ARIA-AT project labels May 31, 2023
@mcking65 mcking65 self-assigned this May 31, 2023
@howard-e howard-e mentioned this issue Jun 1, 2023
Open
@jscholes jscholes mentioned this issue Jun 1, 2023
Closed
@lolaodelola lolaodelola self-assigned this Jun 8, 2023
@howard-e howard-e mentioned this issue Jun 27, 2023
Merged
21 tasks
@mcking65
Copy link
Contributor Author

Per discussion in aria-at-app issue 632, the term "deprecated" is preferable to "sunset". It more accurately represents the state of the version of a plan. That is, when V2 replaces V1 of a plan, it is because V1 is no longer considered current , and V1 should no longer be used.

@alflennik alflennik mentioned this issue Aug 2, 2023
Merged
8 tasks
howard-e added a commit to w3c/aria-at-app that referenced this issue Sep 28, 2023
@howard-e @evmiguel
@Paul-Clue @alflennik @stalgiag
Update Data Management, Test Queue and Candidate Review Pages and Dat…
14563b0 
…abase Implementation to support #648 (#688)

Changes added to primarily support #648, but also #518 and w3c/aria-at#950. This includes functional changes to the Data Management, the Test Queue and the Candidate Review pages. It also includes changes to the database structure, described in #632.

* feature: updates functionality of Data Management page (#713)
* feature: updates functionality of Test Queue page (#715)
* feature: updates functionality of Candidate Review page (#715) 
* feature: include functionality to support the concept of required reports (#722)
* feature: adds Test Plan Report Status dialog (#728)
* enhancement: move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Review page (#730)
* feature: adds Test Plan Version page (#747)
* enhancement: explicitly support ‘DEPRECATED’ phase status for TestPlanVersions (#749)
* feature: adds filter and sorting functionality by columns headers on Data Management page (#750)
* bugfix: update semantic structure of cells with multiple list items on Data Management page (#752)
* enhancement: include GitHub issues on Test Plan Version page (#753)
* bugfix: revision of the required reports conditions for updating to CANDIDATE and RECOMMENDED phases (#764)
* bugfix: removes superfluous header from Test Plan Report Status dialog (#766)
* bugfix: update and revise sorts, headings and descriptions of elements on Test Plan Version page (#767)
* bugfix: account for several other update phase scenarios that could prevent the update from happening if there is an older TestPlanVersion that exists with results (#771)
* bugfix: update headings and revise deprecated dates shown on Test Plan Version page (#773)
* enhancement: allow updating of GitHub issues being presented in the app to be more easily understood (#775)
* bugfix: correct deprecatedAt date to be relative to when the ‘next’ TestPlanVersion was added (#780)
* enhancement: update the text shown when deprecation occurs during a phase on Test Plan Version page (#781)
* bugfix: fix inverted sort descriptions and pin sort of of Test Plan name columns on Data Management page (#790)

---------

Co-authored-by: Erika Miguel <[email protected]>
Co-authored-by: Paul Clue <[email protected]>
Co-authored-by: alflennik <[email protected]>
Co-authored-by: Stalgia Grigg <[email protected]>
Co-authored-by: Howard Edwards <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mcking65 mcking65

@lolaodelola lolaodelola

@ccanash ccanash

Labels
Agenda+Community Group To discuss in the next workstream summary meeting (usually the last teleconference of the month) documentation Related to documentation about the ARIA-AT project or its deliverables enhancement New feature or request process Related to processes for governing and managing the ARIA-AT project
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jscholes @mcking65 @lolaodelola @ccanash