This document proposes ways that we as Jakarta can move towards becoming one community rather than many.
Note that there is a counter-argument that states that multiple communities within Jakarta is fine. However, at present this conflicts with the ASF board opinion and legal structure.
Mission
Jakarta has a less than completely clear mission at the moment. Here is a proposed 'mission statement', please feel free to make alternate suggestions:
Jakarta provides a diverse set of Java-based components which aim to make day-to-day development easier. The focus is on reusable, small-scale, single-purpose libraries that can be used directly by your application or by larger frameworks.
It would seem appropriate for whatever mission we choose to be on the top of the Jakarta home page.
Maililng lists
Jakarta has about 16 current project mailing lists. One is very active (commons) and the rest vary from some activity to very little.
Mailing lists are significant as they represent the primary means of communication in a project, and thus the primary form of community. Any change to mailing list structure needs careful consideration.
The aim of any change is to create better oversight of the mature components.
A 'one community' proposal must provide a technique to reduce the mailing list silo effect, where developers are not interested in other lists (and thus other parts of the same community).
Subversion access
Jakarta currently gives out SVN access to individual subprojects.
A 'one community' proposal almost certainly involves removing this barrier. Any Jakarta committer can thus commit anywhere in Jakarta. Social norms will still act as a barrer to undesirable behaviour.
Subprojects
As developers we tend to abstract and form hierarchies naturally. Subprojects are a natural outcome of this. However, Jakarta as 'one community' must mean the end to the term 'subprojects'.
Instead, a focus on many, many components directly at the Jakarta level is the best viewpoint.
Practicalities
The single-level groupings proposal.
Theory - One community split into groups for practicality purposes (everyone together would be chaos!)
- Move all commons proper projects up to the jakarta level in SVN and on the website.
- Commons level infrastructure/pages is dismantled and moved to jakarta-level
- Agree on 4 to 5 groupings for the current subprojects (this is hard!!! it should ideally be driven by the current component owners)$
- The groupings should have bland names - they are not subprojects
- The commons-sandbox moves to be a jakarta concept
- Provide a mailing list for each of the groupings
- Redfine the Jakarta home page to display all the components in Jakarta using the groupings as a navigation aid
- Use a single mailing list to discuss cross jakarta issues, such as maven builds etc. This may be jakarta-general or a new jakarta-dev
- No SVN commit restrictions across groups
$ No existing mailing list/community should be forced into a merger that they are dead set against. This would be bad for both sides of the merger.
The aim is for each grouping to be large enough to avoid inactivity, but small enough to be manageable and to foster community. The proposal also aims to encourage a significant percentage of developers to be in more than one grouping.