=============================================================

Minutes TAB call (August 19, 2016)

=============================================================

Info

Time: 2pmET

Dial:

Host confcall: OASIS

US Toll Free: +1 641 715-3822

Chat room: http://webconf.soaphub.org/conf/room/tab

Agenda

1) Roll call

2) Approval of agenda

3) Approval of minutes August 12:
https://lists.oasis-open.org/archives/tab/201608/msg00020.html

4) Status of public reviews

No first public reviews open at this time

5) Status of open action items

- AI: Patrick - merge proposed Conformance Clause edits with current working draft & send to Ashok
- AI: Jacques: rough draft of memo on TAB thinking for Liger projects

6) Review Patrick's draft of merged Conformance Clauses document

7) Discuss Jacques draft on Open Project (Liger) initiative and decide on final proposal

8) Approve 2016/2017 work plan

9) AOB

Minutes

1) Attending: Ashok, Chet, Kevin, Jacques, Patrick

2) Approval of agenda

Requests to hold off discussion of conformance clause document. Removed item 6.

No further discussion. No objections to approval. Agenda as modified approved.

3) Approval of minutes August 12th.

No discussion. No objections to approval. Minutes approved.

4) Status of public reviews.

No first public reviews open or pending at this time.

5) Status of open action items.

- AI: Patrick - merge proposed Conformance Clause edits with current working draft & send to Ashok
AI completed. Closed.

- AI: Jacques: rough draft of memo on TAB thinking for Liger projects
AI completed. Closed.

7) Discuss Jacques draft on Open Project (Liger) initiative and decide on final proposal

Jacques cautions that this is a very rough first draft.

Ashok asked whether OASIS would consider open source projects that don't plan to do a standard? Agreed that we wouldn't necessarily want to exclude those. They could evolve over time.

Ashok noted that working in some of the other organizations can be quite expensive. Membership fees can be high. One OASIS value proposition: not as costly as other organizations AND for 1 membership fee you can do both: open source and standard.

Kevin observes that whether open source or standards, the process shouldn't be any different. It should be the same whether they start out knowing what they want to do or not. Going from open source to standards track shouldn't require rechartering or starting a new TC or other bureaucratic hoops.

The big challenge will be modifying the process governing the work so that it covers both. Kevin also suggests we leave cost out of our thinking for now; much more important to get the process right.

Jacques notes that this may be tricky. The process will have to look like typical open source projects while at the same time allowing a specification to transition into the standards workflow smoothly. OASIS should look to aggressively reform the TC Process, especially public reviews and approvals. That's where the differences will be.

Jacques suggests OASIS not overtly position itself as being in competition with other established orgs. We may suffer by comparison.

Jacques suggests we brainstorm the types of open source projects we could see coming to OASIS:

Patrick agrees - deeply in favor of a seamless process where you can start doing either one - open source or spec - and move on to the other.

Patrick suggests we ask somebody who might want to bring a project to OASIS. For example, something like MS Powershell (https://msdn.microsoft.com/en-us/powershell/mt173057.aspx - just started on github). Doing that would be better than trying to imagine something in the abstract. Possible we could even work through the start up with them and redefine the process in partnership.

Ashok asks if it wouldn't it be enough to compare oasis rules with rules at other orgs, e.g. Apache. In other words use the comparison with their rules to draft a first pass at our revised process. Jacques suggests we look closely at the W3C. They are being pushed by their developers to change. Notes that W3C has introduced 'community groups' that are incubators where you don't have to be a member.

Chet asks if TAB members have any suggested contacts. None come to mind. Kevin suggests we could just contact some project contributors.

Jacques notes that one of the culture differences will be that people developing code are very comfortable putting out releases that are not backwards-compatible. People doing standards on other hand value stability over time. So an open source group might to bless an API as standard even though they will break it in the next release. So there is a bit of a mismatch between developers expectations and their manager's expectations.

Patrick notes however that there are projects that maintain separate, incompatible versions and don't see it as a problem. ODF 2.0 will be incompatible with previous versions. (Chet notes here in the minutes that the CTI TC is doing exactly the same with STIX and TAXII 2.0.) So we need to be aware of the difference in culture - the dev's work continuously while the standards people want to stabilize it at some point - but that doesn't have to be a show stopper.

Jacques revises his statement: one of the problems with standards is that users are kept waiting. Open source may be a moving target but users don't have to wait until something is approved and can start basing business activity on the evolving code as soon as something is running. Then once the group converges on a version that everyone feels comfortable is stable, they can branch that off to standardize it.

Patrick requests that we stop calling it 'liger.' Kevin suggests 'tigon.' Finds out that such creatures also exist.

Ashok notes that one open question we haven't discussed is who can commit code into implementations. Chet notes that at the moment the sense is that this will be a benefit of membership. Open question as to wether an open project group should be allowed appoint non-OASIS people as committers (aka maintainers) based on merit.

Jacques notes that the larger question here is how can OASIS reinvent itself to address the changes in the market place. We should look beyond open source projects, e.g. to testing and certification.

Jacques also notes another possible opportunity: most open source projects today are horizontal IT projects. They generally don't pay attention to specific industry verticals. OASIS has industry vertical presence, e.g. legalxml, emergency management. Is this one differentiator that OASIS could capitalize on? Fostering activity and open src work in verticals.

Patrick suggests OASIS could be the 'bigger tent' that enables open source projects from across other orgs to integrate together.

Closed by agreeing that we will continue the discussion and invite Laurent to brainstorm at our next meeting if he's interested.

8) 2016/2017 work plan

Took a last look at Ashok's slide. Agreed to change first line to "Assist Laurent with work to support implementing the Open Project (formerly Liger) project" and distribute.

9) AOB

No other topics were raised.

Next meeting is scheduled for Friday, September 9th, at 2:00 EDT.

Minutes respectfully submitted by Chet Ensign on 26 August 2016.

Chat log

Chet: 1) Roll call

2) Approval of agenda

3) Approval of minutes August 12:
https://lists.oasis-open.org/archives/tab/201608/msg00020.html

4) Status of public reviews

No first public reviews open at this time

5) Status of open action items - AI: Patrick - merge proposed Conformance Clause edits with current working draft & send to Ashok

- AI: Jacques: rough draft of memo on TAB thinking for Liger projects

6) Review Patrick's draft of merged Conformance Clauses document

7) Discuss Jacques draft on Open Project (Liger) initiative and decide on final proposal

7) Approve 2016/2017 work plan

Chet: === chat log beginning ===
Chet: Whoops - I left the access code off the invitation. It is 263566#
Kevin Mangold (NIST): it is? i used 120-469 to login
Kevin Mangold (NIST): dialin*
Ashok: 120469 works
Chet: US Toll Free: +1 641 715-3822 and 263566
Chet: Maybe I am wrong.
Chet: Sorry let me dial back in
Kevin Mangold (NIST): that could b ethe leader code?
Chet: Attending: Kevin, Ashok, Jacques, Chet, Patrick
Chet: 2) Agenda
Chet: Ashok: like to hold off on conformance clauses. Pls carry over.
Chet: So remove item 6.
Chet: Agenda: no objs as modified. agenda as modified approved.
Chet: Minutes
Chet: No discussion. No objs. Minutes approved.
Chet: Status of public reviews.
Chet: None at this time.
Chet: Status of acttion items.
Chet: AI: Patrick - merge proposed Conformance Clause edits with current working draft & send to Ashok
Chet: Done. Closed.
Chet: - AI: Jacques: rough draft of memo on TAB thinking for Liger projects
Chet: Done. Closed.
Chet: Discuss Jacques draft on Open Project (Liger) initiative and decide on final proposal
Chet: Jacques - give us a recap on the draft doc
Chet: J: disclaimer - this is rough, not yet well organized at this point
Chet: J: hope it captured all that we discussed. Took the liberty to add more stuff and tried to add more structure.
Chet: J: not sure if this fits what Laurent wanted.
Chet: Ashok: what about open source projects that are never going to do a standard? Still want those right? Do don't want to exclude those.
Chet: Ashok: What about costs? Some of those other projects are quite expensive.
Chet: J: I see the point - membership fees in organizations can be high.
Chet: J: something to look at...
Chet: J: so at Oasis for 1 fee you can do both
Chet: Kevin: adding to OS proejcts that never go to standard - don't think the process should be any different. it should be the same whether they start out knowing what they want to do or not. Shouldn't require rechartering or starting a diff TC
Chet: K: biggest challenge will be the process governing.
Chet: K: let's keep cost out of our consideration for now - need to get the process right first
Chet: J: it may be attractive though to be able to do both
Chet: K: and that's why we should figure out the process...
Chet: J: tricky - because it does have to look like typical open source project - at same time the specification part needs to blend in smoothly
Chet: J: should look aggressively into reform of TC Process, especially the review part - public reviews and approvals.
Chet: J: In spirit of not positioning ourselves as competitors - perhaps brainstorm the types of open source projects we could see coming to Oasis - present it as a narrow scope
Chet: J: e.g. - those that are specifically to support standard (sample impls, test suites), proof of concept ahead of a standardization effort,
Chet: J: if we are to host, in first phase, narrow the product concept down
Chet: J: we would suffer if people make the comparison because we are seen as trying to compete
Chet: Patrick: Kevin has the right of it - need to define the process first. only way we'll get a handle on what this is going to be the cost and where we can recover those costs
Chet: P: deeply in favor of a seamless process where you can start doing either one - os or spec
Chet: P: the grp that does a spec or standard has ownership of the spec
Chet: P: e.g. maybe we had an open src prj to develop YAML and then someone comes along and starts a group to standardize it - doesn't necessairily need to be the same actors
Chet: P: radical suggestion - let's ask somebody who might want to bring a prj to OASIS - e.g. MS Powershell just started on github
Kevin Mangold (NIST): +1 to reaching out to people already in the OSS community
Chet: P: rather than try to image the project in the abstract
Chet: P: maybe work through it with them and redefine the process in partnership with them ahead of time as they develop their project
Chet: P: in other words, ask "is this going to fit with you doing your open src project
Chet: A: wouldn't it be enough just to compare oasis rules and apache rules and etc.?
Chet: A: in other words use the comparison with their rules to draft a first pass at a process
Chet: K: adding on to Patrick - would be good to engage in discussion w/ some open src experts - they'd be in a better position to informus
Chet: C: do we have contacts - K: we could just reach out to some contributors
Chet: K: requesting an interview
Chet: P: assuming we'd call on some of our own members
Chet: J: don't want to spoil the party - we might find people interested in standardization but the problem is that these people are very comfortable releasing products that are not backwards compatible.
Chet: J: they might want to bless an API as standard even though they might break it in the next release
Chet: J: there is a little bit of a mismatch between developers expectations and their manager's expectations
Chet: J: another snag to be aware of
Chet: P: but there are projects that maintain separate, incompatible versions and don't see it as a problem. ODF 2.0 will be incompatible with previous versions. So we need to be aware of the difference in culture - the dev's work continuously while the standards people want to stabillize it at some point
Chet: J: revise my statement - one of the problems with standards is that users are kept waiting - the open src is a moving target but users don't have to wait and can start biz activity based on the evolving code.
Chet: J: then once the group converges on a version that everyone feels comfortable is stable, then they can branch this off to standardize it - by then the users already have it working in code
Chet: J: it would be good to write down the different types of projects that might start as Ligers
Patrick: I do have one request, let's not use the term "liger"
Kevin Mangold (NIST): i prefer tigon
Chet: C: +1
Chet: C: recaps options - play role of customer / look at other orgs processes / look at our own process - what's anathema to open source culture?
Chet: J: should look at the W3C - they are being pushed hard by their developers
Chet: A: one thing we haven't got is who can commit implementations / update code
Chet: A: will have to add that to Oasis groups
Chet: J: on allowing non-members to be committers - W3C has introduced 'community groups' that are incubators where you don't have to be a member
Chet: J: other options + defining types of projects we would expect to see starting up at oasis - could be very different motives
Chet: J: underlined to all this there is the interest in oasis to reinvent itself - but other things to explore - i.e. bringing an existing spec to oasis but avoiding rubber stamping - other types of services as well that oasis could offer like testing activities - we should think beyond the open prj side
Chet: J: feel like open src today is largely horizontal IT prjs - not much intent to make forays into specific industry verticals - e.g. legalxml - is that a place where oasis could capitalize? fostering activity and open src/standards in those verticals
Patrick: OASIS could be the bigger tent that enables open source projects across other orgs to integrate together.
Chet: Chet: invite Laurent to next meeting to brainstorm
Chet: K: we wanted to put together the Discuss Jacques draft on Open Project (Liger) initiative and decide on final proposal
Chet: Strategic
Assist staff with Liger initiative by
Work with staff to prepare project plan for a first self-certification initiative
Tactical
Recommend additional links on OASIS home page to enable easier access to useful material
Prepare Editors best practices material
Prepare Chairs best practices material
Work on use of GitHub for OASIS TCs
Ongoing
Continue spec reviews
Disseminate citation lists for reuse
Chet: Change line to: "Assist Laurent with work to support implementing the Open Project (formerly Liger) project
Chet: Next meeting scheduled for Sept 9th
Chet: P: might be good to start gathering documents on process from other orgs for the TAB
Chet: Stay with 2:00 ET
Sent transcript to: chet.ensign@oasis-open.org

20160819 (last edited 2016-08-26 16:36:40 by chet.ensign)