Making preparations for 3.8

As mentioned previously, 3.8 development officially opens shortly after 3.7 ships. With the first beta of 3.7 behind us and the final release scheduled for mid-October, it’s time to talk about what’s expected of feature plugins.

@nacin mentioned at last week’s dev chat that 3.7 will likely branch at the WordCamp Europe contributor day, on October 7. At this point, most coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developer focus will be on shipping 3.7. However, feature plugins that want to be considered for 3.8 should be ready by October 14 to give everyone time to review them.

What does being ready mean? Here’s what will be examined:

  • a strong and well-tested user experience
  • fully-baked design
  • positive feedback from the community
  • core-quality code
  • no major bugs or issues
  • a belief that the feature belongs in WordPress core

Some of the above is subjective and will vary from feature to feature. If you have questions, look to a lead developer for guidance.

Of the feature plugins listed, the furthest along are MP6 and global admin search, with Dash not far behind. Plugins in the “feedback” stage should be prepared to answer the question “Why should we include this in core?” As of today, they should prepare their code for core, removing anything unnecessary and making the feature into a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. that can be easily merged with core.

tl;dr

  • Feature plugins wanting consideration for 3.8 should be ready for presentation and inclusion by October 14.
  • Feature plugins will undergo review shortly after 3.7 ships.
  • Plugins must be ready to merge when the merge window opens.

#3-8, #core-plugins

Features, Plugins, and WordPress 3.8

At the dev chat last week, we talked a bit about WordPress 3.8 and the features-as-plugins process. Here’s a recap of what was discussed:

Expectations

A lot of features are in development right now, at varying stages. Given the huge list of new features, there’s no way they’ll all be in WordPress 3.8. That’s okay, and it’s by design.

The features-as-plugins model makes it easy to wait for a feature to be ready before including it in a release. It also allows for a lot of experimentation. Some ideas might not otherwise be developed into potential features, while others are large and complex, and might take multiple cycles to complete. But experimentation can lead to a fully scoped or even fully developed feature that never makes it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. because, after hashing out the details, it’s realized it isn’t something that belongs in core. Don’t let that discourage you — trial and error is part of the process and will result in better features and a better WordPress. Features that don’t get included in core can continue to live on as awesome plugins, and the whole ecosystem benefits. In the past, the core team would have suggested that a feature start as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party anyway; this formalizes that process.

Ultimately, the decision on whether a feature makes it into core rests in the hands of the core team. To ensure you’re on the right track, keep in contact with the next release’s lead and the lead developers. The release leadRelease Lead The community member ultimately responsible for the Release. should understand what problem you’re trying to solve and why the direction you chose is the appropriate one to solve that problem.

Timeline

For features to be included in a release, they must be ready for the release’s first meeting — that is, day one when the development period begins. At that point, the release lead will review current projects, and along with core developers, determine if they’re fully baked and ready for merging into core.

They’ll be looking for a number of things, including a strong and well-tested user experience, fully-baked design, positive feedback from the community, core-quality code, no major bugs or issues, and a belief that the feature belongs in WordPress core. Every feature is different, so “ready” will mean different things depending on the specific feature, but a release lead must feel comfortable taking on primary responsibility for a feature and the core team must be comfortable taking on responsibility for the long term.

If the core developers decide a feature isn’t ready for core, they’ll let the feature lead know why and what can be done to prepare the feature for a future release.

Features that have been approved for inclusion will have a merge window of about two weeks (timeline still being decided) to get their code into core and wrestle with any latent issues getting it merged. However, as stated above, features must be ready for merging at the start of the merge window.

Who’s responsible for features?

After a feature gets merged into core, the feature team remains responsible for the feature, with added support from the core team. As with any part of WordPress, feedback comes from the entire community. However, after merging into core, a feature will receive a lot more visibility than in the plugin phase. Focus is important to ensure the feature ships.

Keep in mind that while the team remains responsible for the feature in core, ultimate decision-making rests in the hands of the core team, as with any part of core. The release lead will obviously work closely with the feature lead and entire team.

tl;dr

  • Sometimes features won’t end up in core. That’s okay! Not everything belongs in core. It’d still be a great, community-built plugin that helps to improve the ecosystem. Maybe it serves as a prototype, or lessons learned, or even a base for a future initiative.
  • Don’t expect your feature to make it for 3.8. These are features being built with the potential for inclusion in a future version of WordPress. They are not “3.8 features.”
  • To be included in 3.8, features must be “ready,” as defined by the core team, at the start of 3.8 development, shortly after 3.7. Be sure to keep in close contact with the release lead.

Questions? Comments? Ask away!

#3-8, #core-plugins

Featured Content Office Hours

As my last task as acting lead for Featured Content, I’m happy to announce our first IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. chat on Monday, 1700 UTC in #wordpress-dev, led by @wonderboymusic.

We will talk about the project organization and intended functionality for the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (on a high level!). Goal of the meeting is that everyone has a clear understanding of where the project is headed, what the next step in the process will be, and who is working on that.

#3-8, #core-plugins, #featured-content

Present your 3.8 feature idea at tomorrow’s meeting

Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

  • What problem(s) are you trying to solve?
  • What proposal solution(s) are you interested in exploring?
  • When and where is your group communicating?
  • Who has joined your group so far?
  • If you’ve selected someone to lead your group, who is your lead?
  • If you’ve already started work on your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, bring a link to your plugin page.

See you tomorrow!

#3-8, #agenda, #core-plugins

Core Plugin Infrastructure Update

Just a quick update on where we stand with the infrastructure for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party development. The mailing lists are currently being used and it looks like they should be able to scale fine.

We still need a patch or plugin for Trac (https://core.trac.wordpress.org/ticket/11898) to help it handle the sheer number of plugins currently in the repository (not to mention the expected future growth). If anyone is able to help with that, please post on that ticket.

The next steps will be to rework the current layout of the plugin pages on wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Currently there’s a link on the adminadmin (and super admin) tab to that plugin’s Revision Log as well as the RSS feedRSS Feed RSS is an acronym for Real Simple Syndication which is a type of web feed which allows users to access updates to online content in a standardized, computer-readable format. This is the feed. for that log. That needs to be moved some place where regular users can see it. Additionally the plan is to add a way for plugin authors to request a mailing list for their plugin directly from the wordpress.org repository.

I’m excited to see all this fall into place so that we can turn the corner and see how core plugins will really shape up!

#core-plugins

Core Plugin Infrastructure

As many of you know, last Thursday’s dev chat resulted in a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. plugins research team team (for lack of a better term). Basically, our job is to try to come up with a list of tools that should be supplied for all core plugins, in order to allow teams of developers to be effective and efficient. It’s only been a few days so far, but we wanted to update everyone on our progress.

First, we started a new IRC channel on freenode to discuss core plugins. If you’re interested in offering suggestions or ideas, share them in #wordpress-core-plugins. The channel is logged at https://irclogs.wordpress.org/ as well, so feel free to put your ideas there even if no one is presently chatting. I’m sure a few of us will look at the logs (I know I do).

We also started discussing the infrastructure that is needed. It seems that plugins already have a good SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. system in place, which is great. Additionally we think core pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party teams need tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (which we already have, but it needs some work), and mailing lists. The way we see it, core plugins should have most of the tools available to WordPress core developers, since they’ll be doing the same basic thing on a smaller scale.

There’s still a lot to do, including coming up with suggestions on how core plugins should be developed, how developers will be added to or removed from a core plugin team, figuring out if any of the tools or processes would benefit all plugins (not just core plugins), etc. We’d love to get more input on these areas, either here or in #wordpress-core-plugins. 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. We’re just trying to come up with a set of tools that would help the developers, and some basic best-practices for plugin development and team building.

#core-plugins

In yesterday’s dev chat, a number of peo…

In yesterday’s dev chat, a number of people volunteered to help with projects for 3.0. We agreed that each team will post weekly updates here on wpdevelwpdevel Formerly the development updates P2 blog at wpdevel.wordpress.com. It is now make/core and resides at make.wordpress.org/core. so that the community can keep up with the progress and weigh in on decisions as they come up. The first one up is the team of AaronCampbell, filosofo, Strider72 and PeteMall. They’ll be working with westi on figuring out the infrastructure and processes around the introduction of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. plugins. For the sake of transparency, below is the email I sent them to outline the scope of the project. If anyone has suggestions for the team to take under consideration, catch them in IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. at #wordpress-dev, or better yet, leave comments on their Monday posts here on wpdevel.

Hi guys. Thanks for volunteering to help get the core plugins system/infrastructure figured out. As you probably guessed, Peter is the lead developer taking point on this, but we thought it would be good to have a volunteer team to help move it forward.

At the core team meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area., we agreed that for core plugins to be successful as team development projects, they would need basically everything WordPress has: TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., mailing list, support forums, etc. We also need to make it easier for there to be a multi-committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. project. Peter has thought through a lot of these things, so hopefully you guys can chat and come to some agreement on what would be the most useful setup.

Once you agree on what we need to have in place for core pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party teams to start testing out the structure, if someone could write up what you propose we do, we can get some community feedback on it, and then pull in Barry to actually set up whatever we need systems-wise.

Aaron brought up a question this morning in IRC: what if a committer starts doing things that are not good for the core plugin? Part of your task is to propose the process by which such a person’s acts would be reviewed and dealt with. My instinct is for the other committers to bring it to the lead devs, and for the lead devs to remove commit privileges if someone is making bad commits. But again, if you guys can write up how you think it should be handled, then we can get community feedback before making any decisions on process.

The UIUI User interface for core plugins in the adminadmin (and super 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/UXUX User experience designers involved as contributors.

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

As mentioned in the dev chat, we want to do a better job of all the mini-projects being visible by having them post updates on wpdevel.wordpress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/. Since there will be about 6 mini-projects (you guys, menu management, bugs, merge, post types, etc), I think the best thing to do is what we did for the GSoC blogblog (versus network, site) this year, which was to give each person (or in this case, project) a specific day on which they’re expected to post their update. That way wpdevel will be getting an update from someone almost every day. I’ll add all four of you as authors to wpdevel, and you can decide who is going to be responsible for posting an update once a week. Since you’re the first mini-project I’m emailing, I’m going to assign you Monday as your day for posting an update each week. That will work well, I think, since your first update can basically introduce what you’re going to be doing and let people leave suggestions in the comments to help get you started.

For the sake of transparency, I’ll also post this email on wpdevel so people know what you’re tasked with doing.

If you have any questions, suggestions, etc, feel free to contact me anytime. And have fun! This is going to change the WordPress ecosystem, and you’re in on the ground floor–how cool is that?

#3-0, #core-plugins