Proposal for Core Compnents (Plugins)

[chipbennett]

Themes are actually slightly different. So they do need to have a separate UI.

But, didn't you just say earlier that plugins and themes are the same?

You always need to have a theme loaded, whereas you don't need to have any plugins loaded.

Actually, I guess you could have no theme loading, but then you would just get a blank page (or an error probably).

Yes, and if "blogging" were made into a Core Component also (which I've also thrown out as a suggestion elsewhere), then you could also say that you always need to have a Core Component loaded.

What do you think needs changed?

I'm not sure I can exactly put my finger on it. Maybe it's style changes; maybe layout? I'm just not sure.

But how do you define the difference between something which is major and something which is not? What happens when it's on the border-line? At the moment it's pretty clear. Themes are themes. Plugins are plugins. Plugins can unhook large chunks of themes (the whole thing in some cases), but they're still modifying the theme as opposed to actually being the theme. Your components wouldn't be any different from a plugin at all. They're literally the same thing.

Those are good questions to ask. I would add that the analogous questions need to be asked by the core devs regarding Core Plugins, as well: what functionality is eligible for consideration for being developed as a Core Plugin?

At least I'm making a start, in referring to "major functionality". If that definition needs more clarification, let's add it!

Where do you think the line should be?

I think all of the following should be considered:

MU
BuddyPress
bbPress
PodPress
Twitter (micro-blogging) integration
OpenID

I think the following should probably not be considered:

HealthCheck
PostByEmail

To be more specific, I think functionality such as Twitter and OpenID should mostly be a standardized API, that would allow for other plugins - while the others should be full-blown functionality.

So, where does that establish the "line"?

[chipbennett]

This debate looks like it's turning into one of those really long topics we seem to have popping up here on the Tavern so often.

Perhaps we should spice it up a bit by bringing the GPL into it?

Maybe we should roll Thesis into core?

tongue firmly in cheek

I don't think that would be ethical.

/deadpan

[Ryan]

For your proposal, HealthCheck and PostByEmail would be bad. For the "core plugins" idea, I'd say they are quite suitable since they're fairly simple, yet commonly used or highly useful features.

[Ryan]

But, didn't you just say earlier that plugins and themes are the same?

I haven't checked, but I think I said "basically the same", which isn't quite the same as "the same" :p I was just meaning that a theme can do anything a plugin can do.

Yes, and if "blogging" were made into a Core Component also (which I've also thrown out as a suggestion elsewhere), then you could also say that you always need to have a Core Component loaded.

Andrew Rickmann suggested having pages in core and posts (ie: blog functionality) as a plugin. So you could actually do that I guess.

[chipbennett]

For your proposal, HealthCheck and PostByEmail would be bad. For the "core plugins" idea, I'd say they are quite suitable since they're fairly simple, yet commonly used or highly useful features.

But then, shouldn't "commonly used" and "highly useful" - not to mention, "fairly simple" - all be arguments for integration into core?

Does PostByMail really meet those criteria? If it did, would it be in the shape that it is, currently?

Likewise with HealthCheck.

Besides, my proposal is an alternative to Core Plugins, not an addition.

[aaroncampbell]

Wow, I wrote the response below, and then checked to see if there were any new posts. It seems there are two new pages of posts, so I'm just going to post this and then go read them.

I've only recently learned how (marginally) to use SVN, so I'm not terribly knowledgeable in that regard. I was thinking that a separate repo might be able to be set up in a way that would better facilitate collaboration.

As someone that's used SVN for years, and been a collaborative developer for years, I'll suggest that the current SVN is fine. There are additional tools needed to better facilitate collaboration (such as mailing lists, trac, etc) that the SVN should integrate with once they're up and running, but the current SVN is fine.

Again, this suggestion goes back to this "Core Components" idea being different from the current "Core Plugins" idea.

Think of this suggestion as being analogous to MU being integrated into core, but requiring a wp-config flag in order to enable it. It's not considered to be making WordPress any less "lighter-tighter" (at least, not that I've heard).

I'm just trying to suggest that (in my opinion) changing the name will get your ideas dismissed rather quickly. The name, "core plugins" has already been decided on (again, this was both by popular vote in a poll as well as being the consensus of the developer meeting, both of which were completely open for anyone to vote/participate). Trying to change it now will feel contrarian not helpful.

The MU merge gives us other advantages (such as not having a whole second distribution that is being maintained basically by one person), but it is adding code and complexity to core (definitely not lighter-tighter).

I think it is short-sighted (at best - condescending at worst) to believe that the name won't lead to confusion for the average user. It reeks of being a name that was quickly chosen, and run with, without any sort of vetting.

Well, it was discussed in dev chat (at least a couple times), then made into a poll where "core plugins" won, it was discussed on the wp-hackers mailing list, and then it was discussed again at another dev chat. In my opinion that's a reasonable amount of vetting, but if you think there should have been more, I'm sure you're not alone and you're entitled to your opinion. I personally think that much less would happen if things like this were discussed until everyone was happy (and actually, I think a lot of great things, like the new admin UI, would have never happened).

Again, "Core Components" aren't mere plugins. This proposal considers them to be major functionality that is tightly integrated with WordPress core: MU, BuddyPress, bbPress, Micro-Blogging, OpenID, etc.

MU doesn't work as a plugin, it needs to be part of core. However, all those others are either already plugins or will soon become plugins (some, like Micro-Blogging are covered by quite a few plugins). Buddy Press is pretty impressive, but I don't see it being any more major than Gravity Forms or Shopp or wp-ecommerce. It's a very nice, rather large, pretty complex plugin. But it's still a plugin.

Well, then - such sentiment appears to be entirely contradictory to what developers are being told currently ("if your plugin becomes a core plugin, just get involved with the core plugin team and continue to contribute").

Coming from the core dev team, y'all are going to have to be very careful how you word such sentiments, or they can (and will) be taken the wrong way.

Already, you have validated the concen of those developers who are saying, "well, I can contribute patches, but who is to say that they'll be accepted?".

They can certainly contribute, either by getting accepted to actually commit to the plugin, or by offering patches. And yes, their patches could be turned down. However, there are only a handful of reasons to turn down a patch. The two major ones are that it's bad (insecure, etc), or that it doesn't take the project closer to it's ultimate goal. If it's the second, then just keep doing your own plugin, the core plugin isn't covering the same ground you are.

Actually, by "contributors", I meant exactly that: contributors. I pretty much assumed that, since core devs would be leading the project teams, the core-dev team leader would be the one with commit access.

There will be multiple committers. I think the Health check plugin already has about 6 developers with commit access (I'm one of them).

I think this somewhat illustrates my point above, about devs assuming what users think, intend, or understand. If you misunderstood my use of "contributors", why should I not think that users will be confused by the use of "core plugins"?

I'm sorry, but I see a problem with that logic "since you misunderstood a word, other people might misunderstand a different word". While people might misunderstand it, the fact that I (not a member of the "other group") misunderstood a completely different word, has no bearing on that.

Well then, I guess it's about time I figured out how to use IRC. :)

Lots of open source projects use IRC for their meetings, support, etc. As a matter of fact, that's what Freenode (a major IRC network) is intended for for.

I'm making a sincere effort to contribute something to the idea and its implementation, and get accused of trying to circumvent the process - by one of the people from whom I genuinely wanted feedback, no less.

From my side (and probably from her's as well, but I won't speak for her), it feels like you're walking into a business meeting that we're just wrapping up, and trying to get us to throw out all the decisions that were made just because you weren't there. It doesn't seem fair to all the people that were there.

The reaction would seem to justify the opinion of some that user-community input isn't really wanted or welcome.

That's not the case, you're just jumping the gun a little. The community will be able to offer input on our proposal as soon as we're done with it.

Users are confused about what they are, how they will work, and how they will be different from normal plugins.
Plugin developers are concerned that the way Core Plugins will be implemented will stifle competition and have an adverse impact on their livelihood

I think that should be written:
A small percentage of users are confused about what they are, how they will work, and how they will be different from normal plugins.
Some plugin developers are concerned that the way Core Plugins will be implemented will stifle competition and have an adverse impact on their livelihood.

Only a (relatively small) percentage of users even know about core plugins yet, because they're not in WordPress yet. Only a percentage of those that know are confused about it. As for plugin developers, I *am* a plugin developer, and I'm not concerned. There are plenty of other unconcerned plugin developers that have been a part of the process, so if some are concerned...it's only some.

The entire process surrounding Core Plugins, from inception, to definition, to implementation, has been closed.

Just because you didn't participate doesn't make it closed. The developer chats, mailing lists, etc are all public and everyone is welcome to join.

From Aaron's post on wpdevel:

Please remember though that we aren’t discussing what core plugins should be called, whether or not they’re a good idea, how plugins will become core plugins, or whether my mom’s a core plugin.

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.

And from the IRC logs:

Jeffro darn, I probably missed the conversation around the 'free market' arguments.
<A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m347">filosofo Jeffro, no it hasn't come up here
<A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m349">PeteMall Jeffro: thats beyond the scope
<A href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2010-01-11#m351">AaronCampbell Jeffro: that's not really for here

The free-market arguments are for whether or not core plugins are a good idea. It has already been decided (in the aforementioned discussions) that core plugins are happening, thus that was not the time or place to discuss it.

So, where is this "open" discussion? Where are user (and third-party developer) concerns being discussed, considered, and addressed?

The real problem (I think) is that these were already discussed and addressed, but you (and a few other people) missed it. It's not fair to claim that it didn't happen just because you weren't there.

Ryan Chip is proposing something totally different than what the black box has decided.

I guess I'm part of that "black box" because I attended public meetings and read public blogs and mailing lists.

[Ryan]

I guess I'm part of that "black box" because I attended public meetings and read public blogs and mailing lists.

I think it might have been me who started the "black box" phrase here. I was surprised to start hearing about core plugins being introduced when I hadn't heard anything about the name being confirmed or much at all about it.

It might be a good idea if decisions are made, then announced via WP Devel or something like that. It's a bit confusing when people start talking about something and despite having kept an eye on everything except for live chat I have no idea that a decision has been made. Either that or I just missed the announcement somewhere, in which case just ignore me :p


Perhaps we should include phpBB in core?

tongue back in cheek

[andreasnrb]

It was me who started with the black box. Ive tried to go back and check wpdevel, chat, wp-hackers.
Some discussions seems to have taken place at Wordcamp NYC.
For wp-hackers I find two threads.
"Some leftfield names for canonical plugins". http://groups.google.com/group/wp-ha...bca0e6d52bac?#
Also: http://groups.google.com/group/wp-ha...lugins&lnk=nl&
Wp-devel: http://wpdevel.wordpress.com/2009/12/08/450/
There seems to be no consensus that it should be done the way that its done now.

IRC Log Wp dev
28 references to core plugins.
1 Jul 18 2009,
1 AUg 18 2009,
Majority of the discussion seems to have taken place Dec 10 2009. Then some Jan 7 and 8 2010.
Even less for canonical plugins 13 references.
1 Jun 12
1 Jul 8
1 Jul 11
1 Aug 13
1 Sept 10
Then it goes up Dec 10 to 6 mentions
Only two three mentions in WordPress.

[chipbennett]

Wow, I wrote the response below, and then checked to see if there were any new posts. It seems there are two new pages of posts, so I'm just going to post this and then go read them.



As someone that's used SVN for years, and been a collaborative developer for years, I'll suggest that the current SVN is fine. There are additional tools needed to better facilitate collaboration (such as mailing lists, trac, etc) that the SVN should integrate with once they're up and running, but the current SVN is fine.



I'm just trying to suggest that (in my opinion) changing the name will get your ideas dismissed rather quickly. The name, "core plugins" has already been decided on (again, this was both by popular vote in a poll as well as being the consensus of the developer meeting, both of which were completely open for anyone to vote/participate). Trying to change it now will feel contrarian not helpful.

The name issue is really secondary IMO. Yeah, I think a more appropriate name could have been chosen, and I think relying on that poll too much is misguided ( a) it's an internet poll, b) it's too small of a sample size ).

But, ultimately, I'm more concerned with the whole decision-making process. Reading through the IRC logs, I get an alarming sense of, "Hey! We've got this great idea! We don't really know exactly what we're going to do with it yet, but, hey - let's just start doing something and see how it all works out."

That's NOT a recipe for success.

If you think that my suggestions here would get more consideration if I dropped the issue of the name, then so be it. I can modify the proposal.

I'd like to know what others think, though. I've heard several people who have indicated that they like the "Core Components" terminology.

The MU merge gives us other advantages (such as not having a whole second distribution that is being maintained basically by one person), but it is adding code and complexity to core (definitely not lighter-tighter).

And lighter/tighter isn't always better.

Heck, look at bbPress. Personally, I like that it is so light-and-tight. But one of the most oft-repeated criticisms is that too much functionality is missing, and has to be included with plugins.

Well, it was discussed in dev chat (at least a couple times), then made into a poll where "core plugins" won, it was discussed on the wp-hackers mailing list, and then it was discussed again at another dev chat. In my opinion that's a reasonable amount of vetting, but if you think there should have been more, I'm sure you're not alone and you're entitled to your opinion. I personally think that much less would happen if things like this were discussed until everyone was happy (and actually, I think a lot of great things, like the new admin UI, would have never happened).

Perhaps one of the issues here is what the developer community considers to be an open discussion, versus what the user community considers to be an open discussion.

Jeff is probably one of the most-connected members of the user community, keeping track of the dev chats and other IRC logs (and wp-hackers?) - but I think even he isn't completely confident that he understands Core Plugins.

Regardless, the resources you mentioned are invisible to most users. Most users are going to respond to things like blog posts, forum threads, etc. - not dev chats and the wp-hackers email list.

So, when I say that the conceptualization process for Core Plugins wasn't "open", I mean that it wasn't open with respect to the user community. It wasn't presented in a way that facilitated the involvement and input from the user community.

What I mean by "vetted" is not several dev conversations and a single internet poll guaging various "X Plugins" terms, but rather, putting the term to the test in some sort of user/usability testing.

But then, better yet: don't worry about the name, until the concept itself is hammered out and finalized. Once you know exactly how the concept will work, the name would likely more readily present itself.

MU doesn't work as a plugin, it needs to be part of core. However, all those others are either already plugins or will soon become plugins (some, like Micro-Blogging are covered by quite a few plugins). Buddy Press is pretty impressive, but I don't see it being any more major than Gravity Forms or Shopp or wp-ecommerce. It's a very nice, rather large, pretty complex plugin. But it's still a plugin.



They can certainly contribute, either by getting accepted to actually commit to the plugin, or by offering patches. And yes, their patches could be turned down. However, there are only a handful of reasons to turn down a patch. The two major ones are that it's bad (insecure, etc), or that it doesn't take the project closer to it's ultimate goal. If it's the second, then just keep doing your own plugin, the core plugin isn't covering the same ground you are.




There will be multiple committers. I think the Health check plugin already has about 6 developers with commit access (I'm one of them).



I'm sorry, but I see a problem with that logic "since you misunderstood a word, other people might misunderstand a different word". While people might misunderstand it, the fact that I (not a member of the "other group") misunderstood a completely different word, has no bearing on that.

It's not an isolated incident - either within WordPress or unique to WordPress. Developers mistakenly believe that they understand the user community with respect to some issue or another, and that mistaken belief leads to false assumptions and sometimes condesension.

Lots of open source projects use IRC for their meetings, support, etc. As a matter of fact, that's what Freenode (a major IRC network) is intended for for.

I know, I know :) I've not gotten around to taking it for a spin. Heck, KDE even has a native IRC client, that I've never used.

From my side (and probably from her's as well, but I won't speak for her), it feels like you're walking into a business meeting that we're just wrapping up, and trying to get us to throw out all the decisions that were made just because you weren't there. It doesn't seem fair to all the people that were there.

Here's the problem with that thinking: from my perspective, that "business meeting" went mostly like what I read in the IRC logs: "Here's a great idea! Awesome! Let's call it... Core Plugins! Done. How's it going to work? I don't really know... but let's get started!"

Do I like the name? No.

Am I going to fall on my sword over the name? No.

Take the issue of the name away, and what are the differences between what I've proposed and what we already know about Core Plugins?

The scope.

As far as I can tell, that's it. I'm proposing that Core Plugins focus on major functionality, as opposed to... well, whatever is decided to be made into a core plugin.

Documentation, APIs, and extensibility? That fits with the current idea.

UI? That's not been determined yet, so could fit with the current idea.

Collaboration? Looks like we're on the same page there, as well.

That's not the case, you're just jumping the gun a little. The community will be able to offer input on our proposal as soon as we're done with it.

But see, there's the problem: the proposal isn't even finished, and we're already full-steam ahead on the first three Core Plugins.

It's really easy to see how some might interpret that as, "Core Plugins are coming. We can't tell you exactly what that means, but if you don't like it, tough."

If the "business meeting" is "wrapping up", where's the proposal?

And, if the plan is already being implemented, and user-community input is already not being well-received, what does it really mean to say "the community will be able to offer input on our proposal as soon as we're done with it"?

That input isn't going to change anything, because the idea is already being implemented.

It would appear that such user-community input is going to be limited to Core Plugin UI. Such input solicitation will be appreciated, and I'll try to contribute my ideas - but where was the input solicitation on the concept itself?

Perhaps more importantly, where was the input solicitation on the concept from the third-party plugin developers?

I think that should be written:
A small percentage of users are confused about what they are, how they will work, and how they will be different from normal plugins.
Some plugin developers are concerned that the way Core Plugins will be implemented will stifle competition and have an adverse impact on their livelihood.

Only a (relatively small) percentage of users even know about core plugins yet, because they're not in WordPress yet. Only a percentage of those that know are confused about it. As for plugin developers, I *am* a plugin developer, and I'm not concerned. There are plenty of other unconcerned plugin developers that have been a part of the process, so if some are concerned...it's only some.

Obviously, it's only some. I didn't intend to imply otherwise.

But, do the core devs have any idea of the magnitude of those some developers who are concerned? Are some a large sum, or a small sum?

Just because you didn't participate doesn't make it closed. The developer chats, mailing lists, etc are all public and everyone is welcome to join.

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.

Again, those are tools mainly for core developers. wp-hackers may have perhaps brought in a few more third-party developers. None would bring in any ordinary users.

The free-market arguments are for whether or not core plugins are a good idea. It has already been decided (in the aforementioned discussions) that core plugins are happening, thus that was not the time or place to discuss it.

And where were users and/or third-party plugin developers involved in that decision-making process?

The real problem (I think) is that these were already discussed and addressed, but you (and a few other people) missed it. It's not fair to claim that it didn't happen just because you weren't there.

The discussion took place within the core dev community - not with the involvement of the user community or the third-party developer community.

I think it is unfair to quantify those not involved in that decision-making process as "a few" - those "few" include everyone who is not a core dev.

I guess I'm part of that "black box" because I attended public meetings and read public blogs and mailing lists.

...not really in the scope of our conversation.

[chipbennett]

It was me who started with the black box. Ive tried to go back and check wpdevel, chat, wp-hackers.
Some discussions seems to have taken place at Wordcamp NYC.
For wp-hackers I find two threads.
"Some leftfield names for canonical plugins". http://groups.google.com/group/wp-ha...bca0e6d52bac?#
Also: http://groups.google.com/group/wp-ha...lugins&lnk=nl&
Wp-devel: http://wpdevel.wordpress.com/2009/12/08/450/
There seems to be no consensus that it should be done the way that its done now.

IRC Log Wp dev
28 references to core plugins.
1 Jul 18 2009,
1 AUg 18 2009,
Majority of the discussion seems to have taken place Dec 10 2009. Then some Jan 7 and 8 2010.
Even less for canonical plugins 13 references.
1 Jun 12
1 Jul 8
1 Jul 11
1 Aug 13
1 Sept 10
Then it goes up Dec 10 to 6 mentions
Only two three mentions in WordPress.

Thanks for doing that; saved me the trouble!

And, interesting wp-hackers read.