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

Mike Schinkel mike at newclarity.net
Wed May 1 02:49:59 UTC 2013


> If it's benefit an user indirectly it still benefit the user. 

True. But I've been told many times by members of the WordPress core team they won't adding an API unless a feature being added to WordPress core depend that API.  

This is unfortunately one of the few places in which I believe Drupal has a leg up on WordPress, their embrace of empowering APIs.

> Deployment is easy to talk about but in the next releases WordPress has other things to fix first.

I only mentioned deployment, as an example, because it was an issue Harry mentioned. 

> Not saying it isn't important but there are other priorities.

I have no issue with setting and following priorities.  

Speaking of which, a public roadmap would allow known priorities to be known by more than a few people and probably ease a lot of frustration. (Personally I'm mostly over the frustration at this point and resigned to the state of affairs, I commented because I believe my doing so help others newer to the list understand.)

> CPT is a bad example. That was really needed.

It is a great example because it illustrates the tremendous value an API can have, which is why I mentioned it.

> See a fresh new API for themes and Image handling. Indirectly they benefit from it but hard to say how.

Those were added AFAICT only because there was an end-user feature being added that needed the API.

> The example of posts relationship is also something that is a bad example. 

Again, not a bad example. The fact is that I submitted the ticket 3 years ago and rather than have the team recognize the need many people who didn't understand the use-case explained:

"This seems to be straightforward plugin territory to me. Fairly niche use, etc." - Really? I hope I don't have to explain why that comment was shortsighted.

"We already have many-to-many relationships between posts. You can relate a bunch of posts to other posts by simply giving them all the same term in a taxonomy"  - I objected to this as being unworkable in practice yet that was the line the core team stuck with at the time. Note that Post2Posts recognized how unworkable taxonomy was and moved away a long time ago. 

"There's no point in creating the table if we don't provide UI ... to go with it." - There's that "We can only add something that is backed by a feature we are including" which means only APIs that support features that are needed for core additions can be added.

This ticket was a great case-study in the core team not having the experience (at the time) to recognize the needs expressed in the ticket yet being quick to dismiss the experience of people who had real world experience they did not.

> 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.

I would be interested to know what types of open tickets are a critical path to object relationships?

Or is it a case of simply there being many tickets and so only so much bandwidth? 

If the latter then the solution (for a need of this magnitude) is to bless a team of people who have the need and commission them to build and test the features, maybe even over a period of several releases, instead of just ignoring the requirement for 3-5 years. I am certain that for features like this all that would be needed would be for the core team to ask.

> Also it's lame to attack me personally without mentioning of tickets.

Do you not recognize the irony of your telling Harry "The issue is that you think in "I" and not in WordPress user base in general", which you evidently did not see as lame, and your calling me lame for pointing out that everyone has their own "I" perspective and that maybe it's a good idea to consider your own "I" perspective before admonishing someone else for theirs?

> Obviously you will find more tickets that I say that it should be closed then it should be opened.

And that's one of the things I have noticed, that rather than try to understand a reporter's needs I have gotten a strong impression over many tickets that you have been quick to dismiss their experiences as irrelevant, and I think that approach does harm to the community.

> 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.

So you must also agree that it would be lame to want me to not tell my opinion. But that seems to be what you are implying, that I should hold my opinions, no?

> 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.

Has nothing to do with that one ticket and I'm disappointed that you would try to make this about a single ticket of mine. I don't ever remember the one to which you refer.  

I'm subscribed to the Trac firehose, so I see a lot of tickets when I have time to watch them and my impressions came collectively from what I saw reading them, most of which I do not comment on. 

I almost didn't mention this but since you implied my point was invalid because I was just upset about my ticket I decided to scan recent tickets and found many over the last four month that are good examples (note I did not report nor participate in on any of these tickets):

http://core.trac.wordpress.org/ticket/24215#comment:2
http://core.trac.wordpress.org/ticket/24010#comment:1
http://core.trac.wordpress.org/ticket/23451#comment:1
http://core.trac.wordpress.org/ticket/23434#comment:1
http://core.trac.wordpress.org/ticket/23394#comment:2
http://core.trac.wordpress.org/ticket/23171#comment:6
http://core.trac.wordpress.org/ticket/23143#comment:3

What's my point here?  I'd simply like to see people who try to participate given more respect. Snap judgements for ticket closure without first making sure the ticket is understood can lead to a lot of discontent in the community, some of which is being evidenced by this thread.

-Mike 


More information about the wp-hackers mailing list