Difference between revisions of "Concall-20071126"

From HL7 TSC
Jump to navigation Jump to search
Line 36: Line 36:
 
## Technical & Support Services
 
## Technical & Support Services
 
#''(20 min)'' '''ARB -- scope and relationship with TSC''' - [http://lists.hl7.org/read/attachment/118218/1/HL7%20reformed%20ARB%20current%20thinking%2011-18-07%20-%20.ppt]- Charlie Mead asked for input as to the TSC's expectation of the ARB and its role/responsibilities.  The TSC's expectation is that the ARB will be focused on the architecture. Beeler noted that the T3F, when they discussed the issue, felt an architecture should cover all of the interchange structures that HL7 supports, not just messaging.  Key is defining an architecture that is encompassing of our standards, is precise enough to specify how the standards interact, but not so overly binding that things come to a standstill when trying to define it. Regarding the authority of ARB, Beeler feels this group should work through the TSC but should have authority to raise the topics.  He suggests that we use a pattern similar to harmonization (i.e., the ARB decision is accepted unless someone raises an objection). They will need to be in a position to review and make decisions relative to a work products’ conformance with the architecture.  Decisions of ARB should be well reasoned and supported by an architecture.  The quicker that the ARB can get an architecture in place, the better they will be at providing the well reasoned answers.  ARB should identify the areas of the architecture that need to be worked on first (prioritization).  There was an expressed desire to carve out areas of responsibility for TSC and ARB to bring clarity rather than competition to their roles. Beeler feels that since the ARB is appointed by the TSC, the relationship is clear.  Singureanu suggested adding a sentence to the ARB mission statement to clarify the relationship.  The ARB is the group that makes decisions related to architecture; the TSC would be consulted for appeals.  Charlie Mead asked if the TSC feelt that ARB is a formal/specialized subcommittee of the ARB – it doesn’t exist outside of the ARB.  Case disagreed with this assessment as all ARB members are not members of the TSC. ARB would take on the issue of what is backwards compatible.  Change control vs architecture issues need to be sorted through.  There also need to be guidelines for appeal to the TSC.  The other piece of information that we have to assit with the architecture is the V3 SOP.  What do we mean by reference models, conformance.  Beeler suggested that group revisit this document.  The first order of business for the ARB will be to define the HL7 Architecture.  Quinn/Mead will provide a proposed ARB slate for the 12/3 meetings.  The TSC will bring forward suggested individuals to serve from their steering divisions and then ratify the slate. McCay also reminded the group of the need to clarify the communications from the TSC outward regarding the ARB, its role/responsibility and the desired skill set of those chosen to serve on the ARB.  Ken McCaslin has some suggested edits to the mission/charter that should be included before we communicate out to the organization.
 
#''(20 min)'' '''ARB -- scope and relationship with TSC''' - [http://lists.hl7.org/read/attachment/118218/1/HL7%20reformed%20ARB%20current%20thinking%2011-18-07%20-%20.ppt]- Charlie Mead asked for input as to the TSC's expectation of the ARB and its role/responsibilities.  The TSC's expectation is that the ARB will be focused on the architecture. Beeler noted that the T3F, when they discussed the issue, felt an architecture should cover all of the interchange structures that HL7 supports, not just messaging.  Key is defining an architecture that is encompassing of our standards, is precise enough to specify how the standards interact, but not so overly binding that things come to a standstill when trying to define it. Regarding the authority of ARB, Beeler feels this group should work through the TSC but should have authority to raise the topics.  He suggests that we use a pattern similar to harmonization (i.e., the ARB decision is accepted unless someone raises an objection). They will need to be in a position to review and make decisions relative to a work products’ conformance with the architecture.  Decisions of ARB should be well reasoned and supported by an architecture.  The quicker that the ARB can get an architecture in place, the better they will be at providing the well reasoned answers.  ARB should identify the areas of the architecture that need to be worked on first (prioritization).  There was an expressed desire to carve out areas of responsibility for TSC and ARB to bring clarity rather than competition to their roles. Beeler feels that since the ARB is appointed by the TSC, the relationship is clear.  Singureanu suggested adding a sentence to the ARB mission statement to clarify the relationship.  The ARB is the group that makes decisions related to architecture; the TSC would be consulted for appeals.  Charlie Mead asked if the TSC feelt that ARB is a formal/specialized subcommittee of the ARB – it doesn’t exist outside of the ARB.  Case disagreed with this assessment as all ARB members are not members of the TSC. ARB would take on the issue of what is backwards compatible.  Change control vs architecture issues need to be sorted through.  There also need to be guidelines for appeal to the TSC.  The other piece of information that we have to assit with the architecture is the V3 SOP.  What do we mean by reference models, conformance.  Beeler suggested that group revisit this document.  The first order of business for the ARB will be to define the HL7 Architecture.  Quinn/Mead will provide a proposed ARB slate for the 12/3 meetings.  The TSC will bring forward suggested individuals to serve from their steering divisions and then ratify the slate. McCay also reminded the group of the need to clarify the communications from the TSC outward regarding the ARB, its role/responsibility and the desired skill set of those chosen to serve on the ARB.  Ken McCaslin has some suggested edits to the mission/charter that should be included before we communicate out to the organization.
 
+
#''(20 min)'' '''Project Management - what does the TSC need?''' - McCay referred to his earlier e-mail to the TSC list in which he set the context for this discussion.  That e-mail quotes the following from the TSC mission/charter:  "It is responsible for overseeing the execution of standards development wihin HL7 by assuring that the efforts of the Working Group (WG) are in line with the product and services strategy set forth by the Board."  McCay noted that the organization does not yet have a products/services strategy and the TSC does not have much insight as to the work groups' projects.  The TSC issues tracking is going well but there is a need to to understand how the projects are proceeding.  McCaslin noted that the intent of project lifecycle committee was that a project, as it was developing, would not scope its completion date until it had gone through a well defined discovery phase.  It may be two or three ballot cycles out before a committee begins balloting a new project.  Project Insight may help us predict what will happen in various ballot cycles.  McCay’s concern is seeing a list of the current active projects.  McCaslin noted that the problem has been pushback from the committees. This will likely not be a short-term transition. Van Hentenryck reported that staff recongized the need to get the projects into Project Insight so that they can be viewed and tracked.
#''(20 min)'' '''Project Management - what does the TSC need?''' - We don’t have a products/services strategy at the moment and don’t have a lot of insight as to the projects being worked on in the work groups.  The issues tracking is going well but there is a need to to understand how the projects are proceeding.  McCaslin noted that the intent of project lifecycle committee was that a project, as it was developing, would not scope its completion date until it had gone through a well defined discovery phase.  It may be two or three ballot cycles out before a committee begins balloting a new project.  Project Insight may help us predict what will happen in various ballot cycles.  McCay’s concern is seeing a list of the current active projects.  McCaslin noted that the problem has been pushback from the committees. This will likely not be a short-term transition.
 
 
#''(5 min)'' '''issue review and processing'''   
 
#''(5 min)'' '''issue review and processing'''   
 
## Status of gForge Implementation -  
 
## Status of gForge Implementation -  

Revision as of 13:23, 28 November 2007

TSC - Technical Steering Committee

Monday, November 26th, 2007 11:00 AM (US Eastern Time, GMT -5)
To participate, dial 702-894-2444 and enter pass code 1244667#
GoToMeeting at https://www.gotomeeting.com/join/822618174
GoToMeeting ID: 822-618-174 

back to TSC Minutes and Agendas

Attendance

Expected

  • Chair: Charlie McCay
  • CTO:
  • Domain Experts: Jim Case (primary), Austin Kreisler (alternate)
  • Foundation & Technology: Ioana Singureanu (primary), Woody Beeler (alternate)
  • Structure & Semantic Design: Calvin Beebe (primary), Gregg Seppala (alternate)
  • Technical & Support Services: Ken McCaslin (primary), Helen Stevens Love (alternate)
  • Affiliate: Frank Oemig, Charlie McCay
  • ARB Chair: Charlie Mead
  • HQ: Karen Van Hentenryck

invited

  • Charles Jaffe (CE); Chuck Meyer (HL7 Chair); Ed Hammond (HL7 Chair Elect)

Apologies

  • CTO: John Quinn

Agenda

  1. (10 min) Meeting Admin
    1. Roll Call - The following individuals participated in the call: McCay, McCaslin, Kreisler, Mead, Singureaunu, Beeler, Seppala, Case, Van Hentenryck (joined late), Quinn (joined late)
    2. Accept Agenda
    3. Approve Minutes Concall-20071119 -The minutes from last week's call were approved with one abstention.
  2. (10 min) Standing Committee Reports
    1. CEO Report
    2. CTO Report
    3. ARB report
    4. Affiliates Report
    5. Domain Experts
    6. Foundation & Technology
    7. Structure & Semanic Design
    8. Technical & Support Services
  3. (20 min) ARB -- scope and relationship with TSC - [1]- Charlie Mead asked for input as to the TSC's expectation of the ARB and its role/responsibilities. The TSC's expectation is that the ARB will be focused on the architecture. Beeler noted that the T3F, when they discussed the issue, felt an architecture should cover all of the interchange structures that HL7 supports, not just messaging. Key is defining an architecture that is encompassing of our standards, is precise enough to specify how the standards interact, but not so overly binding that things come to a standstill when trying to define it. Regarding the authority of ARB, Beeler feels this group should work through the TSC but should have authority to raise the topics. He suggests that we use a pattern similar to harmonization (i.e., the ARB decision is accepted unless someone raises an objection). They will need to be in a position to review and make decisions relative to a work products’ conformance with the architecture. Decisions of ARB should be well reasoned and supported by an architecture. The quicker that the ARB can get an architecture in place, the better they will be at providing the well reasoned answers. ARB should identify the areas of the architecture that need to be worked on first (prioritization). There was an expressed desire to carve out areas of responsibility for TSC and ARB to bring clarity rather than competition to their roles. Beeler feels that since the ARB is appointed by the TSC, the relationship is clear. Singureanu suggested adding a sentence to the ARB mission statement to clarify the relationship. The ARB is the group that makes decisions related to architecture; the TSC would be consulted for appeals. Charlie Mead asked if the TSC feelt that ARB is a formal/specialized subcommittee of the ARB – it doesn’t exist outside of the ARB. Case disagreed with this assessment as all ARB members are not members of the TSC. ARB would take on the issue of what is backwards compatible. Change control vs architecture issues need to be sorted through. There also need to be guidelines for appeal to the TSC. The other piece of information that we have to assit with the architecture is the V3 SOP. What do we mean by reference models, conformance. Beeler suggested that group revisit this document. The first order of business for the ARB will be to define the HL7 Architecture. Quinn/Mead will provide a proposed ARB slate for the 12/3 meetings. The TSC will bring forward suggested individuals to serve from their steering divisions and then ratify the slate. McCay also reminded the group of the need to clarify the communications from the TSC outward regarding the ARB, its role/responsibility and the desired skill set of those chosen to serve on the ARB. Ken McCaslin has some suggested edits to the mission/charter that should be included before we communicate out to the organization.
  4. (20 min) Project Management - what does the TSC need? - McCay referred to his earlier e-mail to the TSC list in which he set the context for this discussion. That e-mail quotes the following from the TSC mission/charter: "It is responsible for overseeing the execution of standards development wihin HL7 by assuring that the efforts of the Working Group (WG) are in line with the product and services strategy set forth by the Board." McCay noted that the organization does not yet have a products/services strategy and the TSC does not have much insight as to the work groups' projects. The TSC issues tracking is going well but there is a need to to understand how the projects are proceeding. McCaslin noted that the intent of project lifecycle committee was that a project, as it was developing, would not scope its completion date until it had gone through a well defined discovery phase. It may be two or three ballot cycles out before a committee begins balloting a new project. Project Insight may help us predict what will happen in various ballot cycles. McCay’s concern is seeing a list of the current active projects. McCaslin noted that the problem has been pushback from the committees. This will likely not be a short-term transition. Van Hentenryck reported that staff recongized the need to get the projects into Project Insight so that they can be viewed and tracked.
  5. (5 min) issue review and processing
    1. Status of gForge Implementation -
    2. tsc issue review process

Agenda item list (our sand box for future meetings)

Click for TSC Action Item List