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

[aa tt <atcyber1000@gmail.com>]

To add my 2cents.

I mostly agree with everything that Bret is saying and would add that our primary objective is to make progress on the content of our specifications. No matter how feedback or content is provided. If you or anyone else has contribution to that goal I would rather we focus on the content of that contribution than be fixated on the required process.

And personally the process we follow should be focused on accelerating our work or helping us be more efficient. Not slowing us down.

So whatever form you want to send us your comments then please send them. 

A google doc or word doc with comments attached works pretty well for tc member feedback. Preferably you also include suggested text changes that resolves a comment so that it makes it easier for us to review and resolve the comment.

All issues will be reviewed and resolved. If the tc decides this is insufficient process and the tc wants a different process then we can decide that on the next working call.

Allan

On Sep 14, 2020, at 7:23 AM, Bret Jordan <bret.jordan@broadcom.com> wrote:

ï

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