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

Wed May 1 03:58:52 UTC 2013

What exactly needs to be done before P2P is to be considered?  I would love
to give any help if I can

On Tue, Apr 30, 2013 at 10:55 PM, Andrew Nacin-2 [via Wordpress Hackers] <
ml-node+s1065353n41388h64 at n5.nabble.com> wrote:

> On Tue, Apr 30, 2013 at 10:49 PM, Mike Schinkel <[hidden email]<http://user/SendEmail.jtp?type=node&node=41388&i=0>>
> 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=41388&i=1>>
> 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
> > [hidden email] <http://user/SendEmail.jtp?type=node&node=41388&i=2>
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=41388&i=3>
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://wordpress-hackers.1065353.n5.nabble.com/WordPress-Maturity-was-Re-hate-tp41331p41388.html
>  To unsubscribe from WordPress Maturity (was)Re: hate, click here<http://wordpress-hackers.1065353.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=41331&code=ZnVua2F0cm9uaWNAZ21haWwuY29tfDQxMzMxfC0xNDEzMDQ4NDgx>
> .
> NAML<http://wordpress-hackers.1065353.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

--
View this message in context: http://wordpress-hackers.1065353.n5.nabble.com/WordPress-Maturity-was-Re-hate-tp41331p41389.html
Sent from the Wordpress Hackers mailing list archive at Nabble.com.