Component contribution guidelines

The same rules which apply to writing almost any kind of code apply to writing components to be submited, improved and reused: writing easy to read, consistent and well documented code. However, there are broader considerations when designing components so that people on the other part of the globe could use them.

Language

Most programmers probably wouldn't even mention it, but it's an issue, nevertheless. At the moment, the global language is English. Some people or even entire componies name variables and document code in their native language, but if I submited a component with variable names in Croatian, it'd probably be easier for someone to build a new one than to use mine. In case a component starts out as a specific component, and is then generalised and reused, it should be refactored so that there remains no trace of the original language used to describe how the component works.

Tests

It's vital that reusable components are dependable: if it's patch-over-patch-over-bad-design and contributed "as is", it might do more harm than damage. Runnable tests are therefore (among a number of other things) very welcome wherever applicable. User interface components are somewhat specific test-wise, but HtmlUnit or HttpUnit might be the tools of choice.

Structure

[Don't really know what to suggest here: packaging, docs, src, where, how?]
[Consider automation possibilities (palette definitions, eclipse update etc.)]

Site-specific component contribution instructions

The [Where] page describes where components can be contributed so that they get the best exposure.
[Don't really know how to contribute to these sites, but it wouldn't be a bad idea if someone who contributed to tassel or tacos or t-deli filled in the details. ]