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

Tue Apr 30 19:20:22 UTC 2013

If it's benefit an user indirectly it still benefit the user. Deployment is easy to talk about but in the next releases WordPress has other things to fix first. Not saying it isn't important but there are other priorities.

CPT is a bad example. That was really needed. I can't say 80% but it was a lot. People used Posts/Categories to manage flows. And as said the 80% rule isn't always used.
See a fresh new API for themes and Image handling. Indirectly they benefit from it but hard to say how.

The example of posts relationship is also something that is a bad example. A lot of people want to include that in core but still a lot of things to be dealt earlier. See the amount of open tickets. Adding features does not reduce that.

Also it's lame to attack me personally without mentioning of tickets. Obviously you will find more tickets that I say that it should be closed then it should be opened. Also I almost never use +1 in tickets.
Also it is my opinion about how people using it and I can be wrong. That doesn't mean that I can't tell my opinion about it. That would be lame.
And as far as my memory goes you mean 1 particular ticket that you disagreed on. And in the end it got closed because more people agreed on that.

You can store objects in an option. Smart thing or not but going the JSON road would limit that. JSON is damn handy for data transfer and on public API level it's used for almost everything.
That said I don't play that much with options and fine in how it is.

Marko

Op 30 apr. 2013, om 20:44 heeft Mike Schinkel <mike at newclarity.net> het volgende geschreven:

> 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