Proposal for Core Compnents (Plugins)

[chipbennett]

1) You don't know that.
2) You have to start the ball rolling with something, somehow.

They are not existing plugins; therefore, they by definition cannot meet your stated criteria.

Yes, well, I'm not a fan of "written down" either. When you write a thing down, you set it in stone. Then when you change it, people come along and say "this isn't what you wrote down". Yes, it's not what was written down, because it changed.

Not writing something like this down is foolish and immature. It is fly-by-the-seat-of-your-pants stupidity. I can almost guarantee that something *will* be written down, whether you like it or not - and whether it resembles what I've drafted or not.

You're confusing the startup of the process with the eventual goals of the process.

For example, post by email is something that is being moved to a core plugin. Health check, ditto. These are how the ball gets rolling. Other devs may take pieces of functionality and turn them into core plugins as well.

But if you seriously think that no other plugins will come along and become core plugins through some means, then you're nuts.

The whole idea is not just to move selected bits of core code into plugins (although that is a goal), but to also make standard plugins for large pieces of functionality. These will very likely start from existing plugins, because why redevelop the wheel? Yes, a core plugin will be based around "functionality", but that doesn't preclude it coming from an existing base.


Core plugins will be starting from wherever they happen to start from. Why must you tie down ideas and imprison them in your words? Why do you continue to believe that things can only happen one way and that ideas are not amenable to change or differing ways of doing things?

Look at the bigger picture instead of focusing on the immediate details. Then maybe you'll see your objections don't make any sense, because you had the idea wrong to begin with.

Otto, you're just wrong.

Read the IRC chats. Read wpdevel.wordpress.com. Read what Aaron Campbell (to whom I mistakenly referred as "Andrew" earlier) has written on this very forum.

It can't get any more clear than this:

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m188">Jan 11 17:19:03 2010<LI class=nick>PeteMall
• how/who is going to handle the escalation of a plugin to 'core plugin'

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m189">Jan 11 17:19:16 2010<LI class=nick>PeteMall
• what will be the process behind it

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m190">Jan 11 17:19:34 2010<LI class=nick>Jane_
• i think there's still a misconception about this

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m191">Jan 11 17:19:39 2010<LI class=nick>AaronCampbell
• PeteMall: It sounds like plugins won't be escalated.

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m192">Jan 11 17:19:43 2010<LI class=nick>Jane_
• we're not going to choose plugins

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m193">Jan 11 17:19:49 2010<LI class=nick>PeteMall
• I agree

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m194">Jan 11 17:19:58 2010<LI class=nick>Jane_
• we're going to choose areas of functionality that we would have liked to put in core but can't quite justify

• <A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m195">Jan 11 17:20:05 2010<LI class=nick>Jane_
• then invite people to contribute

It couldn't get any more clear than this [emphasis changed from original]:

The reason for that statement is because the name has already been decided, the fact that they're being done has already been decided, and plugins will not "become" core plugins so there's no need to discuss that. Those things have already bee worked out in prior completely open, logged, and transparent discussions.

That's the plan. Existing plugins will not "become" core plugins.

Now, somewhat ironically, I agree with you - exceptional plugins should be considered for "escalation" as a core plugin. Why re-invent the wheel?

But that's not what's planned.

[Otto]

Core plugins having special UI is already on the table I think. There by separating them from other plugins in the adminbackend.

I wasn't referring to "plugins". I was referring to his "components" proposal.

All I see is negativity upon negativity against others.

Well, if I think an idea is dumb, how else do you expect me to express that fact?

Is really the only way to go forward to setup gates? You can't see any other ways to improve plugins in the repository which seems to be why you support this step? (At least based on your OneFineJay comment)

The idea of core plugins as its presented is bad.
Moving stuff out of core to plugins is good. Taking other stuff and start calling it core plugin is bad. There is no red thread to follow.

I honestly have no idea WTF you're talking about here. I tried to parse those sentences half a dozen times... but I got nothing.

The rest of your post was equally confusing, since I'm not sure what you're talking about...

[Otto]

They are not existing plugins; therefore, they by definition cannot meet your stated criteria.

I stated no criteria, and your continued insistence on nailing down an idea that is still being developed makes me think that trying to have this conversation with you is ultimately pointless.

That's the plan. Existing plugins will not "become" core plugins.

Sure they won't. Just keep telling yourself that.

What is said before a thing occurs is not the same as what actually occurs. If you seriously believe that existing plugins will not become core plugins, then I have no way to argue you out of it, but you're still wrong.

And no, I really don't care what Jane or Aaron says, the fact of the matter is that there's a huge base of existing code. If they decide to make "Twitter" into a core plugin functionality, do you *really* think that an existing Twitter plugin wouldn't be used as a starting point? Sure, there might not be a "flag" to turn a plugin into a core plugin, but a new project using the same code as a base is really the same thing, isn't it?

You can say "functionality" all you like, and even shout it from the rooftops, but ALL collaborative code must start somewhere. That somewhere WILL be existing plugins. It's the only way that makes sense.

Not writing something like this down is foolish and immature. It is fly-by-the-seat-of-your-pants stupidity.

Annnnnnd we're done here. I knew I should have left you on my block list, thanks for confirming it.

[chipbennett]

I wasn't referring to "plugins". I was referring to his "components" proposal.


Well, if I think an idea is dumb, how else do you expect me to express that fact?


I honestly have no idea WTF you're talking about here. I tried to parse those sentences half a dozen times... but I got nothing.

The rest of your post was pointless, so I won't bother responding to it.

You do realize, don't you, that he is a non-native English speaker?

A little courtesy goes a long way, especially when critizing someone for their use of a foreign language.

[aaroncampbell]

That's the plan. Existing plugins will not "become" core plugins.

Now, somewhat ironically, I agree with you - exceptional plugins should be considered for "escalation" as a core plugin. Why re-invent the wheel?

But that's not what's planned.

Chip is right. The current idea is that existing plugins will not "become" core plugins. That's not to say that this practice won't change in the future, but right now the plan is to choose areas of functionality with a need and build a plugin to fill it.

Having said that, I hope they only reinvent the wheel if they think they can make a better wheel (as James Pearson said "we think there are probably better wheels to be made"). Most of the time I would think they'd find a developer of a good plugin and ask them to join the project and commit a lot of their existing code.

[Otto]

Chip is right. The current idea is that existing plugins will not "become" core plugins. That's not to say that this practice won't change in the future, but right now the plan is to choose areas of functionality with a need and build a plugin to fill it.

Having said that, I hope they only reinvent the wheel if they think they can make a better wheel (as James Pearson said "we think there are probably better wheels to be made"). Most of the time I would think they'd find a developer of a good plugin and ask them to join the project and commit a lot of their existing code.

And this is different... how, exactly?

I consider this to be a distinction without a difference. Code is code. The name of that code is meaningless.

[chipbennett]

I stated no criteria, and your continued insistence on nailing down an idea that is still being developed makes me think that trying to have this conversation with you is ultimately pointless.

Uh, then what was this:

The idea behind Core Plugins is not a "this is a bunch of plugins we like", it's "these plugins have major development efforts, are well-supported, the developers are active in WordPress core development, and so it's very likely that these plugins will stick around for a long time into the future". That's the main difference.

Followed by this:

Originally Posted by chipbennett
And, right now, there are no criteria - not even an idea of any criteria - that will decide what gets selected to be a "core plugin"

Originally Posted by chipbennett
And, right now, there are no criteria - not even an idea of any criteria - that will decide what gets selected to be a "core plugin"
There are plenty of ideas and criteria. You're just not listening to any of them.

Hell, I just GAVE you an idea, which you quoted no less, and then you turn around and tell me that there's no ideas?

So, first you claim that "these plugins have major development efforts, are well-supported, the developers are active in WordPress core development, and so it's very likely that these plugins will stick around for a long time into the future" are criteria - and admonish me for claiming that there were no criteria (or any ideas for criteria), and then you claim that "stated no criteria"?

I'm not the one being self-contradictory.

Originally Posted by chipbennett
Not writing something like this down is foolish and immature. It is fly-by-the-seat-of-your-pants stupidity.

Annnnnnd we're done here. I knew I should have left you on my block list, thanks for confirming it.

Speaking of foolish and immature.

[chipbennett]

And this is different... how, exactly?

I consider this to be a distinction without a difference. Code is code. The name of that code is meaningless.

The difference - obviously - is that the plugin author in question is under no compulsion to contribute his code. He is free to continue to develop his own plugin separately from the core plugin.

The core plugin team isn't going to "take" the code. Thus, if the plugin author doesn't agree to contribute, then the core plugin won't be starting from that code.

[aaroncampbell]

And this is different... how, exactly?

I consider this to be a distinction without a difference. Code is code. The name of that code is meaningless.

I should have been more clear about that. I'm trying to create the distinction based on two differences:

1) The plugin author would be contacted and worked with

Some people have been making it sound like the core team might just come fork your plugin, make it a core plugin, and you get screwed in the process. While I'll readily admit that the licensing (please...let's not get into licensing here) allows them to do just that, I expect cooperation in the spirit of community.

2) Not all the code from a single plugin will be used

I guess this goes hand-in-hand with the idea that a plugin won't just be forked. For example, I hope they don't start a Twitter plugin by taking Twitter Tools as it sits. Instead, I hope they take the ease of use and Google tracking from tweetable, the widget from Twitter Widget Pro (obviously I'm biased here), the comment handling of tweetbacks, and the tweet from WordPress and tweets as posts functionality from Twitter Tools (neither of which I use, but I see why people want them). Then I hope it gets cleaned up nicely with plenty of filters for things like adding other URL shortening services, etc.

That means at a minimum I hope they involve Matt Harzewski, Me, Joost deValk, and Alex King in the start of the plugin.

[Otto]

I should have been more clear about that. I'm trying to create the distinction based on two differences:

1) The plugin author would be contacted and worked with

Some people have been making it sound like the core team might just come fork your plugin, make it a core plugin, and you get screwed in the process. While I'll readily admit that the licensing (please...let's not get into licensing here) allows them to do just that, I expect cooperation in the spirit of community.

2) Not all the code from a single plugin will be used

I guess this goes hand-in-hand with the idea that a plugin won't just be forked. For example, I hope they don't start a Twitter plugin by taking Twitter Tools as it sits. Instead, I hope they take the ease of use and Google tracking from tweetable, the widget from Twitter Widget Pro (obviously I'm biased here), the comment handling of tweetbacks, and the tweet from WordPress and tweets as posts functionality from Twitter Tools (neither of which I use, but I see why people want them). Then I hope it gets cleaned up nicely with plenty of filters for things like adding other URL shortening services, etc.

That means at a minimum I hope they involve Matt Harzewski, Me, Joost deValk, and Alex King in the start of the plugin.

I don't see those as distinctions. They're just the results of normal collaboration efforts. If you take a plugin and make it have many developers instead of just one, then that is what will naturally occur.

And honestly, if you start out with creating a new plugin from bits and pieces, then you're going to have a harder time selling the idea. Better to take an existing plugin (or at least a large portion of it) and then to add in bits and pieces. The plugin *has to work* for the idea to be at all viable. Best to start with a known base and build onto it, instead of starting anew and cutnpasting stuff from elsewhere.

If you're saying "we're not going to fork an existing plugin", then I think that much should be obvious. But that was never what I was stating to begin with.