Proposal for Core Compnents (Plugins)

[Otto]

So, you are equally opposed to the direction being taken with respect to "Core Plugins", as well?

No, because what you want is inherently different. You state the differences yourself.

My basic problem is that all of your "differences" are non-technical in nature. They're differences of *opinion* only. Look at your first three items: components get their own admin screens, they only address major functionality, they are extensible. In what way can existing plugins not fulfill all three of these items?

What makes a "plugin" different than a "component" on a non-arbitrary technical level?

See, all you've done is to create an opinion-based classification of what I'm going to call "big-functionality" plugins and say "hey, these are big, so they should get happy special treatment". Problem is that that makes no sense. Who decides what is "big"? Who decides that A is a plugin while B is a component? Core Plugins have at least an idea of what criteria will decide what gets selected to be a "core plugin".

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.

Nothing? At all? Really?

Yes, really. Your two examples are suggestions that could be applied to all plugins, there's nothing inherent about them that makes them unique to "components".

Plugins should be designed to be extensible, especially if they're adding major functionality. An example would be my Simple Facebook Connect plugin. The base plugin is highly extensible, because there's like 8 sub-plugins which happily extend it. Your suggestion that components be "major" suffers from lack of clarity. Again, what is "major"? Who decides?

It's just a pretty indeterminate proposal, as far as I can tell. You're defining some set of things and giving them a name, but there's no criteria for determining what is what.

Here's a bit of code that adds something onto WordPress: X. Is X a Core Component, or a regular old plugin? How can I tell?

[Otto]

To sum up:

Basically, you're proposing Core Components, which you designate as "big pieces of functionality that can be pulled out into plugins".

But I prefer the idea of Core Plugins, which I will designate as "WP plugins which have significant development efforts behind them and supporting them in the same way that WordPress has a large development effort behind it".

Because the goal is not to create a class distinction, the goal is to get plugins to have bigger multi-author development efforts behind them, improving them, supporting them. The time of the one-man-band plugin should be discarded, IMO. I think it's a pretty hefty failure there.

[chipbennett]

No, because what you want is inherently different. You state the differences yourself.

My basic problem is that all of your "differences" are non-technical in nature. They're differences of *opinion* only. Look at your first three items: components get their own admin screens, they only address major functionality, they are extensible. In what way can existing plugins not fulfill all three of these items?

What makes a "plugin" different than a "component" on a non-arbitrary technical level?

See, all you've done is to create an opinion-based classification of what I'm going to call "big-functionality" plugins and say "hey, these are big, so they should get happy special treatment". Problem is that that makes no sense. Who decides what is "big"? Who decides that A is a plugin while B is a component? Core Plugins have at least an idea of what criteria will decide what gets selected to be a "core plugin".

Coincidentally, nobody can answer that question for Core Plugins, either - which is a deficiency I'm at least trying to address.

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

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.

You've just described what happens to a plugin (or, more accurately, functionality) when it becomes a Core Plugin. You've not at all described the criteria that determine what functionality will be designated for Core Plugin development.

Yes, really. Your two examples are suggestions that could be applied to all plugins, there's nothing inherent about them that makes them unique to "components".

Plugins should be designed to be extensible, especially if they're adding major functionality. An example would be my Simple Facebook Connect plugin. The base plugin is highly extensible, because there's like 8 sub-plugins which happily extend it. Your suggestion that components be "major" suffers from lack of clarity. Again, what is "major"? Who decides?

Again, what is "Core Plugin". Who decides?

It's just a pretty indeterminate proposal, as far as I can tell. You're defining some set of things and giving them a name, but there's no criteria for determining what is what.

Here's a bit of code that adds something onto WordPress: X. Is X a Core Component, or a regular old plugin? How can I tell?

Ditto for Core Plugins.

My criteria are more - not less - descriptive than what we have thus far for Coer Plugins.

[chipbennett]

To sum up:

Basically, you're proposing Core Components, which you designate as "big pieces of functionality that can be pulled out into plugins".

But I prefer the idea of Core Plugins, which I will designate as "WP plugins which have significant development efforts behind them and supporting them in the same way that WordPress has a large development effort behind it".

Those two descriptions are not mutually exclusive. In fact, I would hope that no one would intend for them to be.

Because the goal is not to create a class distinction, the goal is to get plugins to have bigger multi-author development efforts behind them, improving them, supporting them. The time of the one-man-band plugin should be discarded, IMO. I think it's a pretty hefty failure there.

That's just it: with respect to certain functionality, I think there should be a class distinction. There should be more development effort in certain functionality, such as the types I've described.

In case you missed it: I'm all for the approach, and the collaboration, and all the rest. I'm not arguing against any of that.

[Otto]

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? You're being self-contradictory here.

Not everything needs to be formalized into documents. Not everybody cares about formal proposals. This isn't a corporation, and I object to this sort of needless notional red tape.

You've just described what happens to a plugin (or, more accurately, functionality) when it becomes a Core Plugin.

No, and that seems to be the problem. You've got it entirely backwards.

I was describing what should happen to a plugin BEFORE it becomes a Core Plugin.

You've not at all described the criteria that determine what functionality will be designated for Core Plugin development.

You don't develop a Core Plugin.

You develop a plugin. You get other people to help develop it. You support it over some period of time. You get lots of users.

Then you get the core developer community to agree that yeah, your plugin is pretty well done and supported and so should be flagged as "core".

Again, what is "Core Plugin". Who decides?

The core developer community, through means that haven't been determined yet, but which will probably not be as formal as anything like you want it to be.

A Core Plugin is one that the core developer community has decided to designate as such. If you think this is discriminatory, then you're probably right.

My criteria are more - not less - descriptive than what we have thus far for Coer Plugins.

I agree, and that's one more strike against them. They're too set in stone and not fluid. Your ideas are not adaptive to change.

Those two descriptions are not mutually exclusive. In fact, I would hope that no one would intend for them to be.

They're not mutually exclusive, however I don't see the point of the "Core Component" description at all.

That's just it: with respect to certain functionality, I think there should be a class distinction. There should be more development effort in certain functionality, such as the types I've described.

Nooooo.. Again, you have it backwards.

You're starting with the idea of the functionality, and saying that the functionality should be special.

I'm telling you that instead, somebody should implement that functionality, and the implementation should be designated as special.

Because that's what it's all about. There's 30 Twitter plugins in the repository, but Twitter Tools is pretty special. It works well, has frequent updates, great support by Alex King, etc, etc. The idea of the functionality is not special, the implementation of the idea is.

In case you missed it: I'm all for the approach, and the collaboration, and all the rest. I'm not arguing against any of that.

Fair enough, but I think you're putting the cart before the horse here. You don't start with an idea. You start with an existing implementation. Open source has always worked that way, really. One man starts it up and writes the base, perhaps supports it for a long time, and then other people modify it from there. You have to build a community around something that exists, not around a figment.

[chipbennett]

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? You're being self-contradictory here.

Two problems with that:

1) That's not how Core Plugins will work. (See below.)

2) If what you wrote are criteria for designation, then what are "Health Check" and "Post By Mail" (or even "PodPress" for that matter) doing as the first-designated Core Plugins? They fail your criteria.

Not everything needs to be formalized into documents. Not everybody cares about formal proposals. This isn't a corporation, and I object to this sort of needless notional red tape.

No, it certainly doesn't have to be as "formal" as what I've written (though I hardly think what I drafted is so much "formal" as it is merely "written down").

No, and that seems to be the problem. You've got it entirely backwards.

I was describing what should happen to a plugin BEFORE it becomes a Core Plugin.

You don't develop a Core Plugin.

You develop a plugin. You get other people to help develop it. You support it over some period of time. You get lots of users.

Then you get the core developer community to agree that yeah, your plugin is pretty well done and supported and so should be flagged as "core".


The core developer community, through means that haven't been determined yet, but which will probably not be as formal as anything like you want it to be.

A Core Plugin is one that the core developer community has decided to designate as such. If you think this is discriminatory, then you're probably right.

Nooooo.. Again, you have it backwards.

You're starting with the idea of the functionality, and saying that the functionality should be special.

I'm telling you that instead, somebody should implement that functionality, and the implementation should be designated as special.

Because that's what it's all about. There's 30 Twitter plugins in the repository, but Twitter Tools is pretty special. It works well, has frequent updates, great support by Alex King, etc, etc. The idea of the functionality is not special, the implementation of the idea is.

With all due respect, Otto, you are the one who has it all wrong.

The devs have stated quite explicitly - both in the IRC chats and Andrew here in this thread (or perhaps the other one) - that existing plugins will not be designated as "core", but rather, specific functionality will be designated as "core", and the core plugin written - with our without the code contribution of existing plugins.

Fair enough, but I think you're putting the cart before the horse here. You don't start with an idea. You start with an existing implementation. Open source has always worked that way, really. One man starts it up and writes the base, perhaps supports it for a long time, and then other people modify it from there. You have to build a community around something that exists, not around a figment.

But that's just it: core plugins won't be starting from an "existing implementation". They will be starting from designated functionality.

[Jane]

One thing I said in my keynote at WordCamp Atlanta this past weekend was that in the WordPress community, we need to work on people assuming the best, rather than the worst, when they don't understand something/someone's intentions or don't know the full backstory behind things. Asking questions (specifically, in official channels like the IRC dev chats or on wpdevel.wordpress.com or Trac) before jumping to conclusions would be a good thing. This topic is going all over the place before we even have the pilot core plugin project set up: people are accusing others of having bad intentions, people are trying to impose their business preferences on an open source project with hundreds of contributors, people are grouchy because they don't like the name "core plugins," people are annoyed because more hasn't been written officially, etc. ad infinitum.

About the name: "Core plugins" was not chosen by poll. The lead developers discussed about 30 possible names extensively in person in Orlando in December, with pros and cons around how each name would fit in with other WP terminology and if there would be implications about regular plugins. There had been numerous discussions and threads about this before the Orlando meetup, so community sentiment was discussed at this point as well. A short list was put up as a poll to gauge the community response to the top choices. As it happens, the vote was in line with the choice that most aptly described the intention of core plugins (to extend official functionality without bloating the default codebase, to give more people the opportunity to be committers on core without creating a cluster--well.). It was discussed in dev chats as well. It's decided, it'll be "core plugins," and we're not going to change the name now. Maybe after we've got a couple of pilot core plugins and we see how they fit into the WP ecosystem in practice, we may realize that a different name might be more appropriate, but at this point, as another commenter said earlier, lobbying to change the name seems contrarian rather than constructive, as there were several weeks when the decision was still up in the air that it would have been more appropriate to put up arguments for other names.

There is a volunteer team of core contributors and plugin authors working on a proposal for the way it will all work. These things happen in the IRC dev chat and are being put up on wpdevel.wordpress.com. It seems again contrarian rather than constructive to complain about a lack of documentation when people are actively working on it. As things are worked out, they are shared. If someone wants to be involved in the discussions before things are published officially on wordpress.org/development, then the best way to do so would be to join the conversations at wpdevel.wordpress.com or in IRC (login details are always available on wpdevel.wordpress.com).

Something I've been seeing lately is that it seems some people resent it when lead developers make decisions. I find it odd, because isn't that sort of the point of having leaders? That they have the experience and judgment to make good decisions in the best interest of the application? Would it really make sense for decisions to be made by popular opinion? In one breath people complain that a poll allowed a small subset of people to make a decision, while in another breath they want their own small subset of people (involved in the discussion) to be the deciders, rather than trusting the lead developers to do the right thing. Because let's face it, the number of people participating in this thread on WPTavern is no bigger (in fact it's much smaller) than the number of people voting in the poll (a few thousand), and this group is just as self-selected. Sometimes I disagree with the lead devs or Matt (though in this case I happen to be in agreement with them), but in all cases I trust them to do the right thing. It would be awesome if people would be patient and give this experiment a chance to get started before trying so hard to derail it. It kind of implies that there's no trust in the contributors who volunteered to work on it, or in the lead developers to make the right calls. Who knows, you could be pleasantly surprised with how it all works out. And if not, we can try something else based on what we've learned.

[aaroncampbell]

Not everything needs to be formalized into documents. Not everybody cares about formal proposals. This isn't a corporation, and I object to this sort of needless notional red tape.

Well said Otto.

I think Jane explained it all pretty well. I know that many people think the community should decide everything (or many things, or major things...whatever), but in my experience on other community driven projects, the end result is a lot of arguing (debate, discussion, etc) and no progress. I just wanted to say that I'm thankful for the core devs (even the new one, yay Dion). I think they have a good track record, good intentions, and a lot of combines knowledge. I really appreciate them keeping the project moving.

[Otto]

Two problems with that:

1) That's not how Core Plugins will work. (See below.)

2) If what you wrote are criteria for designation, then what are "Health Check" and "Post By Mail" (or even "PodPress" for that matter) doing as the first-designated Core Plugins? They fail your criteria.

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

No, it certainly doesn't have to be as "formal" as what I've written (though I hardly think what I drafted is so much "formal" as it is merely "written down").

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.

With all due respect, Otto, you are the one who has it all wrong.

The devs have stated quite explicitly - both in the IRC chats and Andrew here in this thread (or perhaps the other one) - that existing plugins will not be designated as "core", but rather, specific functionality will be designated as "core", and the core plugin written - with our without the code contribution of existing plugins.

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.

But that's just it: core plugins won't be starting from an "existing implementation". They will be starting from designated functionality.

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.

[andreasnrb]

Otto why the dislike for the ideas? They are mostly good and hes not the only one who proposes it. Check my links to wp-hackers list for more discussion on the matter.
Core plugins having special UI is already on the table I think. There by separating them from other plugins in the adminbackend.
You are all happy with how things are? No ideas at all for how things can improve?
All I see is negativity upon negativity against others. Its boring. Same thing as with the privacy discussions.
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.

Core plugins won't improve code quality or security or anything in old or new plugins in the directory. It will only cause confusion and users will see core plugins as the only way to go. As seems to be the case already. Better dev docs etc could improve quality since they suck at the moment. Improving WP plugin management could also improve quality and the enduser experience.
The improvement of the directory is a much better step to improve plugins than this weird undefined, without boundaries "core plugin" thing.