On 2021-03-15 , at 21:22, Andrii Berezovskyi <andriib@...> wrote:

Dear Pieter,

I am sure you are aware of W3C LDN. You may also be interested to check out TRS, an OSLC spec (W3C LDP grew out of the early OSLC efforts):

https://archive.open-services.net/wiki/core/TrackedResourceSet-2.0/

https://oslc-op.github.io/oslc-specs/specs/trs/tracked-resource-set.html (v3.0 draft)

The TRS spec is essentially defining a paged set of "base" resources and a "truncateable" change log. TRS is used by tools like IBM Jazz and others to publish a stream of changes to the engineering artefacts (e.g. requirements, bug reports).

I had a brief look at LDES and it seems like a great effort beyond OSLC TRS and W3C LDN (if you persist the stream of LDN Notifications). Thank you for a great effort! I think the biggest difference is that both TRS and LDN only represent resource change events, referring the consumers to the resources themselves for the updated state while LDES goes further by allowing any resource to be part of the stream. On our part, the ability to include trs:Creation/Modification/Deletion events ([1] specifies their OSLC shapes, which was a precursor to SHACL in some sense [3]) should be enough to represent all TRS events in the LDES stream.

The only thing that may need special attention is the retention policy. TRS specifies a server-triggered rebase paired with the truncation of the log. As a result, the trs:cutoffEvent property gets updated to move ahead. I don't think either of the two currently defined LDES retention policies would allow to represent TRS log truncation faithfully.

I think it would be even more beneficial to allow LDN Senders to publish an LDES Stream of LDN Notifications for durability reasons. 

Looking forward to see LDES to take off!

Best regards,
Andrew

--

Andrew Berezovskyi

KTH Royal Institute of Technology

OSLC PGB co-chair

Eclipse Lyo project lead

[1]: https://oslc-op.github.io/oslc-specs/specs/trs/trs-shapes.ttl

[2]: https://archive.open-services.net/wiki/core/TrackedResourceSet-2.0/#Truncated-Change-Logs

[3]: http://book.validatingrdf.com/bookHtml009.html#sec49

On 2021-03-15 , at 20:36, Pieter Colpaert <pieter.colpaert@...> wrote:

Dearest public LOD mailing list,

I was looking for a specification, a bit like RSS, that would allow me to tell potential data consumers that:

 - I’m maintaining a collection of members adhering to a certain shape,

 - that they they can find and download all of the members, and

 - that I want them to stay in sync with the latest changes.

As I did not find a solution in for example LDP, Hydra or Activity Streams 2, I made my own. You can find the Linked Data Event Streams (LDES) specification over here: https://w3id.org/ldes/specification. It does not do much: it just defined an event stream as a collection of an ever-growing collection of objects that never change (“version objects”).

It is based on the TREE specification (https://w3id.org/tree/specification) which in its turn allows more than simple one-dimensional paging. It allows to make your collection searchable using qualified links to following pages (or tree:Nodes). This means you can for example geospatially tile your LDES [1] or expose a file-based substring index [2]. Of course, you can also just load the LDES in a triple store and make sure your copy always stays in sync with the authoritative data source. TREE also foresees compatibility with hypermedia specs and collection designs in LDP, Hydra, Activity Streams 2, Shape Trees and Triple Pattern Fragments. Over the coming months we are planing to publish some governmental base registries with this specification.

Are there any other specs LDES should be compatible to?

Kind regards,

Pieter

P.S. Tomorrow I’m speaking at this online event called ENDORSE about this specification and the ideas behind it. More info: https://op.europa.eu/en/web/endorse/programme

[1] We last year published about a geospatial fragmentation in this paper: https://hdelva.be/articles/geospatial-linked-connections/

[2] Check out an autocompletion demo on top of a TREE collection fragmented by substring here: https://treecg.github.io/treemunica_typeahead_demo/ - I can send a preprint of a paper we wrote about this if interested.

--
https://pietercolpaert.be/#me

On 2021-03-15 , at 20:36, Pieter Colpaert <pieter.colpaert@...> wrote:

Dearest public LOD mailing list,

I was looking for a specification, a bit like RSS, that would allow me to tell potential data consumers that:

 - I’m maintaining a collection of members adhering to a certain shape,

 - that they they can find and download all of the members, and

 - that I want them to stay in sync with the latest changes.

As I did not find a solution in for example LDP, Hydra or Activity Streams 2, I made my own. You can find the Linked Data Event Streams (LDES) specification over here: https://w3id.org/ldes/specification. It does not do much: it just defined an event stream as a collection of an ever-growing collection of objects that never change (“version objects”).

It is based on the TREE specification (https://w3id.org/tree/specification) which in its turn allows more than simple one-dimensional paging. It allows to make your collection searchable using qualified links to following pages (or tree:Nodes). This means you can for example geospatially tile your LDES [1] or expose a file-based substring index [2]. Of course, you can also just load the LDES in a triple store and make sure your copy always stays in sync with the authoritative data source. TREE also foresees compatibility with hypermedia specs and collection designs in LDP, Hydra, Activity Streams 2, Shape Trees and Triple Pattern Fragments. Over the coming months we are planing to publish some governmental base registries with this specification.

Are there any other specs LDES should be compatible to?

Kind regards,

Pieter

P.S. Tomorrow I’m speaking at this online event called ENDORSE about this specification and the ideas behind it. More info: https://op.europa.eu/en/web/endorse/programme

[1] We last year published about a geospatial fragmentation in this paper: https://hdelva.be/articles/geospatial-linked-connections/

[2] Check out an autocompletion demo on top of a TREE collection fragmented by substring here: https://treecg.github.io/treemunica_typeahead_demo/ - I can send a preprint of a paper we wrote about this if interested.

--
https://pietercolpaert.be/#me

On 2021-03-09 , at 21:00, Paul Knight <paul.knight@...> wrote:

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

[1] https://issues.oasis-open.org/browse/TCADMIN-3919?focusedCommentId=78916&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-78916

[2] https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26

[3] https://www.oasis-open.org/policies-guidelines/open-projects-process

[4]  https://www.oasis-open.org//policies-guidelines/oasis-defined-terms-2018-05-22#dMaterialChange

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>

--
Cheers,
Andrew

On 2021-03-09 , at 19:38, Paul Knight <paul.knight@...> wrote:

Hi all,

Sounds like a good resolution here.

Just a couple of clarifications:

- I have no objections to any of the changes (in https://github.com/oasis-open-projects/administration/issues/19#issuecomment-778436803). My concern was how the changes in RM v2.1 are prepared for publication, and I believe we have resolved that now.

- 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

On Tue, Mar 9, 2021 at 12:52 PM Axel Reichwein <axel.reichwein@...> wrote:

I'm ok with the proposal.

Best regards,

Axel

On Mon, Mar 8, 2021 at 2:34 PM Chet Ensign <chet.ensign@...> wrote:

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.

--
Cheers,
Andrew

P.S. Jim, it was Chet who was OK with my changes when I asked, not Paul.

On 2021-03-08 , at 22:50, Chet Ensign <chet.ensign@...> wrote:

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

On Mon, Mar 8, 2021 at 4:48 PM Axel Reichwein <axel.reichwein@...> wrote:

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.

The list of changes: https://github.com/oasis-open-projects/administration/issues/19#issuecomment-778436803

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?

--
Cheers,
Andrew

Begin forwarded message:

From: OASIS Issues Tracker <workgroup_mailer@...>

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

To: andriib@...

   [ https://issues.oasis-open.org/browse/TCADMIN-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=78910#comment-78910 ] 

Andrii Berezovskyi commented on TCADMIN-3919:
---------------------------------------------

Can we put this on hold for a bit and proceed with another COS (CM) for now? We will discuss this on the mailing list till the weekly Thursday call, but I don't think we can proceed with this in any case: you will be either publishing the package with changes you don't want to see added between PS and COS or you will be publishing the package that is not the package the PGB has voted on. I think we can redo the SoUs to make sure everything is top notch but I have to ask what Jim and Axel think about this.

Publish OSLC Requirements Management Version 2.1 PS01 as a candidate for OASIS Standard
---------------------------------------------------------------------------------------

               Key: TCADMIN-3919
               URL: https://issues.oasis-open.org/browse/TCADMIN-3919
           Project: Technical Committee Administration
        Issue Type: Task
        Components: Document Upload Request
       Environment: OSLC OP
          Reporter: Chet Ensign
          Assignee: Paul Knight
          Priority: Major

Submitted on Friday, March 5, 2021 - 23:27
Submitted by user: censign
Submitted values are:
Your name: Chet Ensign
TC name: OSLC Open Project
TC email address: oslc-op-pgb@...
Title: OSLC Requirements Management Version 2.1 PS01
Approval link:
https://lists.oasis-open-projects.org/g/oslc-op-pgb/topic/approve_submitting_oslc/80909739?p=,,,20,0,0,0::recentpostdate%2Fstick
Original or Amended:  First COS
Previous Candidate OASIS Standard:
Notes: Entered on behalf of the OP after ballot passed. This will be our
first
Project Specification put forward as a candidate for OASIS Standard so adjust
public review metadata accordingly.
The results of this submission may be viewed at:
http://tools.oasis-open.org/issues/browse/TCADMIN

--
This message was sent by Atlassian Jira
(v8.3.3#803004)

-- 

Chet Ensign Chief Technical Community Steward OASIS Open

+1 201-341-1393 chet.ensign@... www.oasis-open.org

-- 

Chet Ensign Chief Technical Community Steward OASIS Open

+1 201-341-1393 chet.ensign@... www.oasis-open.org

-- 

Paul Knight Document Process OASIS Open +1 781-883-1783 paul.knight@... www.oasis-open.org

--

Paul Knight Document Process OASIS Open +1 781-883-1783 paul.knight@... www.oasis-open.org

On 2021-03-09 , at 19:38, Paul Knight <paul.knight@...> wrote:

Hi all,

Sounds like a good resolution here.

Just a couple of clarifications:

- I have no objections to any of the changes (in https://github.com/oasis-open-projects/administration/issues/19#issuecomment-778436803). My concern was how the changes in RM v2.1 are prepared for publication, and I believe we have resolved that now.

- 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

On Tue, Mar 9, 2021 at 12:52 PM Axel Reichwein <axel.reichwein@...> wrote:

I'm ok with the proposal.

Best regards,

Axel

On Mon, Mar 8, 2021 at 2:34 PM Chet Ensign <chet.ensign@...> wrote:

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.

--
Cheers,
Andrew

P.S. Jim, it was Chet who was OK with my changes when I asked, not Paul.

On 2021-03-08 , at 22:50, Chet Ensign <chet.ensign@...> wrote:

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

On Mon, Mar 8, 2021 at 4:48 PM Axel Reichwein <axel.reichwein@...> wrote:

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.

The list of changes: https://github.com/oasis-open-projects/administration/issues/19#issuecomment-778436803

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?

--
Cheers,
Andrew

Begin forwarded message:

From: OASIS Issues Tracker <workgroup_mailer@...>

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

To: andriib@...

   [ https://issues.oasis-open.org/browse/TCADMIN-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=78910#comment-78910 ] 

Andrii Berezovskyi commented on TCADMIN-3919:
---------------------------------------------

Can we put this on hold for a bit and proceed with another COS (CM) for now? We will discuss this on the mailing list till the weekly Thursday call, but I don't think we can proceed with this in any case: you will be either publishing the package with changes you don't want to see added between PS and COS or you will be publishing the package that is not the package the PGB has voted on. I think we can redo the SoUs to make sure everything is top notch but I have to ask what Jim and Axel think about this.

Publish OSLC Requirements Management Version 2.1 PS01 as a candidate for OASIS Standard
---------------------------------------------------------------------------------------

               Key: TCADMIN-3919
               URL: https://issues.oasis-open.org/browse/TCADMIN-3919
           Project: Technical Committee Administration
        Issue Type: Task
        Components: Document Upload Request
       Environment: OSLC OP
          Reporter: Chet Ensign
          Assignee: Paul Knight
          Priority: Major

Submitted on Friday, March 5, 2021 - 23:27
Submitted by user: censign
Submitted values are:
Your name: Chet Ensign
TC name: OSLC Open Project
TC email address: oslc-op-pgb@...
Title: OSLC Requirements Management Version 2.1 PS01
Approval link:
https://lists.oasis-open-projects.org/g/oslc-op-pgb/topic/approve_submitting_oslc/80909739?p=,,,20,0,0,0::recentpostdate%2Fstick
Original or Amended:  First COS
Previous Candidate OASIS Standard:
Notes: Entered on behalf of the OP after ballot passed. This will be our
first
Project Specification put forward as a candidate for OASIS Standard so adjust
public review metadata accordingly.
The results of this submission may be viewed at:
http://tools.oasis-open.org/issues/browse/TCADMIN

--
This message was sent by Atlassian Jira
(v8.3.3#803004)

-- 

Chet Ensign Chief Technical Community Steward OASIS Open

+1 201-341-1393 chet.ensign@... www.oasis-open.org

-- 

Chet Ensign Chief Technical Community Steward OASIS Open

+1 201-341-1393 chet.ensign@... www.oasis-open.org

-- 

Paul Knight Document Process OASIS Open +1 781-883-1783 paul.knight@... www.oasis-open.org

On 4 March 2021, at 16:00, oslc-op@... Calendar <noreply@...> wrote:

oslc-op Weekly Contributors Meeting

When:
Thursday, 4 March 2021
10:00am to 11:00am
(GMT-05:00) America/New York

Where:
https://meet.jit.si/oslc-op

Organizer:
jamsden@...

Description:
oslc-op contributors weekly telecon. 

Join meeting: https://meet.jit.si/oslc-op#config.startWithVideoMuted=true 

One tap audio Dial In: +15124022718,,,,2979764690# (US) or +498938038719,,,,2979764690# (Germany) Looking for a different dial in number? Please see: https://meet.jit.si/static/dialInInfo.html?room=oslc-op

Meeting ID: 2979764690#

 

The meeting minutes are edited in https://hackmd.io/@driib/oslc-op-minutes/edit
Previous minutes can be found under https://github.com/oslc-op/oslc-admin/tree/master/minutes/2019 

OASIS OSLC Open Project group home: https://lists.oasis-open-projects.org/g/oslc-op 
oslc-op GitHub Organization: https://github.com/oslc-op
Mailing list: oslc-op@... (archives: https://lists.oasis-open-projects.org/g/oslc-op)

On 25 February 2021, at 20:22, Chet Ensign <chet.ensign@...> wrote:

Participants of the OSLC Open Project, 

A Special Majority Vote to consider submitting Requirements Management V2.1 and Change Management v3.0 as candidates for OASIS Standard has been set up.

The ballot is open now. It closes 05 March 2021 at 23:59 UTC. You can access the ballot at:

https://lists.oasis-open-projects.org/g/oslc-op-pgb/topic/approve_submitting_oslc/80909739?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80909739

This ballot is only open to members of the PGB. I currently show the following members as eligible to vote:

Jim Amsden (IBM)
Andrew Berezovskyi (KTH Royal Institute of Technology)
Axel Reichwein (Koneksys)

If your name is not on the list and you believe this to be in error, please contact me and the Chair so that we can resolve the issue.

Best regards, 

/chet   

--

Chet Ensign Chief Technical Community Steward OASIS Open

+1 201-341-1393 chet.ensign@... www.oasis-open.org