On Tue, 2011-01-04 at 17:57 +0000, Adam Williamson wrote: > On Mon, 2011-01-03 at 10:52 -0500, James Laska wrote: > > > Agreed ... I think it makes sense to keep Category:Test_Cases as just a > > container for sub-categories if possible. Mainly for the reasons you > > note around *trying* to keep content organized. > > OK. I think I actually went ahead and changed this in the current > version, I'll go back and double check. > > > My > > question (I guess I already re-stated above) was whether you consider > > the terms "core" and "extended" as a designation of test case priority? > > Yes. The terms themselves aren't hugely important, sure, it's more > expressing the concept of priorities, but I kind of conceived it in > terms of the importance of the functionality being tested.
Gotcha, thanks.
> > Outside of the terminology, I have some concerns whether this is within
> > the scope of the initial project, or something we want to leave as a
> > phase#2 effort. We definitely need to think about it as non-critpath
> > tests will come in, I just hope we don't spend all our collective energy
> > on defining non-critpath tests and then we are still exposed to a lack
> > of test documentation for the critpath.
>
> My thinking here is that one of the typical workflows for creating test
> cases will be 'let's create a set of test cases for package X'. Say the
> maintainer of package X decides to contribute some test cases. I suspect
> it's quite unlikely they'll restrict themselves strictly to critical
> path functionality in all cases; so we should already have the
> groundwork for non-critical-path test cases laid out.
I see. Yeah, we certainly need to be prepared for tests created outside
the initial scope.
> > > possibly. I was meaning those bits to be read simply as a potential
> > > illustration of programmatic use of the categories to illustrate why
> > > consistent categorization is important, but if you think it's confusing,
> > > we could take it out.
> >
> > No strong opinions here. I thought I learned somewhere that one should
> > avoid future leading statements when documenting process. I could have
> > sworn that was in the Fedora doc guide ... but I could be making it up.
>
> I'd agree with that - again the idea was to illustrate a design concept
> ('this is designed this way in order to enable this kind of programmatic
> usage') rather than to prescribe a particular form of programmatic usage
> on the part of particular tools. I tried to re-write it to be less
> specific in a later draft that's up now, is it better?
That looks good. Your pages are looking really good IMO, thanks for the
time+energy you've invested.
Thanks,
James
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
