[wp-hackers] Less than Core, More than Plugins/Themes: Proposing Optional Modules.

Tue Feb 3 17:45:39 GMT 2009

Would having a plug-in then child plugins resolve this?

Sent from my iPhone

On 3-Feb-09, at 13:21, Mike Schinkel <mikeschinkel at newclarity.net>  
wrote:

>> * Drupal modules are a clusterfuck. No personal offense meant
>> to any Drupal developpers or users out there, but my experience
>> with that platform gives me no particular confidence in the kind
>> of system you are describing
>
> No it's not exactly as I desscribed; far from it. I worked in Drupal  
> for 1.5 years and most Drupal modules are exactly like WordPress  
> plugins. Anyone can add one, and (too) many do.
>
> Same is true with WordPress plugins. Are you forgetting how much  
> crap there is in Extend?
>
>> They also always feel pretty handicapped by their slavish
>> acquiescence to the Drupal API (which covers everything like you
> propose).
>
> Saying that obscures the issue. WordPress has an API just like  
> Drupal has a API.  The fact you don't like Drupal's API doesn't mean  
> that having an API is bad. I'm not advocating a Drupal-style API,  
> I'm advocating the ability to add things that can become standard  
> that don't make the cut into the core because they are "too  
> specialized."
>
> Some of the things Drupal does *really well* is "standard" modules  
> and shared APIs.  WordPress could learn from the good parts of that  
> instead of taking it as a "not invented here" attitude.
>
>> I think that the solution to these issues isn't a paradigm shift
>> but rather little steps towards encouraging the kinds of behavior
>> that is good for everyone and discouraging the behavior that isn't.
>
> I'm open to alternate solutions. I'm not married to the idea, just  
> to getting a solution that works.
>
>> Make the plugin pages on extend more development-focussed
>
> Agreed.
>
>> The wp forums is NOT the right place for development, and extend
>> should be doing something. It would make it easier for different
>> users to work together to solve shared problems (and would make it
>> easier for concerned users without problems to help their unknown-
>> neighbors).
>
> Agreed. Frankly I'd like to have mailing lists that are specific to  
> areas, ie. "wp-image-management", "wp-twitter-integration", etc.  I  
> find mailing lists the most effective way to stay involved and one  
> of the main reasons I moved from Drupal to WordPress.
>
>> Have plugin reviews for api compatibility -
>
> I COMPLETELY agree with that.
>
>> Maybe this could be a party idea for those who want more fun in
>> between Wordcamps, "Wordpress Hacker Plugin Review Night".
>
> BTW, I'm seriously considering a WordCamp for Atlanta later this  
> year...
>
>> A lot of the issues you describe basically come down to "Devs
>> aren't using the api properly".
>
> Many, but not even half of the issues.
>
>> In all your examples I could think of API ways to accomplish them
> (store tweets in posts table with 'twitter' as type, for example).
>
> EXACTLY.  That's where the community process would be invaluable,  
> and why I called for optional modules that would be on peer with  
> core; that would get the community to discuss them (and it could be  
> a sub-community.)  I too thought of "twitter' as a type but then I  
> thought "What about Facebook Status Updates?"  So should it be  
> "twitter" or "status?"  That's what the community would be  
> invaluable to address and that doesn't get addressed for plugins;  
> they just do whatever first comes to mind which is often not the  
> best for long-term.
>
>> A more dev-focussed extend would also make this easier, as people
>> could come together to put friendly pressure on plugin devs to
>> clean up their act.
>
> Agree too.
>
> Anyway, given the pushback I've gotten from selected individuals  
> (because I honestly don't think they really understand the proposal)  
> I'm going to take a different approach. I'm going to instead start  
> bringing up things that are needed and when told "No, that would  
> bloat the core" I'll be asking why they can't be optional modules.
>
> See my next email.
>
> Further, I'll call for dependency management and auto-install of  
> dependent plugins. Is there a reason we can't do that?
>
> -Mike Schinkel
> http://mikeschinkel.com/
>
>
>
> ----- Original Message -----
> From: "Jeremy Clarke" <jer-wphackers at simianuprising.com>
> To: wp-hackers at lists.automattic.com
> Sent: Tuesday, February 3, 2009 11:37:42 AM GMT -05:00 US/Canada  
> Eastern
> Subject: Re: [wp-hackers] Less than Core, More than Plugins/Themes:  
> Proposing  Optional Modules.
>
> Lots of great points being made here. I think I'm personally leaning
> towards the status quo on this one though.
>
> Some bullets:
>
> * The plugin ecosystem squeezes more work out of volunteer developers
> than core. Obviously it would be nice if we could all sit back with
> absolute confidence that everything we need will always be provided to
> us for free, but that would overload the core development team. As it
> is prestige, notoriety, etc. are available to people to create or take
> care of important plugins. They take on responsibility because they
> need the thing, and we all benefit. This is the 'caring' DD32 was
> talking about. I think if optional functionality is moved into core
> there would be less people putting time into it (though obviously i
> have no proof).
>
> * Core moves slowly: I think that lots of plugin devs like having full
> control over their work. They would do less work if they had to go
> through the hoops you have to jump through to get patches committed to
> core. It is frustrating and time consuming, which is good because it
> keeps quality high and weeds out people who aren't committed to the
> long-term stability of core, but not necessarily the best place for
> groups to collaborate around important shared functionality.
>
> * core should not be managing teams of module devs - this is pretty
> obvious to me but Mike's description of having teams working on the
> modules sounds like a management nightmare. The core committers are
> very busy looking at one function at a time as previously stated. The
> whole ecosystem right now is a kind of anarchic meritocracy that runs
> based on tickets rather than people and I think it works pretty well.
> I think asking the devs to go around kicking the teams awake is a very
> bad idea. If anything they should just make note of the truly
> important plugins and offer friendly advice and encouragement and help
> to them as needed in an informal way, just like they currently do to
> developpers who work on important parts of core and take
> responsibility for them.
>
> * If the API sucks lets fix it - The whole discussion about a paradigm
> shift towards moving API into optional modules I think misses the
> point entirely. The things that get turned down for core aren't API
> they are uses of the API. If you make a consistent argument for a
> given bit of API and do the work to implement it then there's a good
> chance it will get committed. In my experience when I ask for a hook
> that is really needed I get it as long as I write a patch and convince
> people why it's important. When it is turned down it's usually because
> there is already another place in the code that can do what I need.
>
> * Drupal modules are a clusterfuck. No personal offense meant to any
> Drupal developpers or users out there, but my experience with that
> platform gives me no particular confidence in the kind of system you
> are describing (which is exactly how Drupal does its business). Their
> modules are often abandoned, out of date, bug-ridden and also crappy.
> They end up feeling like design-by-committee in a very annoying way
> and ultimately aren't that much more consistent than the better WP
> plugins. They also always feel pretty handicapped by their slavish
> acquiescence to the Drupal API (which covers everything like you
> propose). They somehow manage to all feel awful to use because they
> are built that way, unlike WP plugins which (while it can be
> annoying!) vary widely, from the ugliest plainest most useful thing to
> the elaborate extravagant plugins that you love to use.
>
>
> I think that the solution to these issues isn't a paradigm shift but
> rather little steps towards encouraging the kinds of behavior that is
> good for everyone and discouraging the behavior that isn't.
>
> Some ideas that wouldn't change the big picture but would help fix it:
>
> * Make the plugin pages on extend more development-focussed - I'm
> constantly wishing I had access to some kind of bug tracker where I
> could post patches or bugs on extend. I think there might be a trac
> set up automatically somewhere but it's invisible from the extend page
> and no one uses it as far as I can tell. The wp forums is NOT the
> right place for development, and extend should be doing something. It
> would make it easier for different users to work together to solve
> shared problems (and would make it easier for concerned users without
> problems to help their unknown-neighbors). Ideally the dev would have
> the ability to turn off the development stuff IF they had another link
> or place to forward users.
>
> * Have plugin reviews for api compatibility - Maybe this could be a
> party idea for those who want more fun in between Wordcamps,
> "Wordpress Hacker Plugin Review Night". A lot of the issues you
> describe basically come down to "Devs aren't using the api properly".
> In all your examples I could think of API ways to accomplish them
> (store tweets in posts table with 'twitter' as type, for example). A
> more dev-focussed extend would also make this easier, as people could
> come together to put friendly pressure on plugin devs to clean up
> their act.
>
>
> -- 
> Jeremy Clarke | http://simianuprising.com
> Code and Design | http://globalvoicesonline.org
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers