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

Wed May 1 03:54:33 UTC 2013

On Tue, Apr 30, 2013 at 10:49 PM, Mike Schinkel <mike at newclarity.net> wrote:

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

Image handling was added because IM generates better images than GD. It
paired nicely with end-user media features, but it was arguably a user
feature as well. The way it got written — as an API that allowed for more
image manipulation editors to be added — benefits developers, of course.

WP_Theme was an upgrade of an existing API. (I say that generously, because
what we had previously was terrible and hardly an API.) While it made some
things in 3.4 a bit easier to develop, it really was just something that
had been grating on my nerves for years because it hindered a number of
other things. It actually came out of the desire for theme headers to be
fully internationalized (a major 3.4 push) and after realizing all of the
potential performance gains.

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

Of course it was. My point is: I fail to see a problem with playing the
long game here. I do believe it remains plugin material. I also do believe
that it *could* become core material in the future. I just don't see why we
need to rush it. But also, just because it doesn't yet make sense for core,
it doesn't mean it isn't suitable for development or use.

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

Yes, there *are* a number of new APIs and schema changes that are a higher
priority, and that do need to happen before object relationships are
considered. (They relate primarily to the taxonomy schema and API.)

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

???. A process like this is already happening. Look no further than the
Posts 2 Posts plugin itself. A number of us like it, and we strongly
support what scribu and others have done in that space. I'm not even
questioning that P2P is ready for core. I don't think core is ready for P2P.

Often, when we decline to take action on something, plugins are developed
to fill the void. This is precisely what you just asked for — over a period
of several releases, one or more developers are building and testing the
features. Even if they are not "blessed" in some cases, we do pay
attention. My point is, we're not "ignoring" it. We're deliberately letting
things play out at the plugin level. If you want something so bad, build
it. It doesn't need to be in core — immediately, or ever — to be a
successful contribution to the community.

Nacin

On Tue, Apr 30, 2013 at 10:49 PM, Mike Schinkel <mike at newclarity.net> wrote:

> > 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>