[Bioc-devel] Updated check results page

[Vincent Carey 525-2265]

> > so perhaps there could be some descriptive text accessible via
> > linked at the top (e.g., what to do if your package is not OK)
> > which gives general suggestions on how to improve status
>
> Good idea.  Perhaps a Bioconductor package bug fixing How To.  Are you
> volunteering to draft something ;-)

I would be willing to start on this.  This isn't truly about bug
fixing, though, it is primarily about responding to the findings on the
package check page.  This involves

1) understanding the vocabulary of check status results
 - "WARNINGS/ERROR":  i need to look through some examples to see what
kind of documentation would be helpful here -- we should write
up what to do for the most prevalent problems
 - builds but doesn't pass check ... this is a somewhat
obscure situation, may relate to platform or java dependencies.
We want to help developers avoid this.
 - "OK" -- i guess this is what we are shooting for, but there
may be a need for more refinement here -- some conditions like
vignette lacks keywords, or package lacks vignette, or too many
functions are aliased without proper pages/examples, can be present
with packages in OK status.  such packages are OK by a very
particular criterion, but in reality need more development.

2) understanding relationship between platform used and check
status results.  i suppose that we get between-platform discrepancies
when portable coding is not used, and we can give pointers on that
in a document.  we should provide clear guidance to people on
how they can build and check their own packages on windows machines --
if it looks like people are just avoiding that superficially.
(we could assemble the links to the required tools and quick
installation notes in one of our pages for this purpose).

Perhaps what we really need is to put some information about this
in the "How to create Bioconductor packages" document --
we have some links that relate to this on the developer page
but we may need something much more concrete, along the lines
of Writing R Extensions, and this would point developers directly
to the check status page -- which really needs to be as self-documenting
as possible.