=================================================
Minutes of the OASIS DITA TC
Tuesday, 14 February 2017
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendasBusiness
========
1. Roll call
Regrets: Stan Doherty
2. Approve minutes from previous business meeting:
14 February:
https://lists.oasis-open.org/archives/dita/201702/msg00030.html (Nancy Harrison, 14 February 2017)
Changes requested:
https://lists.oasis-open.org/archives/dita/201702/msg00031.html (Eberlein, 21 February 2017)
Resubmitted:
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201702/msg00052.html (Nancy Harrison, 23 February 2017)
21 February:
https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201702/msg00054.html (Tom Magliery, 24 February 2017)
Both sets of minutes moved by Tom, seconded by Bob, approved by TC
3. Announcements:
New TC members: None
4. Action items
23 August 2016:
Kris: Get TC instance of DITAweb updated with 1.3 DTDs; restore sync with SVN (IN PROGRESS)
6 September 2016
Kris: Revise subject scheme example topic pulled from errata 01
4 October 2016:
Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS)
25 October 2016
Deb: Develop FAQ for folks new to DITA TC (IN PROGRESS)
21 February 2017
Kris: find someone from the iiRDS working group to come to TC meeting and do presentation.
Kris: correct error in sourc 2.2.3.4 processing controlled att values
Robert, Kris, Dick, Dawn: discuss workflow/admin practices for errata 02
[didn't meet]
Eliot: Update the grammar files to fix allowed number of in
[not yet]
Robert: Correct the content model appendix topics for / for the same.
[actually for errata 02] AI; needs to get added to errata 02 list
Robert: Robert: Correct the ditavalmeta section so the example link goes DIRECTLY to the example.
[same as above; for errata 02]
Robert: update 2.0 proposal wiki page to point here:
https://wiki.oasis-open.org/dita/DITA_2.0_Proposals (COMPLETED)
**ActionItem; Tom will make sure his minutes from Feb 24 include all the data; some of it didn't come through.
5. NEW Item: Overview of DITA 2.0 Proposal Process
Draft of 2.0 proposal process:
https://wiki.oasis-open.org/dita/DITA_2.0_Proposal_Process_DRAFT Robert; we need for everyone on the TC to be evaluating this Stage 2 template:
https://www.oasis-open.org/committees/download.php/60163/2-0template.htmlTom; we've been moving all proposals into proposal process; we've made some changes to proposal process. One thing that's new for 2.0 is that all proposals will be stored in source form in SVN, rather than in KAVI; everything we do with a proposal goes through at our meetings, every change needs to be recorded in minutes. At Stage 1, the proposal process is relatively informal; goes from brand-new idea to general agreement by TC. Then it needs a designated champion
At stage 2, if we're adding a new element, the stage 2 proposal will include all the implications of adding the new element. If something comes up that requires a change, then we iterate this review process after the changes have been made.
At stage 2, casting a vote of 'no objection' means that you've at least read and studied the proposal; if there are too many 'no objection' votes, that might be a reason to do re-consider the proposal.
Robert; if a proposal relates to major stuff in the spec, too many 'no objection' votes should raise a flag, For something trivial, it wouldn't concern me.
Eliot; in 1.3, all proposals got considered, but some of the interactions between proposals didn't get quite enough consideration.
Robert; I agree.
Deb; I don't remember it being a problem at 1.3.
Tom; we've made one tweak; no champion can own more that 3 proposals at the same time. That is, one person can champion more than 3, but not simultaneously, you'd have to get some done before you can start more.
Robert; when you go through the draft template for stage 2, please think about overall usability. Is it easy to use? Note the new section on 'backwards compatibility'. This 2.0 release is the fist one to allow for backwards incompatibility, so the first time we've needed this section.
https://wiki.oasis-open.org/dita/DITA_2.0_Proposal_Process_DRAFTBob; one question; how about doc shell configuration in default schemas/RNG/DTD?
Tom; if it's removing something, that's covered.
Robert; what about if you're adding something?
Bob; what about removing something from a shell without removing it from the specification?
**ActionItem; Robert will add that to the template.
Robert; if there's anything that changes compatibility, you have to add that in the 'backwards compatibility' section. If documents need to be updated, how will that be done? by hand? by vendor tools? scripted? The goal for this section is for migration info to be published, but not to be in the spec.
Tom; so we need to consider whether /how the TC willl disseminate this useful information. The period of development is when this useful info will become available to us, but how will we make it available to others? There needs to be something happening on a parallel track to the spec; we don't want spec editors to be doing this side work.
Robert; hopefully migration info will be clean enough to add to a migration paper. Which creates the potential role of 'migration master'
Tom; everyone should be thinking about volunteering for that,..
Robert; we need to consider whether there can there be compatibility issues that don't affect migration.
Robert; finally, look at end of template... Here we have considerations wrt new terminology. For tool vendors, what's the cost to implement? And will this make DITA seem more complex? IF this is breaking compatibility, how many docs are likely to be affected? cost??
Deb; should we add cost of writing a CN or white paper?
Robert; I don't know if we need to add that kind of thing or not; we don't know if every proposal will need a separate, dedicated white paper
Nancy; what about referencing deprecated stuff, in case of backwards compatibility issues?
Robert; good idea, I'll add it.
ActionItem; Robert will add note about referencing deprecated elements/attributes to template.
Tom; after template is complate, and has been approved, then we have a fully baked set of content. Then, the champion will polish up language to be good specification/langref content. Any changes to grammars that need to be made are made and complete. Then you have a peer review process, at lease 2 reviewers. Need to have just about every TC member involved in this. review takes places offline, not as part of TC meeting. But once the review is done, discussed again at TC meeting, another [roll call] vote a week later. [yes, no, abstain]
Chris; Are there any other things we could put on the proposaers shoulders, to offload Robert and Kris?
Tom [will bring it up next week]
12 noon ET close