Maintenance ITI 2021
This is mostly notes and actions from ITI-Planning meeting December 15, 2020
In the first year of publication (not declaring anything about future years)
where html is wrong relative to PDF, html errors, messy html, egregious span, missing style usage)
- continuous update by core members to the github repo
- may use pull requests, but this is not necessary at this time
- use of github.io pages to review
- on regular ITI html meetings (bi-weekly meeting on Mondays)
- committee approval called for
- upon committee approval, the content will be migrated from github to profiles.ihe.net
- no expected version tracking on the profiles.ihe.net, as these are quality issues. The changes can be backtracked in the github repo
any need to change the Technical Framework that would normally qualify for CP process
- Normal process at minimum.
- which means that when ballot is voted approved, the CP is in effect, but not normally integrated until summer
- Summer will integrate the approved CPs into the html (not the WORD/PDF)
Alternative: For one or two CPs (experimenting)
- Integrate the CP to the html when the CP is approved, not waiting for summer
- There would need to be some indication on the pages affected that they have been updated by a CP
- Not clear that the indication needs to be anything more than a page version increment (e.g. that page is marked 17.1)
Alternative for one or two CPs (second experiment)
- Use Github Issue mechanism, and pull-request to run the CP process
- The issue takes the place of the CP header block, the pull-request takes the place of the editing
- Thus the CP ballot would somehow include this for ballot approval
- Unclear if the public would vote using github issue votes, or normal voting (surely normal voting is needed)
- Once the CP is approved, the vote is memorialized in the pull-request acceptance and migration to profiles.ihe.net
at the summer milestone the ITI committees may chose to move some TI supplements to Final Text
- This will require the data extract out of word into html, the cleanup of the html, the breakup into chapter layout
- Major Version on the whole Technical Framework does change
Historically the readership has had access to each major version in the archive. The persistent URL would always go to the current PDF, where if one wants to pin their links to a specific version they must navigate into the archive folder. For example to reference specifically the Version 16 technical framework, there is a URL scheme in the archive for this
https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev16-0_Vol1_FT_2019-07-12.pdf
These versions are only listed in the archive page, and are carefully identified as such.
A similar effect could be achieved by zipping the publication and providing it at a version specific URL.
The positive and negative of this is that there is no way to have a URL to a portion within. This is a positive in that it prevents lock-in to a old version. This is a negative in that it makes it hard to point at the specific text you designed toward (deep links). This is both a positive and a negative. However this is equivalent to what we have today with PDF. And more consistent with IHE model of profiles not being version specific.
Similar solution would not create an archive at all, but rather leverage the tags on the github repository. IHE would just publish the tags used at each release. Reader is free to navigate to that tagged release. This has very low impact on process or storage.
Again, deep links are difficult.
This does rely on reader understanding github tags.
Replicate the whole branch in an archive branch.
This enables deep links to a version specific page.
The archive branch should include search engine instructions to not index to prevent accidental discovery.
This takes up alot of space on the profiles.ihe.net
Not clear the overall benefit for this overhead.