> What I would like to see would be that people with similar needs came > together to maintain 'community' versions of their Trac setup with a > set of plugins they would need for their use.
I have two concerns with that approach -- Brand Dilution and Fragmentation (and yes, they're related). If you break Trac up into a number of sub-projects for each community, you're more likely to dilute the public awareness of what Trac is. I think the OForge project is exactly the type of thing you're talking about (http://code.optaros.com/trac/oforge/). While I applaud the efforts put into OForge, nobody who's not already familiar with Trac and OForge are going to have any idea that "OForge" and "Trac" are indeed intimately related. In fact the only place on the OForge homepage that mentions Trac is the "Trac Powered" logo in the footer. So if OForge becomes popular (and develops it's own "brand"), Trac isn't really going to benefit much from that. Similarly the improving popularity of Trac isn't really going to help OForge become more popular. It's not clear to me how having 3 or 4 separate sub-projects helps Trac. By Fragmentation, I mean that it'll be easy for efforts put into a the sub-projects to not be generally promoting Trac as a whole. If everyone's careful this can be mitigated, but it's a slippery slope as well. It's easy to get in a situation where a sub-project needs a slightly variation on a plugin. It's not generally useful outside of the sub-project environment so they fork it off. Now future changes to the original plugin and the forked plugin need to be maintained separately. Over time this is tough. > I am not a great believer in the design-by-committee, and the > everything-delivered-and-supported-by-Trac based on popular vote is > guaranteed to be a frustrating experience for everyone involved. I agree that "design-by-committee" can be a problem. But "design-by- lots-of-separate-committees" can be a problem as well. As for "popular vote", I was thinking more along the lines of "core developer vote". I wasn't suggesting that the entire community as a whole make final design decisions as to what should be included as a "Core Feature". What I do think would be useful is having the people using Trac expressing their thoughts/needs (like the new ticket voting on T.E.O), and the people doing the actual work on Trac taking that into account as they make their decisions. But the final call should be with the people who understand Trac the best (the core developers). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
