Date
1 - 1 of 1
What's next for publishing oslc-op specifications
We are finally getting
the remaining ReSpec changes done in order to be able to render HTML for
the oslc-op specifications. Thanks to Nick and Andrew for all the work
they've contributed to this important component of our development procersds.
Our ultimate goal is to get these six multi-part specifications to Candidate OASIS Standard as soon as possible:
1. Architecture Management 2.1
2. Change Management 3.0
3. OSLC Core 3.0
4. Quality Management 2.1
5. OSLC Query 3.0
6. Requirements Management 2.1
I have created a summary of Open Project specification lifecycle process in https://github.com/oslc-op/oslc-specs/wiki/Open-Project-Specification-Lifecycle-Processeswith some additional oslc-op specific details. This document will need to be updated as we push the first document through the process, but its a start.
Here's a rough state machine that summarizes that process:
WD -- PGB vote--> PSD revision -- PGB SMV vote and OASIS conformance review approval --> published PS revision -- 3 statements of use + PGB SMV--> COS --> 60 day public review + OASIS OP Admin issuing call for consent to approve COS as OS --> OASIS Standard
Each PGB vote is open for 14 days. This serializes the process for a specification, be we could do many in parallel.
Here's what's left to be done:
1. Complete and final ReSpec Update and merges (in progress, should be completed today)
2. PGB vote to create Change Management 3.0 as PSD03 (in progress, waiting for votes, closes 1 Aug)
3. OASIS OP Admin reviews Change Management 3.0 as PSD03 for specification conformance (ahead of vote for PS03 in order to address any formatting issues in this first published OP document)
4. Do any final edits and/or ReSpec changes to address OASIS specification conformance issues (if any)
5. Schedule PGB SMV to promote Change Management 3.0 as PSD03 to PS03.
6. OASIS publishes Change Management 3.0 PS03.
7. All OASIS and open-services.net redirects for access to Change Management 3.0 PS03 are done and tested.
8. Schedule PGB SMV to promote Change Management 3.0 as PS03 to COS and schedule 60 day public review
9. Collect one more statement of use for Change Management 3.0
10. Assuming no issues are raised during public review that require a specification revision: ask OASIS OP Admin to issue a call for consent to promote Change Management 3.0 COS to OS. Does this require a PDB vote?
Following step 7 on the Change Management 3.0 spec, we can repeat the process in parallel for the other five multi-part specifications.
Regarding those specifications, there may be further actions:
We need to catch up on the issues and make sure we've addressed all the ones that are needed before publishing a PS.
We need to publish the vocabularies and shapes on open-services.net/ns. Not sure when this should be done. Perhaps not until we reached OASIS Standard?
Architecture Management:
A significant issue has been raised: https://github.com/oslc-op/oslc-specs/issues/69that calls to question the viability of the proposed AM 2.1 specification. The issue is that there a no properties that define connections between oslc_am:Resource and other OSLC domain resources. This reflects a significant shift in design and implementation of the AM 2.0 specification at open-services.net that was never resolved or completed in the 2.1 specification.
Requirements Management:
We should probably address issue "Should we deprecate the "inverse" properties defined in RM 2.1" (https://github.com/oslc-op/oslc-specs/issues/82) before creating an RM 3.0 PS.
Quality Management:
Has some vocabulary cleanup and other issues that need to be resolved before a PS is published.
--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575
Our ultimate goal is to get these six multi-part specifications to Candidate OASIS Standard as soon as possible:
1. Architecture Management 2.1
2. Change Management 3.0
3. OSLC Core 3.0
4. Quality Management 2.1
5. OSLC Query 3.0
6. Requirements Management 2.1
I have created a summary of Open Project specification lifecycle process in https://github.com/oslc-op/oslc-specs/wiki/Open-Project-Specification-Lifecycle-Processeswith some additional oslc-op specific details. This document will need to be updated as we push the first document through the process, but its a start.
Here's a rough state machine that summarizes that process:
WD -- PGB vote--> PSD revision -- PGB SMV vote and OASIS conformance review approval --> published PS revision -- 3 statements of use + PGB SMV--> COS --> 60 day public review + OASIS OP Admin issuing call for consent to approve COS as OS --> OASIS Standard
Each PGB vote is open for 14 days. This serializes the process for a specification, be we could do many in parallel.
Here's what's left to be done:
1. Complete and final ReSpec Update and merges (in progress, should be completed today)
2. PGB vote to create Change Management 3.0 as PSD03 (in progress, waiting for votes, closes 1 Aug)
3. OASIS OP Admin reviews Change Management 3.0 as PSD03 for specification conformance (ahead of vote for PS03 in order to address any formatting issues in this first published OP document)
4. Do any final edits and/or ReSpec changes to address OASIS specification conformance issues (if any)
5. Schedule PGB SMV to promote Change Management 3.0 as PSD03 to PS03.
6. OASIS publishes Change Management 3.0 PS03.
7. All OASIS and open-services.net redirects for access to Change Management 3.0 PS03 are done and tested.
8. Schedule PGB SMV to promote Change Management 3.0 as PS03 to COS and schedule 60 day public review
9. Collect one more statement of use for Change Management 3.0
10. Assuming no issues are raised during public review that require a specification revision: ask OASIS OP Admin to issue a call for consent to promote Change Management 3.0 COS to OS. Does this require a PDB vote?
Following step 7 on the Change Management 3.0 spec, we can repeat the process in parallel for the other five multi-part specifications.
Regarding those specifications, there may be further actions:
We need to catch up on the issues and make sure we've addressed all the ones that are needed before publishing a PS.
We need to publish the vocabularies and shapes on open-services.net/ns. Not sure when this should be done. Perhaps not until we reached OASIS Standard?
Architecture Management:
A significant issue has been raised: https://github.com/oslc-op/oslc-specs/issues/69that calls to question the viability of the proposed AM 2.1 specification. The issue is that there a no properties that define connections between oslc_am:Resource and other OSLC domain resources. This reflects a significant shift in design and implementation of the AM 2.0 specification at open-services.net that was never resolved or completed in the 2.1 specification.
Requirements Management:
We should probably address issue "Should we deprecate the "inverse" properties defined in RM 2.1" (https://github.com/oslc-op/oslc-specs/issues/82) before creating an RM 3.0 PS.
Quality Management:
Has some vocabulary cleanup and other issues that need to be resolved before a PS is published.
--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575