Emphasize opportunities for extension over the richness of core features.

Have potential usefulness to all Java developers, regardless of
their application domain.

Match in style to the current JUnit codebase.

Many people have made JUnit extensions that would be useful to a
healthy portion of Java developers, but do not meet all of the above
criteria. For example, the extension may target a particular IDE, or
data that is stored in a SQL database, or in XML, or it may be
experimental, and likely to change API, or it may require an external
dependency. Also, as the popularity of non-Java languages on the JVM
has grown, some people have made extensions to JUnit that make it
easier to use JUnit's core functionality in ways idiomatic to those
other languages.
It has always been an option for developers of these extensions to
publish them on their own repositories. However, having a central
clearing-house as an option for extension developers has some
advantages, including discoverability, documentation, and dependency
management.
The goal is for junit.contrib (just started here) to be this clearing house.
All Java classes in this project should be in packages prefixed with
org.junit.contrib.
Now, the

Proposal

The root structure of the project will contain:

/
README
docs/
java/
scala/ [?]
clojure/ [?]

Thus, a folder for overall documentation, and then a folder
per-language. I haven't thought about how non-java language
extensions should be organized.
Under java, there should be a folder per "subproject" (names chosen,
with apologies, by my favorite naming tool):