On Jun 29, 2008, at 1:53 PM, Scott Bussinger wrote:
> >> 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. > Why is this a problem. We develop Trac to provide people with the tools, it really doesn't matter if they don't know what Trac is. Brand identity issues matter much less in a FOSS world, where money isn't a concern. > 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. Proper design can help mitigate this, but if people are determined to make single-purpose hacky solutions nothing will stop them. These are the same people that would rather maintain a local patch to Trac than make a plugin. > >> 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). Of course, the votes on t.e.o are just to guide us. It is being called into question as to if we actually know what users want, so the vote numbers give at least some idea. There is a huge non-response bias of course, so the numbers must be taken with a grain (or 12) of salt. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
