As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future.
* Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things.
* Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list.
Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example.
Commons would be groupalized out. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification.
* No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI.
* Improved Committer->PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC.
* Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc.
* Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list.
----- Shout, scream, yell :) Hen On Mon, 12 Dec 2005, Henri Yandell wrote:
dum de dum de dum..... Just to be public so that it doesn't look like I'm sneaking around trying to manipulate things. -- I'm starting to open the question of TLP on many of the Jakarta dev mailing lists. It's with a general plan where we would see another half a dozen subprojects move to TLP and then really leave Commons as the main entity inside Jakarta along with some commons-like components that are currently subprojects. I've been talking unofficially with lots of people at ApacheCon, so I've had a fair bit of feedback on various bits. The important part is that the loose plan above finds a way to coalesce the Jakarta community into a much tighter, more TLP e like project. I've talked with a couple of board members to feel out things would be. One question being, is it a problem if we're pushing a TLP with just a few committers. The answer I had was that Excalibur is the example TLP, it's rather dormant and it's not a problem. I was also advised to be a bit more active in pushing forward. I think this makes sense, a lot of our cross-community activity is gone because people with high activity tend to move to TLP, so we need a bit more drive to get things done. Thus the change of tack that I'll be trying to pull off without getting hung :) Please discuss, argue, wibble; but what I'm looking for are active ways forward instead of maintaining the status quo. I don't think the status quo is good for Jakarta as an entity, it puts strain on our oversight because the number of subprojects stretches the chair's and community in general's ability to keeps things covered. *denies the blindfold and stands against the wall waiting* Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
