This is a scratch pad of good ideas for battening down the hatches for 1.0 release of a plugin. We are considering these steps now, so we know what to do as we approach the UDIG 1.0 release.

1. Quality Control measures from Programmer's Guide:
   • Eclipse House Rules
   • Hacking Guidelines and User Interface Guidelines
   • Internationlization, Initialization, Threading and Resource violations will result in immidiate downcheck
2. Assign a plugin maintainer with following responsibilities:
   • Front line contact person
   • Accepts patches for bug fixes to plugin
   • Don't accept patches for new features
     (instead provde an extention point, because where one feature is requested a second is sure to follow)
   • list contact information in plugin.xml provied by field
3. Have an associated test plugin
   • test cases for data models others depend take priority
   • No minimum coverage here, the focus is on playing nice with others
   • If you care have a test for it
4. Documentation
   • Have a page on the wiki for the plugin with links to schema, javadocs, tutorial if available
   • API class and interface javadocs are required, even if only one sentence
   • API package javadoc recomended location for code examples
5. Tutorial is not manditory, just cuts down on front line contact person emails
   • For strategic pacakges that are the focus of the framework, such as Catalog, Tools, Renderer, StyleConfigurator, MapGraphics and so on a tutorial will be required as part of the Developers Guide.

Links to more information about this stuff:

• [Project Plugins] as used for Developer >Reference
• API rules of engagement from Developer > Programmer's Guide