==============================================================
Minutes TAB call (Sep 6, 2013)
==============================================================


Info

Dial:
Host confcall: Fujitsu
US Toll Free: 877-995-3314
US Toll/International: 210-339-1806


Agenda

1. Admin:
- minutes Aug 23, (minutes posted)
- action items status
- aspects of using JIRA to track TAB's work, tooling

2. Public Reviews process for TAB : follow-up on details of review process
- Selective review items from checklist?
- Use of JIRA, exports.
- what standing should have "TAB" review ? (TAB members review in their name, or represent TAB view?)

3. Normative Keyword directives doc review, possibly approval.

4. Follow-up on exploratory work and tooling:
- " Manifest" proposal review: (Chet/Robin)
https://tools.oasis-open.org/issues/browse/TAB-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34450#action_34450
- "concordance" tool and potential use (Patrick)

5. Conformance Guidelines 2.0,
- review and refinement of posted issues.
- general scoping, notion of "normative content".


Roll:

Ashok Malhotra (Oracle)
Chet Ensign (staff)
Patrick Durusau (individual)
Jacques Durand (Fujitsu)
Zhexuan Song (Huawei)


Action Items status: [status-change]

AI-4: [open] Chet: propose rewording of Policy statements for keywords on spec templates. - still open
AI-5: [close] Ashok to investigate 3rd party documentation tracking - A did look at other doc mgmt systems. All heavyweight.
Nothing Ashok would recommend for us at this time. Closing the issue.
AI-6: [close] Jacques: open a JIRA entry to manage Conformance Guidelines and related issues - Done
AI-7: [close] Chet to clean-up the current JIRA TAB project (close old issues) - done.
AI-8: [close] Chet to set up the JIRA TAB component Public Reviews - done.
AI-9: [close] Patrick to add RFC examples of keyword use in the Keywords Guidelines - done.
AI-10: [open] Chet to configure JIRA to show how it might look using Version for the name of the public review


Minutes:

1. Admin:
- minutes Aug 23, (minutes posted): approved.
- action items status (see above)
- aspects of using JIRA to track TAB's work: All TAB work will be tracked with JIRA: PRs, long-lasting action items, guidelines.

2. Public Reviews process for TAB : follow-up on details of review process
- JIRA model for PRs: Keep the generic "PR [JIRA] component", but still create an individual issue for each individual comment on each individual specification. Then how to group/partition per specification reviewed? Use the Environment field to identify the work product being reviewed ? Chet: Use the Version field seems best.
- Selective review items from checklist? Still TBD. Jacques: TAB should certainly focus on review items that others are unlikely to cover. That’s where we can show real value in TAB reviews.
- Use of JIRA, exports.
New AI-10: Chet to configure JIRA to show how it might look using Version for the name of the public review
- what standing should have "TAB" review ? (TAB members review in their name, or represent TAB view?)
Ashok: if I post a comment, is it a TAB comment? An Oracle comment? An individual comment?
Chet: careful to not hierarchize the comments (TAB vs. individual).
Chet: tricky to ask TAB to author comments. Some overhead. Need vote, etc.
Chet: Should be individual comment, but signed as a member of the TAB (an "educated" comment).
Patrick: TAB should get credit for doing reviews.
Chet: cases where the TAB member needs to bring back to TAB level, is issues that need be escalated to TC process board, or staff.
Chet: should report the practices of TCs as seen in drafts.
J: in conclusion - we don't see a need to make any distinction between whether a review comes from the TAB or the individual. Some may however raise to the level of something we might want to discuss as a group.
- do we want to categorize the comments we make? (conf clauses vs. references vs. use of keywords vs. etc.) We'll look at it after populating a critical mass of comments.

3. Normative Keyword directives doc review, possibly approval.
- Goal is to have the next version of the document approved and ready to show the Board by their next meeting, mid-Oct.
- review of the latest iteration from Patrick and provided feedback. In particular: MAY NOT a keyword. Should be used as a bad example (from real specs... just obfuscate their name). In a note, which is non-normative text, keywords should not appear.

4. Follow-up on exploratory work and tooling:
- " Manifest" proposal review: (Chet/Robin)
https://tools.oasis-open.org/issues/browse/TAB-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34450#action_34450 - "concordance" tool and potential use (Patrick)
We postpone this (Robin not here).

5. Conformance Guidelines 2.0,
- review and refinement of posted issues:
list in the TAB JIRA -> https://tools.oasis-open.org/issues/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10104&sorter/order=DESC&sorter/field=priority&resolution=-1&component=10373 There was a discussion on mail list about:
distinction between a conformance clause, normative text and the use of keywords.
See emails 8/25, 8/30 titled: "Conformance clauses and keywords"
This relates directly to Conformance Guidelines issues #11, #14, #15
More in-depth discussion for next meeting.

20130906 (last edited 2013-12-05 18:02:14 by chet.ensign)