Proposal for Core Compnents (Plugins)

[chipbennett]

This thread is intended to be a centralized point for discussion of a community proposal for implementation of WordPress Core Components ("core plugins").

Below is the current state of this proposal:

Background:

Recently, WordPress core developers have promoted the idea of "Core Plugins", which would be, as defined by Jane Wells:

[Core] plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.

This proposal provides an alternative suggestion for these proposed "Core Plugins", that would hopefully address some of the short-comings of that proposal.

Problems with "Core Plugins" Idea:

The implementation of Core Plugins is being pursued without the underlying concept having been completely fleshed out. This rushed implementation is creating confusion among users and third-party developers, and is leading to perhaps unfounded fear and criticism of the proposal.

This Core Components proposal is intended to define fully the underlying concept prior to embarking upon its implementation.



Core Plugins, as proposed, have caused many concerns within the WordPress community. Some of these concerns include:

• Discriminatory Labeling/Sanctioning of Core Plugins
• Disruption of the Plugin Free Market System
• Assuming/Forcing Plugin Developers to Collaborate
• Discouraging Third-Party Plugin Development

Core Components would seek to avoid these issues by focusing on major functionality only, and by designing the Core Components to be fully and inherently extensible, in order to ensure and to facilitate sufficient third-party developer space.

Differences between "Core Components" and "Core Plugins":

Nature

Core Plugins, as proposed, would be plugins, and would exist as part of the current plugin system. Core Plugins would be available through extend/plugins, and would be managed through the Manage Plugins screen.

Core Components would be a separate classification of WordPress extension. Although Core Components would have a separate landing page (e.g. extend\components), Core Components would be generally available and managed through a new, Top-Level Menu Manage Components screen.

Functionality

Core Plugins, as proposed, could address any functionality as determined by the core developers.

Core Components would be intended to address only major functionality (multi-user blogs, social-networking, forums, micro-blogging, podcasting, etc.).

Extensibility

Core Plugins, as proposed, would merely be plugins. As such, they may or may not be developed such that they are themselves extensible.

Core Components would be desinged to be inherently extensible, and provided with APIs to facilitate third-party plugin development.

Purpose of Core Components:

Core Components would be community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. The purpose of Core Components would be to standardize and to consolidate such functionality to the benefit of both the users and the developers of that functionality.





These components would be GPL and live in their own WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these components that ensured that:

• the component code would be secure and the best possible example of coding standards, and
• new versions of WordPress would be tested against these components prior to release to ensure compatibility.

There would be a new Manage Components screen within the WordPress admin to feature these core components. These components would be a true extension of core WordPress in terms of compatibility, security and support.

Definition:





Core Components are defined as follows:

1. Core Components would be managed from a distinct Admin UI page, such as Manage Components, that would provide for installation and configuration.
2. Core Components would address extensible/niche functionality of core, functionality that extends core as a CMS, but that would not be useful to the majority of users. Examples of Core Components include, but are not limited to, Multi-Site component (MU), Social-Networking component (BuddyPress), Forum component (bbPress), Micro-Blogging component (TwitPress), Podcasting component (PodPress).
3. Core Components would themselves be extensible, with well-documented APIs.

Name:

The name "Core Components" is desirable, in order to prevent the confusion and ambiguity created by the name "Core Plugins". Further, the concept of "components" facilitates the promotion of WordPress as a bona fide "Content-Management System" (CMS).

First, the name "core plugin" is internally contradictory, since plugins are by definition an extension, rather than a part, of core.

Second, the functionality and integration of Core Components rise above that of mere plugins. The intent of Core Components is to incorporate some form of significant functionality into WordPress, rather than merely extend existing functionality.

Third, Core Components facilitates the promotion of WordPress as a CMS, since the various cmoponents represent functionality that extends beyond a mere blog platform. WordPress components such as Multi-Site, Social Networking, Forum, Micro-Blogging, and Podcasting present ready-made marketing opportunities for WordPress.

Core Integration:

Core Components would be tightly integrated into core.

Core Components would be managed via a new, top-menu-level Admin screen, such as Manage Components. This screen would allow for enabling/disabling the Core Components, and would contain, either within the main screen or sub-menu screens, the configurable options for each Core Component.

Core Components would be subject to extensive compatibility, security, and usability testing, commensurate with such testing for WordPress core. e.g. Critical bugs against Core Components will be considered as "show-stoppers" for WordPress core version releases.

Extensibility:

Core Components would be fully extensible through the WordPress plugin system, including top quality documentation and APIs.

For some Core Components (e.g. Twitter or OpenID integration), the bulk of the component may itself be the API, to allow for more standardized plugins to be developed.

Plugins that extend Core Components would be hosted in the wordpress.org plugin repository (provided, of course, that such plugins meet the hosting requirements).

Collaboration:

Core Components would be GPL, and would exist in a separate SVN repository hosted by wordpress.org. Core Components would have a separate "landing page" on wordpress.org, such as Extend -> Components, in order to clarify further the distinction between components and plugins.

Core Component project teams would consist of multiple developers, and membership on Core Component project teams would be open-invitation to any developer who chooses to contribute.

(How will Core Component project teams and team leaders be chosen?)

More:

(What else needs to be included?)

Please make comments, suggestions, and constructive criticism. I would like to have something together to present for the dev chat agenda as quickly as reasonable.

EDIT #1:

1. Added "Background" section.
2. Removed statement that Core Components would be installed, but not enabled, by default. Added statement that Core Components would be installed from Manage Components screen.

[Jane]

I'm sorry, but I'm confused. Whose proposal is this? There is a team of volunteers working on a proposal, which will be discussed in the community, as posted on wpdevel.wordpress.com. Discussion will happen there and in the dev chat. It's fine for there to be other discussions elsewhere, but this almost sounds like you want to circumvent the people who have already stepped up to officially lead the charge and create a proposal here instead of participating in the one that is official?

[chipbennett]

I'm sorry, but I'm confused. Whose proposal is this? There is a team of volunteers working on a proposal, which will be discussed in the community, as posted on wpdevel.wordpress.com. Discussion will happen there and in the dev chat. It's fine for there to be other discussions elsewhere, but this almost sounds like you want to circumvent the people who have already stepped up to officially lead the charge and create a proposal here instead of participating in the one that is official?

Jane,

Not trying to circumvent anything, nor do I presume to have the power or ability to circumvent anything. I wasn't aware of an official proposal. In fact, I've not seen anything even remotely resembling the above proposal, anywhere.

If that discussion is taking place elsewhere: where is it? If the entirety of the "core plugin" discussion at wpdevel.wordpress.com is taking place in your Jan 8 thread, then almost none of what is presented in this proposal is being discussed. At all.

I don't understand what you're confused about. This draft proposal is simply an attempt at elaborating on the recommendations of some of us in the WordPress community regarding the "core plugins" idea.

I'm confused about why you would be so confused. After all, you did write this:

At the core team meetup, we identified a bunch of areas where it would be good to have a core plugin, but we’ll also need a process for deciding which areas to create a core plugin for, how to choose the committers for each, etc. If you guys can brainstorm a little around that… you guessed it: write up what you propose and we’ll get community feedback.

Well, here's our first attempt at "writ[ing] up what [we] propose".

Just trying to make a beneficial contribution. As with the privacy policy disclosure, a bunch of us hashed things out here, and *then* took it to the wpdevel dev chat agenda. That's basically what we're looking at doing here.

I've thrown up the framework of how I think the idea should be implemented, but want to get feeback from others before posting on wpdevel.

I would greatly appreciate any substantive feedback you might have on the content!

[mfields]

Chip - I've been following different discussions about the "Canonical/Core" Plugins concept. After skimming through your proposal, I really like the use of the term "Core Component". I've read a few threads regarding the naming... Core, Canonical, etc... All variations we were given seemed to only change the adjective and not the noun. I really like the sound of "Core Component". I also like how your outline implements them... separation in the admin panels and what-not... Nice work.

[Jeffro]

Yeah, I'm with mfields that your proposal looks good even if you jumped the gun :)

I would keep an eye on WordPress Development Updates as that is where you'll find news and updates on proposals and things being worked on regarding the core plugin stuff.

[Ryan]

I'm sorry, but I'm confused. Whose proposal is this? There is a team of volunteers working on a proposal, which will be discussed in the community, as posted on wpdevel.wordpress.com.

I think your reply illustrates Chip's point quite well.

He (and a few others around here) are confused as to what is going on, so are suggesting a proposal to help mould it into something the community wants. Plus, as he pointed out, you requested help with this hence he's chipping in (unintended pun).

I'm kinda on the fence here, I like most of what Chip's suggesting, but it seems like the core devs have made a decision and are rolling with it already so I'm not sure this is going to go anywhere.

[aaroncampbell]

Here's my opinion. Please take it as constructive criticism, that's what it's meant to be. I commented on each section individually and made the specific text I was referencing orange to make it easier to find.

Purpose:

Core Components would be community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. The purpose of Core Components would be to standardize and to consolidate such functionality to the benefit of both the users and the developers of that functionality.

These components would be GPL and live in their own WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these components that ensured that:

• the component code would be secure and the best possible example of coding standards, and
• new versions of WordPress would be tested against these components prior to release to ensure compatibility.

There would be a new Manage Components screen within the WordPress admin to feature these core components. These components would be a true extension of core WordPress in terms of compatibility, security and support.

First, I'd like to say that I have problems with the name "core components" but I'll put that off until the "name" section of your proposal.

I'm also not sure it's really the "most popular functionality requests" that will become core plugins, although I'm not sure that's entirely inaccurate either. It seems like things such as "post by E-Mail" could make a great core plugin (and remove some of the extra code from core) even though it's not one of the "most popular" features.

Additionally, since they will essentially be plugins (and use the plugin system), I don't really see any reason for them to live in a separate WordPress.org repository. It makes sense for them to be featured in some way, but it seems like a lot of wasted effort to set up and keep up another repository that's basically (if not completely) identical to the existing plugins repository.

Lastly, you talked about the UI. I'm not specifically taking issue with your UI ideas (although I'm not completely sold on them yet either), but Jane has said multiple times that the UI will be put to the community as a design challenge:

The UI for core plugins in the admin is going to be a design challenge. I’m starting up a UI mailing list, and we’ll have a handful of UI design challenges for 3.0 to get more UI/UX designers involved as contributors.

When that is brought to the community, you should mock up your design ideas and submit them!

Definition:

Core Components are defined as follows:

1. Core Components would be included in the default download, but not enabled by default.
2. Core Components would be managed from a distinct Admin UI page, such as Manage Components.
3. Core Components would address extensible/niche functionality of core, functionality that extends core as a CMS, but that would not be useful to the majority of users. Examples of Core Components include, but are not limited to, Multi-Site component (MU), Social-Networking component (BuddyPress), Forum component (bbPress), Micro-Blogging component (TwitPress), Podcasting component (PodPress).
4. Core Components would themselves be extensible, with well-documented APIs.

For #1, they are trying to move away from packaging things in the download. Actually, it looks like even Akismet will be removed from the download. Instead they will just be really easy to install from admin. I'm all for this idea because we will end up with a lighter-tighter WordPress download, but all the extra functionality will still be easily available.

As for #2, I just highlighted it again because of the aforementioned design challenge.

Name:

The name "Core Components" is desirable, in order to prevent the confusion and ambiguity created by the name "Core Plugins". Further, the concept of "components" facilitates the promotion of WordPress as a bona fide "Content-Management System" (CMS).

First, the name "core plugin" is internally contradictory, since plugins are by definition an extension, rather than a part, of core.

Second, the functionality and integration of Core Components rise above that of mere plugins. The intent of Core Components is to incorporate some form of significant functionality into WordPress, rather than merely extend existing functionality.

Third, Core Components facilitates the promotion of WordPress as a CMS, since the various cmoponents represent functionality that extends beyond a mere blog platform. WordPress components such as Multi-Site, Social Networking, Forum, Micro-Blogging, and Podcasting present ready-made marketing opportunities for WordPress.

I will agree that "core plugin" is really an oxymoron. Plugin is by definition an extension of core, not a part of core. However, most people do not take "core" to mean the same thing that developers do. You have to remember that this name isn't for developers. The developers will figure it out because they'll be using it regularly. Instead, the name is for the average user (meant to make sense to 80+% of the user base). To them "core" takes more of a dictionary definition such as "a small group of indispensable persons or things" or maybe "the center of an object". Either way, it makes sense. These are indespensible things that are near to the center of WordPress.

As for using "plugin" in the name...well...that's what they are. They are plugins that extend WordPress using it's plugin interface. No matter how the UI shows it, they will still be plugins.

Core Integration:

Core Components would be tightly integrated into core.

Core Components would be managed via a new, top-menu-level Admin screen, such as Manage Components. This screen would allow for enabling/disabling the Core Components, and would contain, either within the main screen or sub-menu screens, the configurable options for each Core Component.

Core Components would be subject to extensive compatibility, security, and usability testing, commensurate with such testing for WordPress core. e.g. Critical bugs against Core Components will be considered as "show-stoppers" for WordPress core version releases.

Again, there's a community challenge for the UI aspect of this. I really think you should participate.

Extensibility:

Core Components would be fully extensible through the WordPress plugin system, including top quality documentation and APIs.

For some Core Components (e.g. Twitter or OpenID integration), the bulk of the component may itself be the API, to allow for more standardized plugins to be developed.

Plugins that extend Core Components would be hosted in the wordpress.org plugin repository (provided, of course, that such plugins meet the hosting requirements).

Just to be fair, developers (including myself) tend to suck at documentation. Much of the documentation for WordPress comes from volunteers who write it as their contribution to WordPress. I think the core plugins will be very similar. I think coding standards that require quality phpdoc and good comments will be normal, but documentation will probably depend on finding people willing and able to write it.

Collaboration:

Core Components would be GPL, and would exist in a separate SVN repository hosted by wordpress.org. Core Components would have a separate "landing page" on wordpress.org, such as Extend -> Components, in order to clarify further the distinction between components and plugins.

Core Component project teams would consist of multiple developers, and membership on Core Component project teams would be open-invitation to any developer who chooses to contribute.

I already mentioned why I don't think there should be a new repository.

As for having a second landing page, I'm not sure that's necessary but I do think they should be clearly highlighted in some way. I'm not saying that having a separate landing page is a bad idea, I'm just saying that I don't think it's the only option there and I'm personally flexible as to how they do it.

Now for the really hard one: the membership. I don't think it should be an open-invitation. If I were to add additional developers to a team that worked on one of my plugins (and I hope to soon), I would want to be quite selective. Why? Because I want to maintain the quality of the code in the plugin. Now if I were a plugin leader for one of these core plugins I would not only want to maintain that high-level of quality, but I would be expected to maintain it. However, I'd like to point out that while you said contributors, in context it seemed like you meant committers. There's a difference, and if you meant contributors (people who can write a patch and attach it to a ticket for review and possible submission by the development team) then I agree that anyone should be able to do that. As for committers, I think that for now the core dev (every core plugin will have a core dev for now) will choose who has access. Westi is doing that for the Health Check plugin right now. Eventually I think it should be the "plugin leader" but that the plugin leader doesn't necessarily need to be a core dev. They just need to be trusted and have proved themselves capable.

If that discussion is taking place elsewhere: where is it? If the entirety of the "core plugin" discussion at wpdevel.wordpress.com is taking place in your Jan 8 thread, then almost none of what is presented in this proposal is being discussed. At all.

The Jan 8 post mentioned a group of people that would be halping with various projects and posting updates to wpdevel on a weekly basis. Our group posted an update today (the post mentioned that we'd be doing Monday updates), which includes an IRC channel. Most of the discussion has happened by E-Mail between that group of people or in that IRC channel (#wordpress-core-plugins on Freenode).

I'm confused about why you would be so confused. After all, you did write this

Hopefully it wasn't meant this way, but that came off very rude. Jane puts a lot of work into WordPress and the WordPress community, so when something like this comes along I think she deserves the benefit of the doubt rather than a sassy reply.

[aaroncampbell]

I think your reply illustrates Chip's point quite well.

He (and a few others around here) are confused as to what is going on, so are suggesting a proposal to help mould it into something the community wants. Plus, as he pointed out, you requested help with this hence he's chipping in (unintended pun).

I'm kinda on the fence here, I like most of what Chip's suggesting, but it seems like the core devs have made a decision and are rolling with it already so I'm not sure this is going to go anywhere.

Sorry Ryan, I didn't ignore your post, it must have been posted while I was writing my reply.

If you look at the post he's referencing that quote from, and go all the way to the bottom, you'll see "For the sake of transparency, I’ll also post this email on wpdevel so people know what you’re tasked with doing." That entire grey quote box is the E-Mail that was sent to our group to get us started on outlining what was needed for core plugins. That means that "If you guys can brainstorm a little around that… you guessed it: write up what you propose and we’ll get community feedback" was written to us.

I agree that it could have been more clear that the large quote was an E-Mail sent to the team. However, I think if you read the entire post it does make sense. The misunderstanding explains the confusion though.

[Ryan]

To be honest, I'm basing some of my comments in here on what I've read from others, so it's entirely possible I've screwed a few things up by not checking my sources properly.

I'm 100% certain Chip isn't trying to be rude though, he just has an abrupt way of wording things.

[chipbennett]

Here's my opinion. Please take it as constructive criticism, that's what it's meant to be.

Excellent! That's exactly what I'm looking for.

Also, perhaps it wasn't clear enough (I should probably address that, with a "Background" section, or something), but I am intentionally proposing something slightly/significantly different from what has been proposed so far.

I'm not so much trying to express an exact description of what has been proposed; rather, I am trying to express something different (and, hopefully, better).

I commented on each section individually and made the specific text I was referencing orange to make it easier to find.



First, I'd like to say that I have problems with the name "core components" but I'll put that off until the "name" section of your proposal.

I'm also not sure it's really the "most popular functionality requests" that will become core plugins, although I'm not sure that's entirely inaccurate either. It seems like things such as "post by E-Mail" could make a great core plugin (and remove some of the extra code from core) even though it's not one of the "most popular" features.

That wording is actually from Jane herself. :)

Basically, I took her original description of the (then) "canonical plugins", and modified it to suit what I'm proposing here.

Additionally, since they will essentially be plugins (and use the plugin system), I don't really see any reason for them to live in a separate WordPress.org repository. It makes sense for them to be featured in some way, but it seems like a lot of wasted effort to set up and keep up another repository that's basically (if not completely) identical to the existing plugins repository.

Perhaps, on the back end, you're right.

But, my thinking is that, because "Core Components" aren't merely well-supported plugins but rather tightly integrated functionality extensions, they should be treated separately from plugins on both the front-end and the back-end.

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.

Lastly, you talked about the UI. I'm not specifically taking issue with your UI ideas (although I'm not completely sold on them yet either), but Jane has said multiple times that the UI will be put to the community as a design challenge:

When that is brought to the community, you should mock up your design ideas and submit them!

That might be beyond my abilities. :) But, I can try!

For #1, they are trying to move away from packaging things in the download. Actually, it looks like even Akismet will be removed from the download. Instead they will just be really easy to install from admin. I'm all for this idea because we will end up with a lighter-tighter WordPress download, but all the extra functionality will still be easily available.

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

Although, given the ease of installing from within the WordPress Admin UI, I could see an argument for having "Install" links on the Manage Components screen.

As for #2, I just highlighted it again because of the aforementioned design challenge.

I will agree that "core plugin" is really an oxymoron. Plugin is by definition an extension of core, not a part of core. However, most people do not take "core" to mean the same thing that developers do. You have to remember that this name isn't for developers. The developers will figure it out because they'll be using it regularly. Instead, the name is for the average user (meant to make sense to 80+% of the user base). To them "core" takes more of a dictionary definition such as "a small group of indispensable persons or things" or maybe "the center of an object". Either way, it makes sense. These are indespensible things that are near to the center of WordPress.

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.

As for using "plugin" in the name...well...that's what they are. They are plugins that extend WordPress using it's plugin interface. No matter how the UI shows it, they will still be plugins.

Again, this idea is something slightly different. Granted, how "Core Components" would hook into WordPress would be, essentially if not entirely, the same as mere plugins. But they are intended to be differentiated.

Again, there's a community challenge for the UI aspect of this. I really think you should participate.

Just to be fair, developers (including myself) tend to suck at documentation. Much of the documentation for WordPress comes from volunteers who write it as their contribution to WordPress. I think the core plugins will be very similar. I think coding standards that require quality phpdoc and good comments will be normal, but documentation will probably depend on finding people willing and able to write it.

Agreed - and documentation is one area that I've considered getting involved in. I just want it to be clear that, because they are intended to be extensible, Core Components need to be well-documented in order to facilitate plugin development.

I already mentioned why I don't think there should be a new repository.

As for having a second landing page, I'm not sure that's necessary but I do think they should be clearly highlighted in some way. I'm not saying that having a separate landing page is a bad idea, I'm just saying that I don't think it's the only option there and I'm personally flexible as to how they do it.

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.

I think such functionality warrants its own landing page, if for no other reason than to use such a page for promotion of such major functionality.

Now for the really hard one: the membership. I don't think it should be an open-invitation. If I were to add additional developers to a team that worked on one of my plugins (and I hope to soon), I would want to be quite selective.

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

Why? Because I want to maintain the quality of the code in the plugin. Now if I were a plugin leader for one of these core plugins I would not only want to maintain that high-level of quality, but I would be expected to maintain it. However, I'd like to point out that while you said contributors, in context it seemed like you meant committers. There's a difference, and if you meant contributors (people who can write a patch and attach it to a ticket for review and possible submission by the development team) then I agree that anyone should be able to do that. As for committers, I think that for now the core dev (every core plugin will have a core dev for now) will choose who has access. Westi is doing that for the Health Check plugin right now. Eventually I think it should be the "plugin leader" but that the plugin leader doesn't necessarily need to be a core dev. They just need to be trusted and have proved themselves capable.

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.

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"?

The Jan 8 post mentioned a group of people that would be halping with various projects and posting updates to wpdevel on a weekly basis. Our group posted an update today (the post mentioned that we'd be doing Monday updates), which includes an IRC channel. Most of the discussion has happened by E-Mail between that group of people or in that IRC channel (#wordpress-core-plugins on Freenode).

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

Hopefully it wasn't meant this way, but that came off very rude. Jane puts a lot of work into WordPress and the WordPress community, so when something like this comes along I think she deserves the benefit of the doubt rather than a sassy reply.

I re-worded my response a couple of times, in order to ensure I wasn't being rude or snarky - because, quite honestly, I was pretty miffed when I read her reply. I think that there was no reasonable justification for assuming that I was trying to "circumvent" some process - a process that, with all due respect, has been, up to this point, not at all out in the open.

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.

All that to say: I think I, too - and, really, everyone in the WordPress community - deserve the benefit of the doubt rather than a sassy reply.

Which, coincidently, is why I do greatly appreciate your time and effort in making such a thorough reply.