I agree. Zend Search works... let's put it to work! On Sun, Feb 22, 2009 at 12:20 PM, JPhilip <[email protected]> wrote: > > I think a full text search engine on the plugins README would help > people a lot. > It is hard to find what you want when you can only search on name and > author. > > On Feb 22, 5:27 am, Tom Boutell <[email protected]> wrote: >> On Sun, Feb 22, 2009 at 9:10 AM, Bernhard Schussek <[email protected]> >> wrote: >> >> > I understand that, but we have to investigate the cause of this >> > problem. I guess that very few people use or even know about your >> > plugins. Again, I think the root of this problem is the current >> > situation about the plugins. There are too many plugins with too >> > little information about their quality and about differences between >> > similarly named plugins as well as too little documentation. >> >> I agree entirely here. >> >> > I personally mostly go for custom solutions, because the time required >> > for finding an appropriate plugin, getting to know how to use it and >> > debugging it hugely exceeds the time required to write the required >> > functionality myself. I can well imagine that other developers feel >> > the same. >> >> I have this urge a lot too, but I wind up regretting it. (: We got a >> lot of mileage out of sfSimpleCMSPlugin before it got stale. We also >> get a lot from sfFeed2Plugin, sfWebBrowserPlugin, >> sfDoctrineActAsTaggablePlugin and sfJqueryReloadedPlugin. We've >> contributed back to sfDoctrineActAsTaggablePlugin and >> sfJqueryReloadedPlugin, but that didn't take as long as reinventing >> them would. >> >> And of course everybody uses sfDoctrineGuardPlugin or sfGuardPlugin, >> but since those are practically in the core I hesitate to mention >> them. >> >> >> Most of the time a few "burning souls" do most of the >> >> work on any given project. >> >> > Well, that's always the case for OSS with little publicity. >> >> It's the case for OSS with lots of publicity. Most of the work on >> Firefox, OpenOffice and even the Linux kernel has historically come >> from a small core of people. >> >> >> The prefixes also serve to keep the sf namespace clean for new core >> >> plugins >> >> > Why should the core team release functionality for something that is >> > already actively being developed by the community? >> >> I was referring to the middle ground between plugins at large and the >> actual Symfony core: "core plugins." Plugins like sfGuardPlugin and >> sfSimpleCMSPlugin that are blessed with access to the ticketing >> system. Functionality that many, many people need and more than a >> handful of people are willing to contribute to, but which nonetheless >> doesn't need to be in the core itself where everyone would be stuck >> downloading it. Core plugins would also need to be released under a >> suitably open license (such as the MIT license used by Symfony >> itself). >> >> I like the idea of reserving the sf- prefix for core plugins. Plugins >> that the Symfony team has recognized as being strong enough and >> popular enough to deserve that designation. Conversely, inclusion as a >> core plugin would be attractive to developers and we'd be willing to >> give up our own two-letter prefix in exchange for being on a list of >> plugins that people actually use. (: >> >> Of course, a comment system would also be useful. It would be more >> democratic than waiting around to be blessed as a core plugin, and a >> lot faster too. >> >> >> they prevent me from getting stuck if somebody *else* >> >> abandons a project which is camping on the "right" name for something >> >> I want to do. >> >> > In this case nothing holds you back from taking over the lead of the >> > abandoned plugin and to work on a next major release. >> >> Nothing but the months of politics and nonsense that ensue before >> everybody agrees that this has happened and I'm designated as a >> developer on that project. >> >> > I see that, but you cannot compare the size of these projects with the >> > size of the average plugin. There's just no point in forking an >> > abandoned plugin that covers maybe 1000 lines of code. Such a plugin >> > cannot even be considered "complete", so somebody should take the time >> > to finish it off instead of forking it. >> >> sfSimpleCMSPlugin is currently an "abandoned plugin." It's not >> trivial, and it's quite complete for Symfony 1.0. It's just not moving >> in new directions anymore. >> >> > I would really like to know some plugin development and usage >> > statistics. In the past, Fabien only ever released information about >> > how many new plugins had been published. I don't think that this >> > information is very useful. I rather would like to know the average >> > development time before plugins are abandoned, the ratio of >> > functionality vs. users etc. If we had these statistics, we could base >> > our investigation of the "plugin problem" on some real facts. >> >> I agree completely with this statement. >> >> -- >> Tom Boutell >> >> www.punkave.comwww.boutell.com > > >
-- Tom Boutell www.punkave.com www.boutell.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
