Keeping in mind this is but one way a TC may use branching to do this, but not necessarily the only or best way. There is an entire working group working on an RFC for this. And there is just as many ways of doing this as there are TCs and WGs. While I would love the idea of integrating git into the publication process, I am not sure this is the best way to do it. Git does not lend itself well to tracking changes in large bodies of text. It shows that the entire paragraph has changed. Keep in mind, git was designed for short lines of code not paragraphs and pages of prose text. There is also a significant barrier to entry for people to contribute to a specification when they are required to issue pull requests. This makes working on a standards less attainable by a lot of people. We need to find ways of making it easier for people to contribute, even if that makes it harder for editors. I fear that if we go down this path to quickly, we will start creating an echo chamber of only a few people working on the specs. Google Docs is not necessarily the better choice either given that some people can not access Google Docs. CodiMD or HackMD might be a way of addressing this problem. But we need to find a way to integrate this into an entire workflow and work stream. Looking at this problem and solving tiny parts one at a time is a myopic view and is detrimental to the entire ecosystem that we have here at OASIS. Requirements: - Easily allow individuals to comment on and suggest text modifications - Allow comments on comments and comments on suggestions - Trackability on when things were changed - Integration with publication automation Some of this could be provided by Git or something like Git. But Git falls down on some of these. When I look at this, I see this being solved with something like: A) We need an editor that can allows 1 and 2 above B) We need some automation integration that can take snapshots of a document and load them into something like git C) We need the publication process to work with git and then back feed the editor tool. I think we could find a solution for this, but we need to look at this holistically. I also strongly believe that OASIS should be hosting these tools locally. 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 Tue, Aug 4, 2020 at 7:11 AM Considine, Toby <
Toby.Considine@unc.edu > wrote: Keeping the TAB informed of changes in the way GitHub is being used as part of a TC Process. tc From:
openc2@lists.oasis-open.org <
openc2@lists.oasis-open.org > on behalf of Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com > Sent: Monday, August 3, 2020 3:57 PM To:
openc2@lists.oasis-open.org <
openc2@lists.oasis-open.org > Subject: [openc2] Proposed Simplification of GitHub Repository Branching Strategy After various discussions and some analysis, I'm proposing a simplification of the GitHub repository branching strategy currently defined in the TC' Documentation Norms . While this primarily affects work product editors, the norms and the repositories are in support of the TC's objectives, so I'm sending this to the TC mail list / Slack #general channel. The current approach has three branches: published (formerly master ) release working My proposal is to eliminate the release branch in favor of only using GitHub " Releases " . The original intent of the three branch structure was that work product development would occur in the working branch and be checkpointed to the release branch when the editor declared a working draft (WD), using a pull request. The published branch is reserved for TC/OASIS-approved specifications and standards. Another part of this strategy was to use the GitHub "Release" feature to package the WD, creating a ZIP file for uploading to OASIS. In short, I've realized that both having a release branch and creating release packages is redundant: a release package can be based on the working branch and it's just as easy to find by examining the repository's Release entries as by looking at the release branch. If anyone sees a reason to retain the current three-branch strategy, please articulate it in a reply. Dave David Lemire Systems Engineer HII Mission Driven Innovated Solutions (HII-MDIS) Technical Solutions Division 302 Sentinel Drive Annapolis Junction, MD 20701 Work (301 ) 575 -5190 Mobile (443) 535 - 1182 Attachment: smime.p7s Description: S/MIME Cryptographic Signature