[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting Minutes: 2003.04.06
[Item #1: CAP] Allen mentions discussion with Jamie regarding that there should not be any normative changes to the doc. This basically means no changes at all except the name and date, NOT referring to internal normative (data dictionary, schema, etc.) vs. non-normative (design principles, concepts, etc.) info. Rob states that he doesn't want to pull it back at this point - that it could damage the group. Rex agrees. No other comment. Rob proposes a future "point release" - basically a CAP 1.NEXT (1.1, 2.0, etc.). Art comments that it is probably a 4 - 6 month process to really address the issues and bring CAP.NEXT to market. Allen comments that there is more than one way to help reduce the severity of the concerns that have been raised. This can come in the form of a non-normative errata, Implementer's Guide, etc. or any combination thereof. Art brings up that people should present solutions with their issues. Allen comments that not all people who experience issues know enough to also define a solution, but that doesn't mean it is not a valid issue. No one is saying we can address a phantom issue (ie: an issue no Member will "own"). If the submitter does not understand it enough nor does anyone else, then it becomes something the TC can not address. Rick as some comments also stating that not everyone knows the "answer", but someone in the group may. Rex also states this should be "ok" for comments w/o solutions (MINUTE TAKER NOTE: the group did not appear to be on the same page at this point, but the next statement helps...). Carl brings up the fact that people will find errors, problems, etc., and the way to handle is through errata. Art clarifies that he is speaking more of philosophical differences and having a process for triaging or even addressing them. Jamie joins the call at this point, and Carl asks for his guidance on this topic... Jamie discusses (refer back to what Allen said at intro of meeting) how the spec/doc is frozen, at least that version, once it is voted on. Examples to help illustrate: 1. What if a semi-colon is in the wrong place? OASIS allows an errata document, but the standard can not change at all. Basically the TC can adopt this errata document. 2. What above major changes? It is up to the committee as to how, by vote, to handle each of these items and issues and where/when they appear (ie: 1.1, 2.0, across multiple versions, etc.). Carl just reflects that basically the TC becomes a "revision working group" as it pertains to how to address CAP 1.0. Jamie goes on to point out that the next step is to determine if we should do an errata list/doc. Allen asks Art if his questions regarding philosophical differences was answered, and if not to restart. Art provides the info again to Jamie now the he is on the call. Jamie mentions that a member proposes a change. If there is a bunch then there should probably be an agreed list that the TC debates/discusses and makes a voting decision on. Allen mentions that we have a list started (CAP 1.0 Standard Issues List.xls), but that it needs to be updated as of the last 2 weeks discussions. Rob reflects that he is hearing 2 different paths. One is errata, and the second is about enhancing for the next version. Points out that it is brand new, and as such, there will be a surge in additional comments, etc. Likes the idea of an errata sheet to address immediate needs/comments. Seeks agreement that there are flaws that should be put in an errata document. Jamie comments that you should be careful to try and not include everything in an errata - plan some of the bigger issues for 2.0. Basically, for the errata, look for the things that are easy to include and agree on, but avoid things that are larger topics that will take more time to address. Suggestion: if there is a major functionality issues you can acknowledge, but state it is to be addressed in a future version. Jamie suggests that we identify owners (Members) to review the issues in the CAP List 1.0 Spreadsheet. Allen will update spreadsheet with newer issues and email to group regarding the review of this list. [Item#2: CAP Evangelization] Rex has already has 3 articles/resources to draw from and some opportunities. See his post (http://lists.oasis-open.org/archives/emergency/200403/msg00102.html) for a more complete summary. MINUTE TAKER NOTE: Rex, if I missed anything here please send out to group, as I am not sure I captured everything that was important.. At the end of the meeting (after Item #4 discussion) Rex asks if we are in agreement with what he wrote for the newsletter. Art brings up that the press release is 4/14, so there may be synergy to sync it up. Jamie recommends to touch base with Carol. Everyone agrees, so Rex will work with her on lining these two publications. Allen will provide "Chair" quote to Rex for inclusion. [Item #3: CAP Future] We talked all around this in Item #1, so it was not discussed any further in the meeting. [Item #4: IF SC Update] Rick grabbed the documents off the list and they are in Tom's hands now. Tom had to drop off, but they will get together today or tomorrow and forward out to group. [Summary] 1. Update CAP Comments spreadsheet and send out to group from review. Determine what items should be in errata. 2. Implementer's Guide outline has been drafted (http://lists.oasis-open.org/archives/emergency/200404/msg00038.html), and as such, we need to take the items from our Public Comment review assigned to the Imp Guide and ensure they are covered. 3. Allen to provide quote for Rex's article. He will continue to work the media angle. 4. Tom/Rick to circulate IF SC work. -- R. Allen Wyke Chair, OASIS Emergency Management TC emergency-tc@earthlink.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]