[wp-hackers] WordPress Maturity (was)Re: hate

[Harry Metcalfe]

I couldn't agree more, mike. Exactly right.

-------- Original message --------
From: Mike Schinkel <mike at newclarity.net> 
Date:  
To: wp-hackers at lists.automattic.com 
Subject: Re: [wp-hackers] WordPress Maturity (was)Re:  hate 
 
On Apr 30, 2013, at 1:53 PM, Marko Heijnen <mailing at markoheijnen.nl> wrote:
> I play with all kinds of projects and I can see your issues. But the issues is, should it be in core? And the rule is if 80% of the users will benefit from it then it will.

That perspective applied blindly is one of the problems.  BTW, this is a general comment about WordPress project governance and not directed at you.

I agree the 80% should apply to **end-user features**. Unfortunately the same benchmark is used when it comes to discussions of APIs and certain standardization.  

For example, deployment could great benefit from an API and some standardization of the process which would allow 3rd parties to all build off the same base.  There need not be everyone bungling through the details of deployment; WordPress could add a standard way for programmers to deal with it and then plugins and themes could enable far more than 80% of users to benefit. As it is right now the efforts to solve this problem are widely fragmented and consume a huge amount of time of people that could otherwise be much more productively used.

Let's look at a wildly successful feature that was added that 80% of users didn't need: Custom Post Types.  Since CPTs were added themes and plugins and even custom site builders have used them to great effect, and that has helped well more than 20% of users. But directly speaking, less than 20% would have said "we need this" because 80% or more are bloggers who to their own eyes just need posts and maybe pages.

When a coterie of core developers identify the need for an API in something they want, they dive in an add it without the need for 80% of users to directly benefit.  As it should be.  But when there is a broad need for an API that most of the core developers don't currently need but many developers on the outside do they dismiss it as not being something for the 80%.

The problem is developers build things for other people. I don't know what the multiplier is, but let's say that for every developer solving a problem 10 end users benefit.  If that's true, and considering cross over, then if probably only 20% of developers need something then it probably would benefit over 80% of end users.

Here is a perfect example[1] of a feature that is badly needed that could probably benefit 100% of user but probably less than 5% of end-users have no clue why it is needed.

Listen, I'm not trying to upset the apple cart. In general WordPress' processes work well. But the 80% end-user rule applied to efforts to standardize and potential internal APIs is a bad use of the rule.

Harry mentioned poor quality of plugin code and you said it cannot be helped. It most definitely could be helped by providing a plugin framework that handles most of what needs to be done in 80% of plugins using a declarative approach similar to register_post_type().  I've even written one such plugin framework I use for client projects and it's on GitHub, although I've not had time to document it yet so I won't point to it. But if you apply your formulation of the 80% rule to the question of should such a plugin framework be included in core it will never even be considered even though it would solve many problems for the user-base at large.

Here's what I propose. I propose that instead of the rule of thumb "Will 80% of end-users need it?" be changed to "Will it directly or indirectly solve concerns that 80% of end-users have?" 

> Which is not always the case tho. The issue is that you think in "I" and not in WordPress user base in general. What is fine.

Conversely when I see your replies challenging issues others bring up it always seems you are saying "I don't experience this problem so I reject that it's an issue worthy of concern" even if a lot of people are actually dealing with the issue. 

It's hard to get away from "I" 

And in this case I am being specific about your replies, I have noticed them many times on Trac and in wp-hackers in this manner. 

Just giving my perspective as a counterbalance to yours.

> JSON was one time mentioned but has limitations.

As a side note, I'd be curious to know what practical limitations you are referring to.  The API world is finding that JSON can handle pretty much anything that is needed for real-world use-cases.

-Mike
[1] http://core.trac.wordpress.org/ticket/14513

_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers