Editing processes of our ODF TC deliverables

As described last week on the TC mailing list:

https://lists.oasis-open.org/archives/office/202007/msg00021.html
 
 
I would suggest we are bringing all your working draft files into our GitHub repository.
The final ODF 1.2 artefacts are already checked in: odf-tc/src/main/resources/odf1.2
You might want to add your current state-of-work at: * odf-tc/src/main/resources/odf1.3

• odf-tc/src/main/resources/odf1.4

I would suggest to place the ODTs of all parts with the schemas flat in the directories and unzip the ODT in addition n a directory named identical aside with "_" instead of ".".
The reason for the duplication is that the XSLT is not yet able to access the XML within the ODT and Git is just better with pretty printed XML files as with binary blobs.
On the other hand, for convenience, I would like to be able to open quickly open the file without zipping it myself.
There should be a script to unzip them and a pre-commit hook test that both (ODT & unzipped XML) are identical, but one step after the other.
You might as well edit the XML. Although the MIMETYPE should not be compressed, my bet is LibreOffice (LO) will fix it.
After you added your documents, we might test if an update of LO will change the existing parts by loading and saving them (aside from the metadata string).
Michael got such a regression tests AFAIR.
 
In addition, we might want to commit the results of our transformations as well, e.g. for ODF 1.3: odf-tc/src/test/resources/odf1.3/references
It is easier to spot regression if we have the former results of our transformations at hands in history.
Of course, the file names will change in the future according to the input, but the work is quite preliminary at this point.
 
As a rule of thumb. All files being delivered are in the directory: 

• odf-tc/src/main/
  all other files, being mostly test and test documents will reside beyond:
• odf-tc/src/test/  
  I am reusing the Maven build system standard layout. Perhaps later we might switch to Gradle.
   
  GitHub Pages is activated, but I want to improve it, the test commits will be cleaned up later in my fork, I have moved tests to:
  https://github.com/svanteschubert/testing-github-pages/  
   
  For the ODF 1.3 CS02, I would suggest you work without change-tracking most of the format changes is too noisy in change-tracking anyway.
  We should be able to track your changes in the content.xml via GIT.
  Still, it would be helpful if we use GitHub commit on the deliverable artefacts as semantical steps using a certain commit pattern including the issue ID and title.
  Although we are using still JIRA we might want to overtake the GitHub keywords, e.g. I suggest we use: "Fixes #242 bug title".
  In case of the format task, you might add the subtask instead of the bug title.
   
  Last but not least, later we might want to fix one task after the other. Starting with no changes in the beginning, we would enable change tracking for this task.

1. Fix the JIRA issue within the specification
2. The editor would do a pull-request, triggering via Travis several tests.
3. Another TC member as a reviewer will check the task against the JIRA issue - we might want to enable (later) branch protection for review
4. The ODT will be committed as reviewed within GitHub still with change-tracking
5. The ODT will be committed again with GitHub with all changes accepted

Now this iteration would repeat. 
The advantage is that we have change-tracking only for this task and might generate DIFF PDF from the change-tracking ODT to show the changes related to one issue.
The disadvantage we might end up with more than one DIFF PDF if we have to start such iteration for the same issue again and we won't have one DIFF document.
 
As a developer, I would be happy to have a list of changes related to new features with all changes related in one PDF and/or ODT.
In addition, I never liked the all-diff-included with all the format changes, it is far too much noise, as it included all format changes as well.