OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cacao message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cacao] Re: Method of work and Comments


HiÂToby,

Thanks for your email and comments. There is nothing in OASIS Policy that prevents us from continuing to do what we have been doing or what was done in STIX and TAXII. We will track all comments receivedÂduring public review and will upload that log to the comment-list and to kavi. There is no requirement to release a new draft every month. Nor is there a requirement to log every change and every issue in JIRA. However, we will track major issues and major changes in our Github Issue tracker.Â

As always we will discuss all issues on our working calls and try to drive every issue to consensus. The TC gating function is every time we release a CSD there will be a vote. If a TC member is unhappy with the way a document or issue is progressing the best way to handle that is on a working call. If that does not work, they can always cast their vote in the negative when we release a new CSD.Â

If you have comments on the document please send them in. But as you know, you are a TC member and are not required to use the publicÂcomment process. Nor are your comments and suggestions limited to only the public comment period. As a TC member you can submit comments and suggestions at any time. That is the benefit of being a TC member. While it is true the public can also submit comments and suggestions at any time through the public comment period, the TC is only required to respond to those that come in during a public review. However, my policy has always been to respond to all public comments.Â

Using GIT for documents is far from ideal. We have tried it and have done a lot of work with it in the IETF. There is even an IETF working group to write an RFC on how to use GIT for standards work. But git is designed for code, aka short little statements. It does not work well for paragraphs. Also, the cost of entry for people to comment is often a lot higher, unless they are normally a code developer and used to working in GIT. I have worked with Chet on several online editor tools for markdown to make using git more possible, but it is still a clunky process. HackMD and the free version called CodiMD look to be the most promising, but there is still a lot of work that would need to be done to integrate this into the OASIS process. When I was a board member I tried to put in place a lot of foundation elements to make a transition like this possible.Â

Please send your comments to the TC list so we can review them on our next working call.Â

Thanks,
Bret
PGP Fingerprint:Â63B4 FC53 680A 6B7D 1447 ÂF2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."


On Sun, Sep 13, 2020 at 1:32 PM Considine, Toby <Toby.Considine@unc.edu> wrote:
Sorry, partial email sent because left tab for paragraph was interpreted as send from within the browser... Please ignore and use the following...

===

We are entering a more formal part of the OASIS process. We have a Public Review outstanding, and we have received comments.Â

Â

Under the Oasis process, all comments must be tracked and their disposition recorded. These comments and dispositions mut be publicly reviewable.Â

Â

A brief oversight of this process can be read atÂhttps://www.oasis-open.org/resources/toolsÂ

Â

The result of this is that informal group editing of Google Docs is no longer appropriate. One big reason is versioning. There must be formal versions for comments to be linked to formal versions.Â

Â

I am aware of two ways this is done in OASIS.ÂÂ

1) Each working draft from here on out must be properly tracked within KaviÂ

At least once a month (unless no work has been done), and prior to each TC meeting at which one or more draft documents will be discussed,ÂWorking DraftÂlevel material for any/all such documents must be uploaded to theÂTC document repository, properly identified according to theÂOASIS Naming Directives; links to the non-Kavi publication venues are insufficient

Under this model, comments are tracked in OASIS Jira. All comments are entered there, assigned as necessary, and potentially the resolution is voted on. (Most issues do not require committee votes, but some do, and it is often considered good practice to have a formal vote accepting all the Kavi managed issues in advance of the next publication.)Â

As far as I can tell, no Jira project for Cacoa has been created, so there are definitely no issues.Â

Â

2) Working Drafts move into Github. Working Drafts must still be released as if it were in Kavi. There are a host of other procedures which, in the spirit of specifications, I reference rather than incorporate here.Â

If managed in GitHub, each comment is entered as a Pull Request. Pull Requests can be worked as any other issue, and may require TC votes to resolve.Â

Â

I raise the issue now because I see that nothing has been done in the git for CACAO for more than eight months. (https://github.com/oasis-tcs/cacao). Again, we have issues and comments but they are not being logged.Â

Â

Have we, as a TC decided on which path to use, yet?Â

If the path is in Github, as hinted at by the existence of the repository, then some work needs to be done including but no limited to:Â

  1. Enter the CSD01 into Github as a releaseÂ
  2. Initiate a working branch (WD04?) from CSD01Â
  3. Begin entering the comments as pull requests, linked to the appropriate text as appropriateÂ

Â

I have numerous comments from the ongoing Public Review. I need to know if I shouldÂ

  1. Write them all up, and submit them as one massive multi-part comment to CACAO-commentsÂ
  2. Start entering Jira IssuesÂ
  3. Begin entering Pull Requests, which requires that the branch described above be created.Â

Â

If this was decided previously, and I missed it, my apologies. Â

Â

ThanksÂ

Â

tcÂ





From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org> on behalf of Considine, Toby <Toby.Considine@unc.edu>
Sent: Sunday, September 13, 2020 3:14 PM
To: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>
Subject: [cacao] Method of work and Comments
Â
We are entering a more formal part of the OASIS process. We have a Public Review outstanding, and we have received comments.

Under the Oasis process, all comments must be tracked and their disposition recorded. These comments and dispositions mut be publicly reviewable.

A brief oversight of this process can be read atÂhttps://www.oasis-open.org/resources/tools

The result of this is that informal group editing of Google Docs is no longer appropriate. One big reason is versioning. There must be formal versions for comments to be linked to formal versions.

I am aware of two ways this is done in OASIS.Â
1) Each working draft from here on out must be properly tracked within Kavi
At least once a month (unless no work has been done), and prior to each TC meeting at which one or more draft documents will be discussed,ÂWorking DraftÂlevel material for any/all such documents must be uploaded to theÂTC document repository, properly identified according to theÂOASIS Naming Directives; links to the non-Kavi publication venues are insufficient


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]