See also: IRC log
Kai: let's begin... Alan, can you restate the point you made on the list?
Alan: Firstly that we should be
clear whether we're going to be limited by BP or if we're going
to go beyond the BP
... We can say that mOK goes beyond BP but they'll need to be
made aware of that
... I think some Basic tests already go beyond BP
... I think it's going to be a mistake to use the BP names for
the names of the tests is the latter goes beyond the former.
May we could just use numbers
... and then say that this test relates to or is inspired by
[BP]
Kai: I think you're right
... we should flag where we go beyond the BP
... we're trying to be educational. Maybe we can say here's the
BP but look you can be even better
... let's not confuse the issue, we're chartered to be based on
the Basic test
Alan: I understood that we're creating the basis for a label. If we're going to go beyond BP then maybe we end up with an appendix to BP
kai: We'll need to reference/flag
Further discussion on this point
<Zakim> jo, you wanted to say what I just said in an email to the list
Jo: I don't see that there's a
need to be very strict about this. If there's something that
simply isn't mentioned in BP and the test was way off the mark,
then we'd have to say that Pro had gone too far
... but there are lots of cases where you can interpret the BPs
and retain the spirit of the BP by giving more specific
conditions
... I don't think you should see the BPs as a prescriptive list
of things to be testable
<Kai> PROPOSED RESOLUTION: If anything within the tests goes beyond what is listed in the Best Practices, it should be clearly flagged within the test as a recommendation for further considertation. Furthermore we may later produce a separate document stemming from these changes.
Jo: I see BPs as more of a fireside chat. "say use caching".. and then be ready in the tests to explain what that actually means with limits
Kai: When we notice something that is not quite right, then I think we should flag it. We may decide to remove those flags in the doc but we should flag it for discussion within the full WG
Jo: That seems very
sensible
... For Basic it's water under the bridge
Kai: Bryan may want to take some
of our commnets up in BP2
... I'd like to move on...
... I am creating an editor's draft version of the doc we've
been working on on Google docs (http://docs.google.com/Doc?docid=dft77cn8_15dxsxg5hf&hl=en)
PROPOSED RESOLUTION: That editing of the doc is now in Kai's hands and the shared document on Google Docs is no longer the active document
RESOLUTION: That editing of the doc is now in Kai's hands and the shared document on Google Docs is no longer active
kai: The other thing is the charter. I sent a new version to the group. Francois has created the group home page and included the amended charter. That might be a problem as it hasn't been approved by the group
PhilA; Is there stuff we should be doing between now and this time next week?
Kai: I don't think so, things have been done
PhilA: Presenting the doc to the group is likely to generate action items for us
kai: Forgot that we want to ask for FPWD when we submit this doc
<Kai> 04 01PROPOSED RESOLUTION: If anything within the tests goes beyond what is listed in the Best Practices, it should be clearly flagged within the test as a recommendation for further considertation. Furthermore we may later produce a separate document stemming from these changes.
+1
<Kai> RESOLUTION: If anything within the tests goes beyond what is listed in the Best Practices, it should be clearly flagged within the test as a recommendation for further considertation. Furthermore we may later produce a separate document stemming from these changes.
Kai: So getting the doc edited
and FPWD is the next step
... Can we share the editing?
PhilA: We can pass control between people
Kai: Yeah that's a pain
... Let me see how I get on
... AOB?
<Kai> Francois, how do I close this properly?