On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: > On 1/10/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > > > 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. > > > I prefer the term "groupings" (which, interestingly, you switch to below ;) > over "groups".
+1 gave up groups (topological or even finite simple) when i left uni ;) > I also think we should allow the component:grouping > relationship to be 1:N, since not all components will fit tidily into a > single grouping. As a corollary, I don't believe groupings should have their > own mailing lists. not sure i like the idea of fuzzy groupings with 1-N components need to be mapped 1-1 to dev mailing lists but 1-N would work fine on user lists. might be possible to factor 1-1 dev lists (for traffic purposes) whilst retaining fuzzy users lists. > 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. > > > Well, except that the process is that the PMC has to vote in a new committer > to the PMC and then notify the board of that vote. I'm definitely not in > favour of magic notifications to the board when the six months are up, > without an associated vote. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
