Documentation and Testing Meeting 2010-07-14

Notes from Documentation and Testing Workgroup
Date: July 14, 2010
Time: 2pm-3pm
Attendees: Tom Silvious, Janet Campbell, John Moehrke, Nageshwara Bashyam, Parag More, Arien Malec, Uvinie Hettiaratchy, David Tao, Wil Ross, Claudio Sanchez
Actions from this Week

#	Date	Action	Status	Owner	Due Date
4	7/14/10	Work on preliminary prioritization on artifact list	Open	WG	7/21/10
5	7/14/10	Work on initial abstracts of documents	Open	WG	7/21/10

Actions from last Week

#	Date	Action	Status	Owner	Due Date
1	7/7/10	Add audience and training to charter	Open	Arien Malec	7/7/10
2	7/7/10	Reach out to security agent specification team for an update	Open	Arien Malec	7/7/10
3	7/7/10	Create preliminary list of artifacts	Open	Arien/Janet Campbell	7/7/10

Agenda

1. Validate document artifact list (any additions? subtractions? clarifications?)
2. Plan for August 17 deliverable(s) - see below
3. Preliminary prioritization of document list
4. Call for volunteers

Proposal for August 17: Let's prioritize our document list into the following ranks

• Rank 1: Quasi-final draft ready by Aug 17
• Rank 2: First draft/outline ready by Aug 17
• Rank 3: TBD, reprioritize after Aug 17

· We may decide, for example, that nothing is Rank 1, but such ranks should give us good common starting point for prioritization, similar to how the User Stories group worked.
Additionally, what should be our deliverables in terms of testing and testing toolkits?
Notes
Janet Campbell
· Our action item last meeting was to put together preliminary artifacts.
· Want to know what people think and see if there are any areas that are missing.
· Includes the S/MIME Security agent, API documentation, general links to code library, configure your email clients, SMTP client developers guide, the specification of XDD, and more.
· We’re talking about different parts of documentation. There are technical things aimed towards developers and then move towards end users and policy type documents.
Round on Initial feedback on list of preliminary artifacts

John Moehrke	· No comment
Nageshwara Bashyam	· List is a good start. Helpful to start a tree to see what’s in the artifacts. Maybe technical specifications, testing specs, developers guide, general reading guide. There were some emails on wiki on Reference Implementation. We might want to look at that list to make sure we’re mapping out components of Reference Implementation page.
Parag More	· List is comprehensive. Add certification guide. Create checklist relating to NHIN direct specification.
David Tao	· No comment

Janet Campbell
· Main thing is to classify documents into more general list – technical vs. overview. Also that Reference Implementation group is already creating their own so sync with them. Also, timing for HISP.
Arien Malec
· It might be reverse map of audience document.
Janet Campbell
· The next goal is the August 17th meeting and we should decide on our deliverable. I suggest to take our document artifact list and prioritize it based on Rank 1 documents as close to final draft.
· Rank 2 might be a working draft or general draft.
· Rank 3 we will prioritize after August 17th meeting.
· How do other people feel and do they feel these ranks cover everything? Do we want some other middle state – outline but not ready.
Round on: Does this sound like a good deliverable to rank document list and provide the document at level suggested? Second, do these ranks make sense? Other ranks?

Tom Silvious	· Perhaps we can have an abstract ready especially for those who are marked as not started. · We want to make sure we have coverage.
Nageshwara Bashyam	· Ok with classification. Makes sense to prioritize.
Parag More	· Agree with classification. Good solid start. I will definitely add documents that we will not be starting, and provide an abstract.
David Tao	· No comment
Wil Ross	· I have a higher level question about extent to which we are going to use wiki for documentation versus other artifacts? No comment on the artifact list and prioritizing.
Claudio Sanchez	· No comment.
Arien Malec	· Agree with comments.

Janet Campbell
· Generally, my vote is that it’s good for what it does, but we shouldn’t feel we have to use the wiki. Some of documentation may be better served by PDF publication. The documentation should be available off the wiki though.
· Agree about abstract addition. Rank 1 close to final by August 17th, Rank 2 well thought out by August 17th, and Rank 3 after August 17th with abstract.
· Any test deliverables want prepared by August 17th ?
Arien Malec
· Certification guide as key artifact is good idea.
Round the Room

Tom Silvious	· To keep it from being confused, I might even put under heading of specification.
Nageshwara Bashyam	· Testing might fall into third bucket. Might write abstracts. Just because of timing and reference implementation is kicking off.
Parag More	· No comment
David Tao	· Testing guide would be in scope. I would agree August 17th seems premature. It does seem we need the specs in order to have the requirements for testing it. I agree it should be an artifact later. There are also all these possible components they may write, and not in the box solution, how do you test that? I think if we do reference implementation where all the parts are produced by this project, then that’s best way. As soon as customize and mix, it’s going to be difficult to write all test guides. Each component has unit test.
Wil Ross	· I was going to take opposite approach and say that unit testing guides developed by Security and Trust, etc. are our natural artifacts and are our starting points. · We want to be harvesting and organizing them as a starting point. · It’s both because it’s a phasing issue. We can’t actually write testing guides without things to test. During development of components though, there’s going to be unit testing of raw components we can use. · I see as ongoing process and finish in end.
Claudio Sanchez	· No comment.
Arien Malec	· My experience in testing is that it’s better to do testing implementation along with specification components. I would vote for conformance guide along with specification. I think we should make that conformance guide as close to possible to end to end. One for client side and one for HISP.

Janet Campbell
· I think what Parag was getting at is that these are the MAY functionalities and these are the MUST. As Arien pointed out, these are for the client, these are for the HISP.
· I think we can do high level analysis for August 17th, and come up with something close.
· For more specific details to actually perform functions will depend on other workgroups.
· Are there other representatives from Security and Trust and Reference Implementation group.
John Moehrke
· I think Janet, you summarized the key points.
· The requirement for security and trust and implementation will have our requirements for implementation. That doesn’t mean that there’s a test plan. There are things that could be tested on individual level.
· I think we could have a high level view of how to test components.
Janet Campbell
· I think that makes sense, and we should capture what’s high level in our artifact list.
· I think one of things is someone who can keep an eye on this from Reference Implementation group and Security and Trust group.
· It sounds like John’s on Reference Implementation group.
· Arien can be designated as liaison.
· I think that our next step is start to work on preliminary prioritization on artifact list after it’s updated.
· It sounded like a high level checklist is one of our first priorities.
· Right now, the Security Agent specification and API documentation are also first priorities.
· Are there other things that should be first priority? We can decide this now, or offline?
Round on: Prioritizing now or defer later?

Tom Silvious	· Good list.
Nageshwara Bashyam	· Ok with priorities.
Parag More	· The NHIN Direct high level overview and security NHIN Direct high level overview for which the primary audiences are decision makers for organizations. In my opinion those documents should be primary because these will help with decision makers. · What is coming down the pike and what should be ready for? · My opinion would be to first going after high level whats and then the hows.
David Tao	· Yes, agree with what was just said. Although person writing overview is not necessarily person writing the API document. · To have adoption of NHIN Direct, people need to know about it and be interested in it. · I would not put policy questions up there (as priority 1), perhaps email client could be later. · I agree among the technical documents, the ones that have a 1 are good. · I think the overview could get started soon.
Wil Ross	· I agree with getting initial versions of the laymen/policy maker’s guides for high level. · What’s the difference between SMTP, S/MIME, CERT implementation guide and conformance guide? · Arien Malec - Implementation guide says how to put pieces together and are deploying services. The conformance guide says this is what you need to do to validate your development framework so that it’s in conformance with specification. · So component of implementation guide? · Arien Malec – Yes. You can do conformance guide in parallel.
Claudio Sanchez	· No comment.
Arien Malec	· My experience in testing is that it’s better to do testing implementation along with specification components. I would vote for conformance guide along with specification. I think we should make that conformance guide as close to possible to end to end. One for client side and one for HISP. · Heard that general overview is a high priority so request that’s priority 1.

Janet Campbell
· That sounds good when looking at where the need is right now.
· Moving some of the more generic stuff first makes sense to me as well.

Call for volunteers for people who are interested in certain artifacts – write the abstract and start planning out what it should contain. Are there certain areas people are interested in and could write abstract for next meeting?

Tom Silvious	· Nothing to add
Nageshwara Bashyam	· I’ll write abstract for top level guide – NHIN Direct overview and top level stuff.
Parag More	· Take a stab for abstract for conformance/certification guide for NHIN.
David Tao	· I was going to volunteer for overview, so I could help Dragon. The XDD spec is something we have interest in. Might not be personally – I tentatively volunteer for that with others on team. Assist with Dragon on overview.
Wil Ross	· Put me down for two things: there are two overview documents – NHIN Direct and Security. Will help Dragon for Security and draft abstract for S/MIME security agent spec.
Claudio Sanchez	· Nothing to add.
Arien Malec	· I also know that Rich Elmore volunteered for overview. Sounds like we have a good team for overview. I’ll volunteer for API documentation.

Janet Campbell
· I can volunteer for deferred policy condition abstract.
· Let’s meet back next time to go over abstract. If not watching wiki page, suggest you add yourself. As you write abstract, you can hyperlink them off of the document artifact list so we can organize everything together.