Documentation and Testing Presentation 2010-08-18
Jump to navigation
Jump to search
NHIN Direct Face to Face Meeting
Documentation Workgroup Presentation
August 18, 2010
Notes
Janet Campbell
· Document-a-thon was not as productive as WG had wanted.
· Settled on a model that worked well: focused on NHIN Direct Overview as most important artifact.
· WG thinks of the Overview as the skeleton to understanding the whole project.
· WG is cutting down on length of documents.
· Focusing on one document at a time.
· Plan on getting only the people most invested in particular documents to work together and come to an agreement on the final document then put up for consensus within the overall WG.
· Necessity to connect with other workgroups.
o àFor example: need to work with Reference Implementation WG on SMPT Guide.
· Shepherding the lessons learned process
o àHad a request to put together a FAQ document for potential participants in pilot implementations.
· Communications WG v. Documentation Workgroup: Documentation WG will be focused on creating materials, content, actual documentation, while Communications WG is more focused on how to package and deliver it best to people who need to understand it.
· What comes first, documentation or implementation? It is a little back and forth
· Calls for working closely with other groups.
Q&A
Comment from Audience
· Documentation WG doesn’t want to document down to a certain technical level, but should focus on things that will jumpstart extended teams, with more folks participating.
Sean Nolan
· As we are in this process of having basic technical interfacing, where do you want to break as far as the responsibility for developers v. documenters?
Janet Campbell
· The low-level technical documentation makes sense coming from the actual developers. Documenters’ role in that is to look at and point out what is not as understandable or less obvious.
Sean Nolan
· For review and oversight?
Janet Campbell
· Yes.
Arien Malec
· Just because the Documentation WG is taking on a document doesn’t mean the WG is writing it. A document may be written and edited by Umesh but overseen by Documentation WG.
John Moehrke
· Another way to look at it: Conformance, the tightest spec, is neither descriptive nor speaking to any particular reference model.
· The reference model should be more from the developers while the descriptive stuff should go through Implementation Geographies.
Arien Malec
· Question to the team, especially Implementation Geographies:
o Have you read the material that has come out of Documentation WG?
o Is there anything you need when bringing info to providers or other stakeholders that you don’t have yet from the Documentation WG?
Gary Christensen
· Has not really read, so needs to see what is there.
Janet Campbell
· àOverview document will be ready to be sent out after one more pass.
Gary Christensen
· It is not clear on the wiki which documents are still in process and which are final or close to final and are ready for outside review.
Janet Campbell
· àWill clarify.
Documentation Workgroup Presentation
August 18, 2010
Notes
Janet Campbell
· Document-a-thon was not as productive as WG had wanted.
· Settled on a model that worked well: focused on NHIN Direct Overview as most important artifact.
· WG thinks of the Overview as the skeleton to understanding the whole project.
· WG is cutting down on length of documents.
· Focusing on one document at a time.
· Plan on getting only the people most invested in particular documents to work together and come to an agreement on the final document then put up for consensus within the overall WG.
· Necessity to connect with other workgroups.
o àFor example: need to work with Reference Implementation WG on SMPT Guide.
· Shepherding the lessons learned process
o àHad a request to put together a FAQ document for potential participants in pilot implementations.
· Communications WG v. Documentation Workgroup: Documentation WG will be focused on creating materials, content, actual documentation, while Communications WG is more focused on how to package and deliver it best to people who need to understand it.
· What comes first, documentation or implementation? It is a little back and forth
· Calls for working closely with other groups.
Q&A
Comment from Audience
· Documentation WG doesn’t want to document down to a certain technical level, but should focus on things that will jumpstart extended teams, with more folks participating.
Sean Nolan
· As we are in this process of having basic technical interfacing, where do you want to break as far as the responsibility for developers v. documenters?
Janet Campbell
· The low-level technical documentation makes sense coming from the actual developers. Documenters’ role in that is to look at and point out what is not as understandable or less obvious.
Sean Nolan
· For review and oversight?
Janet Campbell
· Yes.
Arien Malec
· Just because the Documentation WG is taking on a document doesn’t mean the WG is writing it. A document may be written and edited by Umesh but overseen by Documentation WG.
John Moehrke
· Another way to look at it: Conformance, the tightest spec, is neither descriptive nor speaking to any particular reference model.
· The reference model should be more from the developers while the descriptive stuff should go through Implementation Geographies.
Arien Malec
· Question to the team, especially Implementation Geographies:
o Have you read the material that has come out of Documentation WG?
o Is there anything you need when bringing info to providers or other stakeholders that you don’t have yet from the Documentation WG?
Gary Christensen
· Has not really read, so needs to see what is there.
Janet Campbell
· àOverview document will be ready to be sent out after one more pass.
Gary Christensen
· It is not clear on the wiki which documents are still in process and which are final or close to final and are ready for outside review.
Janet Campbell
· àWill clarify.