2008/6/20 Risto Kankkunen <[EMAIL PROTECTED]>: > > On Jun 20, 1:22 am, "Endre Bakka" <[EMAIL PROTECTED]> wrote: >> >> Unrelated to this is the idea that doing things in plugins is bad. I >> >> really don't understand where people get this idea. > >> Two reasons: >> - Trust >> - Maintenance > > I totally agree. Plugins aren't bad as a technical solution, the > problems come from "trust" (in the general sense, e.g the quality of > the code etc.), maintenance and other user experience problems (I > wrote recently about first not finding and then trying to figure out > which one of the 3 Wiki Include plugins to use). > > I'm also wondering what is the additional cost for users to include > "extra functionality that not everyone uses"? I think the intersection > of functionality that everyone uses is about an empty set anyway... > Having much more functionality available right out of the box (but > still configurable of course) would be much more user friendly. I > wouldn't worry about increasing the package size or even the Trac > process size. > > Including optional functionality in the "core" (as plugins or as core > features not using plugin APIs) would also have the same kind of > benefit that Linux has with their divers: when you make changes to > unstable APIs the core maintainers can pretty easily make fairly > mechanical search+replace through the code tree to update the plugins. > It would require much more for each individual plugin maintainer to do > the same. > > I think Trac could also encourage experimentation by assigning some > APIs non-frozen or experimental and the others as frozen (Mozilla does > this, yes). Trac-hacks could be the place to experiment with plugins > using experimental APIs to see if they work in practice and can be > frozen in some future release. > > I see Noah and Endre talk past each other, because Noah looks only at > the developer experience (Trac code is perfect and we keep releasing > only perfect code, plugins don't have technical problems) and Endre > thinks about the user experience (Trac is highly imperfect for almost > every use case since it contains only the common subset of features > everyone needs and that is close to the empty set, figuring out what > plugins to use is a pain). There are no technical solutions to address > Endre's comments, it's about the mindset and attitude. If Trac is not > just a programming exercise, it needs to pay attention to the user > experience as well. > > I know Linux and Firefox (and git) are not perfect, but I thank their > developers for not trying to make them perfect and force me to use > some other non-perfect OS and browser. It's also a fallacy that people > would switch using the perfect Trac (or OS or browser) once it is > released in the distant future; good enough is good enough for users. > The perfectness of the code is not a value in itself, it's only a > means to make a better product faster. Having a rapidly improving > product also attracts more developers which helps to improve the > product faster and making less short-cuts while doing so.
Excellent post Risto. I'm not sure what the solution is, but it's obvious that the status quo could stand to be improved. -- Evolution: Taking care of those too stupid to take care of themselves. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
