Folks-
As more and more plugins are being used outside CBIL, it is becoming
clear that the plugins need more documentation, and in some cases need
to be cleaned up for use outside of CBIL.
The idea we have come up with is to begin the process of "certifying"
plugins. A certified plugin would:
- be listed as such on a web page available from gusdb.org
- have argument lists that make sense and conform to an (emerging)
plugin arguments standard
- have a usage string that makes sense
- be checked for GUS 3.0 compliance
- be checked for hard-coded references to CBIL-specific files or data
(eg externalDatabaseReleaseIds)
- be documented.
- ultimately, we would also like the plugins (new ones anyway) to
conform to a structured programming standard
For the documentation, we have in mind to develop a "plugin
documentation template." This template would specify a bunch of
information about the plugin that needs to be supplied, eg:
- overview of the plugin
- dependencies on other data (with pointers to plugins that provide it)
- sources of input data
- how to restart the plugin
- failure cases
- expected run time
- expected db resource usage
- other assumptions
- overall context of how the plugin is used
To get things rolling, I would like to poll everybody for:
1. which plugin should we start with as a demonstration project
2. please add to and/or improve my list of questions the plugin
documentation template should ask
Any and all other ideas are encouraged.
Steve
|
