RE: structured review process ?

 
>I was just wondering if there was any structured review process for
>reviewing LSB specifications.
>I've found some information here -
>http://www.linuxbase.org/LSBWiki/ReviewPlan3 
>which seems to adopt a general approach.
>Is there some kind of step-by-step procedure that can be followed for a
>review ?

Not sure quite what the question is here.

As you've seen, the general process is: review spec;
file bugs; be prepared to provide more information or
argue for the change you'd like to see; wait for the
next spec build that contains a fix and check that
it was implemented (correctly).

Having to create a bugzilla account and learn how to
file bugs is a bit of a burden, admittedly, but it's
important for us to use a mechanism that assures 
there is contact information together with the problem
report, because often more information is needed
from the submitter.

The "review spec" part can be as organized or as
informal as the reviewers like, I'm not clear how
we could organize it more formally.

As a release evolves, the team tries to point to
the areas under change, which should give an
indication of the areas to concentrate on most
heavily when reviewing.