Andrew, I just went with the oslc-op@ main mailing list. Let's see how this works out in practice.
I think the collecting of comments is a topic that will benefit from some experimentation. So we're good for now!
/chet
On Tue, Mar 9, 2021 at 4:03 PM Andrii Berezovskyi < andriib@...> wrote:
" We'll address that in the next Version", nice addition to my co-chair vocabulary :D
Regarding public comments, https://www.oasis-open.org/oasis-open-projects-handbook/ specifies that anyone with a GH account can leave "comments". On the other hand,
the handbook indeed sends us the TC process for the COS and that document talks about a completely separate mailing list. We are fine with whatever process you can approve quickly. I think if we want to stick to the letter of the handbook and resolve it quickly,
we shall either tell people to get a GH account and open an issue as per the handbook or to create a new list as per the TC process. Though you may use the rule/loophole §8.1/8.2 https://www.oasis-open.org/policies-guidelines/open-projects-process/#repositories-project-tools-dvcs-issues and
"bless" the Github repo or anything else as an officially selected tool for public review comments.
Hi Andrew and all,
I do hope we can start the public reviews tomorrow, although there is still some question (apparently rule interpretations are involved) about how to handle the public comment submissions. (Andrew's suggestion [1] for using the regular OP email
is very functional, but not yet approved by Chet, Jamie, etc.). When that is resolved, we'll send out the announcements and start the 60-day review.
(I've put the "public review metadata documents" in place with tomorrow's date, but will adjust the date if needed.)
Regarding the diagram (very nice!), I'm not certain if the "Material changes required" arrow MUST go back to "Prepare PSD" or if there is a way it can go more directly to publication of a new PS. After looking through the TC Process [2] and Open
Project Rules [3], I think that you are right - it DOES require returning to "Prepare PSD", as in your diagram. However, "Material change" [4] is a fairly high bar (requiring change in implementations), so it is very unusual at this stage. (For major change
comments, the usual response is "We'll address that in the next Version...")
Best regards,
Paul
On Tue, Mar 9, 2021 at 2:08 PM Andrii Berezovskyi < andriib@...> wrote:
Hello Paul,
Great, let's start the public review tomorrow then. Thank you for all the hard work!
I am assuming Jim is also onboard given that we found a way forward without any delays. Also, nice to know that the PS goes to OS without publishing a COS document but a PS n+1 instead (hopefully). I made a quick and dirty process diagram (sorry,
I copypasted a bit and misused some shapes). Could you please check if I am on the right track?
<OASIS OP 2021 process.png>
Hi all,
Sounds like a good resolution here.
Just a couple of clarifications:
- About "COS" - Following the 2020 process changes, we no longer publish a "Candidate OASIS Standard" (COS) as a separate document. There is simply a 60-day public review of an existing Project Specification (PS). If the review results in "Non
Material" changes, an updated PS (PS02, for example) is published, and it will be the subject of the "Call for consent". After approval, the updated PS will be published without further change (other than filenames, etc.) as an OASIS Standard.
(If there are "Material" changes, the PS02 would need to receive new "Statements of Use" and undergo another 60-day review.)
Best regards,
Paul
I'm ok with the proposal.
Best regards,
Axel
Correct. I agreed that the changes are non-material. I just didn't take the time to think through the implications of how to handle that in the ballot.
Andrew, what I mean is that the current PS01 will be opened up to public review in preparation for the call for consent. Paul or I will send your issues in #19 to the OP mailing list as review comments. (And, as you note, you may get others.)
After the 60 day review closes, we will follow this section of the TC Process:
If comments were received and only Non-Material Changes are to be made to the Committee Specification, the editor(s) may prepare a revised Committee Specification.
Changes may only be made to address the comments. The TC must provide an acceptable summary that is clear and comprehensible of the changes made and a statement that the TC judges the changes to be Non-Material to the TC Administrator and
request a Special Majority Vote to proceed with the call for consent. The TC Administrator shall hold the Special Majority Vote and announce it to the OASIS membership and optionally on other public mail lists along with the summary of changes and the
TC’s statement. If the Special Majority Vote passes, the TC Administrator must start the call for consent for OASIS Standard within 7 days of notification.
In other words, we will take the ZIP file (or, if there are other modifications, that resulting file), publish it as PS02, and then hold the SMV to proceed with the call for consent. Once that passes, I will start the call.
We can run Change Management in parallel with that if you like or process it independently.
Yes, Jim, Axel, if you can confirm that this is OK by you, we'll move forward.
/chet
On Mon, Mar 8, 2021 at 5:07 PM Andrii Berezovskyi < andriib@...> wrote:
Hello Chet,
I am happy with the plan, sounds like a good way to kill two birds with one stone, esp. if some non-material changes will be requested during the review and we will need to make minor edits anyway. The only thing that raised I am curious about
is:
Once that passes, we will publish the ZIP as PS02 and make it the candidate for the Call for Consent.
The document you linked tells me that either those changes go into a "revised CS [PS]" if they are non-material or result in "a CSD [PSD]" and have another PS approved. Do you mean that this process allows us to take a PS01, take it to COS01,
get comments and make non-material changes and when you open a ballot for an SMV, the "revised PS" will automatically be approved both as PS02 and COS01?
Finally, should we get all PGB members to reply here for a record that we [hereby] agree to proceed with the public review of RM COS 01 based on RM PS 01 as published in OASIS archive at http://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/ and
not based on the attachment? I do approve that on my part.
Also, I think it should be Chet or Paul who will take the 8 extra changes I made and submit them as comments as I am not sure it will be OK for me to add public comments on the spec document I prepared myself.
P.S. Jim, it was Chet who was OK with my changes when I asked, not Paul.
Hi guys -
Sorry. Paul is right. I goofed on the ballot but here is an alternative way forward.
I should not have used the link to the email attachment - https://lists.oasis-open-projects.org/g/oslc-op-pgb/attachment/107/0/rm-2.1-cos01.zip -
in the ballot. I *never* should have done that. The version approved as PS01 that is published is the version at http://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/.
That is the formally approved spec, published, and, crucially, the one all the Statements of Use cite. Asking for approval to move forward with an email attachment was stupid, stupid, stupid and I'm not sure how sleep-deprived I was when I set it up. But I
cannot put that forward as the candidate for OASIS Standard. That is just compounding the error.
I don't see any clean way to go back and redo this. If I set up a ballot to approve that ZIP file as PS02, you'll need to redo everything else. And we don't overwrite specs once published. PS01 has to stand as is.
Here is what I propose: we will go ahead and run the review on teh approved version at http://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/.
We will then submit the issues identified in issue #19 as public review feedback. After the public review period has closed, we will kick into the process as described in https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/#OSpublicRev.
Basically, I will hold a Special Majority Vote to approve the ZIP file as a new PS for submission to the members in the Call for Consent. Once that passes, we will publish the ZIP as PS02 and make it the candidate for the Call for Consent.
Again, apologies for this snafu. This is the first cOS ballot from Open Projects and I wanted to get it right. At least this way, we can keep it moving forward in line with the process.
If you have questions or you want to consider alternate approaches, let me know so that we can hold off starting the public review.
I'm happy to proceed whichever way you guys want to go.
Best,
/chet
Hello Andrew,
I agree with whatever you think is the best.
Best regards,
Axel
On Mon, Mar 8, 2021 at 1:43 PM Andrii Berezovskyi < andriib@...> wrote:
Hello Axel, Jim,
The CM COS is proceeding as usual but the RM COS is in a bit of a trouble as Paul is not comfortable with the changes I made to RM PS.
If we want the changes to be applied, we need a new round of SoUs and a PS vote. Otherwise, I think we need to hold a new vote to approve RM PS01 as is to progress
to COS. I am most intested in changes 3,4,7. I think Paul will do 1, 2, 5 himself. I think we can convince him to update metadata (8) as well. I don't care much about (6). But I think (3) and (7) are the most important items.
CM COS review will proceed as planned and we can republish RM PS02 and be ready to submit a COS within 3 weeks if I announce intent to publish tomorrow and the new SoUs arrive in parallel during those 3 weeks. In total, it will set us back 6 weeks.
KTH will be able to produce SoUs within the next 3 weeks and I think SodiusWillert should be able to as well. If Jim can get SoUs re-approved within 3 weeks from now, there will be no added delay.
Should we do another PS?
Begin forwarded message:
Subject: [OASIS
Issue Tracker] (TCADMIN-3919) Publish OSLC Requirements Management Version 2.1 PS01 as a candidate for OASIS Standard
Date: 8
March 2021 at 22:32:00 CET
--
![]() |
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
--
![]() |
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
--
![]() |
Paul Knight
Document Process
OASIS Open
|
|
|
|
|
|
--
 |
Paul Knight
Document Process
OASIS Open
|
|
|
|
|
|
-- | Chet EnsignChief Technical Community Steward OASIS Open | | | | |
|
