Re: QAH outline

Le 20 avr. 2004, à 11:33, Lofton Henderson a écrit :
>> +chronology diagrams.
>>         * use it but by making it a bit different. To think.
>
> I'll try to do it, but if you want to try it instead ... feel free!  
> (If so, please let me know, so that I don't duplicate your efforts.)

Don't work on it

>> How long does it take to
>>         Think about a new feature?
>>         Write the prose for it?
>>         Write the schema/DTD for it?
>>         Write the test case for it?
>>         Get the review of WAI, I18N, QA, DI etc for it?
>>         Get Implemented? (CR)
>
> This is good stuff!  I'm not sure exactly how you envision it to be 
> integrated into the EP&C module.  I'll try.  But if you have a 
> definite thought, where/how the bits ought to be integrated, I'll 
> implement that -- please let me know (soon).

not really. I'm trying to make clear the consequences of things for a 
chair and its working group, consequences for each new things. I wonder 
if a box diagram could be one answer. Do you see any kind of steps. We 
could try to draw an flow chart for this kind of things.

	Thinking.

>>         ( [ouside W3C] + Specs translated, features used in the 
>> world, etc.)
>
> I'm not sure I understand that little add-on.  Clarification?

Out of scope of QAH:

Once the spec has been translated in takes times:
	- to translate the specification for larger avaibility (volunteers 
effort)
	- to have implemented features used by end users
	-
Was thinking that there might be a long process before the complete 
adoption of a technology

>> """Tips for Getting to Recommendation Faster (section 3) also 
>> addresses (early) staffing decisions.
>> Examples: [Collect them here? or scatter them in the above practices; 
>> or some of both?]"""
>>
>> -> The whole QAH is to get Recommendation faster ;)
>
> Indeed.  Do you suggest to change something specific in the draft?

It's more about this particular title.
	Addressing early staffing decisions helps getting rec faster
	I think the tips could be distributed, you know like these books which 
have a light bulbs to explain a simple and neat thing.

>> """Good Practice: Identify Web page(s) for test suites, 
>> announcements, and other QA deliverables. [was CP4.4]"""
>>
>> -> http://www.w3.org/QA/WG/ for us?
>
> I guess so.  Or is it ../QA/WG/QA?  ;)
>
> Actually, to other folks I would recommend something like 
> ../<wg-name>/Test, for uniformity.  E.g., ../SVG/Test/ (exists), 
> ../CSS/Test/ (exists), ../Forms/Test/ (exists), etc.

	Try that ;)
	http://www.w3.org/QA/Test/
	Maybe I should reform this page, archive it somewhere and change it to 
the real Test materials

> Except ... in our case, I don't know if we are going to have test 
> materials for the "good faith" Lite QAF.

Maybe to be thought right away. SpecLite a principle/GL/thingie -> How 
do I create a test for it. Or what's a test for this particular thing.

> Are you suggesting that we now need to "eat own dogfood"?  (I.e., 
> finish our QAPD and post it concurrent with FPWD?)

I suggest we do to avoid any reproaches