Process and Scope for 3.1, Part I

Last night’s dev chat was the first of two planning meetings for 3.1. The intention of this meeting was to remind everyone of the goals for 3.1, identify features that the lead team has prioritized, get an early sense of who’s willing to work on what, and to talk about the timeline. Much of what is written here is what was posted in the dev chat last night, to retain consistency.

There were a lot of suggestions on the table. That said, quite a few suggestions fall outside the stated intentions of 3.1 (quick, fast dev cycle, no big huge projects). For anyone late to the party, here are the goals of 3.1: to have a very short dev cycle, a decent amount of testing time, and a releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. in mid-December. Low on new features, heavy on ui and code cleanup, and avoidance of schema changes. Save the big ideas for 3.2 where we’ll have the liberty to implement those ideas in PHP5. No schema changes and no big new APIs.

This means stuff that got worked on over the summer or can be taken more or less wholesale from 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 or 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. has a better chance of being allowed into 3.1 than a brand new idea that doesn’t already have code written. In cases where we can do something small in 3.1 to pave the way for something bigger in 3.2, that will be the approach.

To that end, the leads have identified some of the suggestions, both from the wpdevelwpdevel Formerly the development updates P2 blog at wpdevel.wordpress.com. It is now make/core and resides at make.wordpress.org/core. and from other sources such as the ideas forum/WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. feedback/support forums, that would be appealing to include in 3.1. We’ve also identified some things that definitely do NOT fit into the scope of 3.1.

An example of something that doesn’t fit:
Media overhauls. We’re going to target 3.2 for a bunch of media fixes. The underlying code is too complex to do anything hardcore this fast. The only media things that would be acceptable in 3.1 would be small updates that don’t change the overall flow, such as the request to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). the caption able to hold htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. to include links. If someone volunteered to code that, that addition would be acceptable in terms of scope. Other discrete things like this would work. Refactoring the way featured images work would be out of scope.

Another thing that doesn’t fit is per-post/page/categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. selection. There are plugins that do this, and the code is nuts underneath. We want to stick to easy wins for 3.1.

Now on to things that fit!

Features

Polishing features introduced in 3.0 can be one umbrella task. BUT — this means spit and polish ONLY, not adding features to features.

New feature: Mark Jaquith is committed to getting in some advanced taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. queries stuff, which already has some movement in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. via scribu.

Mark Jaquith also wanted to get down and dirty with roles/caps, but that’s just too big an undertaking for 3.1. Maybe in 3.1 we could do the get_users() and friends cleanup that scribu started on to pave the way for role cap cleanup next time around.

In short? Mark Jaquith and scribu will be joined at the hip this cycle. 🙂

New feature: Internal linking. This is my pet user feature for this release. It has been requested from users for years, got the most +1s on the wpdevel post last week, and is a missing piece of true CMS functionality. Since we likely won’t have Andrew Ozz for this release, Daryl Koopersmith is going to take a stab at this, with backup from Austin Matzko if needed.

New feature: The ajaxified adminadmin (and super admin) screens that scribu did for GSoC, with some UIUI User interface cleanup applied. There was also a GSoC project by Matt H on comment moderation that needs to be reviewed for inclusion.

New feature: Admin Bar. Connect the back end to the front end. Most useful for people on multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site installs, but still useful for single-site users in providing 1-click access to dashboard, new post form, etc. We’ll be looking at both the original Viper007Bond admin bar plugin and the 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/ revised admin bar recently done by Andy Peatling. Note: there was some resistance to this being in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. rather than a plugin. A compromise of making it optional was discussed.

Cleanup: UXUX User experience/UI cleanup across the application, including multisite. This could turn into a ton of new dev, so we need to restrain ourselves. The UI group will do a review and come up with a list. Jane Wells and John O’Nolan will manage UI contributions from the group so that approved UI makes it into tickets.

Ongoing maintenance: Bug fixes. Peter Westwood is all over bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes. Anyone and everyone invited to submit patches for known bugs.

New feature: Separate networknetwork (versus site, blog) dashboard from the site dashboards (in multisite). Ryan started on this over the summer, and all agreed it would be great. Needs some UI love. Ryan also looked at doing a personal dashboard to replace the wonky global dashboard you get in multisite when someone has an account but no site. This might be a better 3.2 candidate, but we’ll see if we can get it to a reasonable place in time for 3.1.

There are some small fixes to the custom post types APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. that ought to be made, while staying within the ‘no big API things’ guideline. Nacin is taking charge of this.

I’d like to swipe the wordpress.com UI for searching/browsing installed themes, as it’s better than what we have in core (especially useful for multisite and sites with lots of installed themes, like those on shared hosting). I helped on the UI when John Godley made it last year, so I’d be comfortable with almost a straight swipe.

New feature: Post templates/post styles. Ryan will be handling this one.

New feature: Making QuickPress a template tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), so it can be used for front-end posting. Aaron Jorbin will be handling this.

Other suggestions not on this list that fit into the 3.1 guidelines (no schema changes, no big new APIs, etc) will be considered until feature freeze if a well-tested patch has been posted by then. Well-tested means more than one person, so if you want your pet project to be considered for 3.1, publicize your patch and get people to test it and post their results to the trac ticketticket Created for both bug reports and feature development on the bug tracker.! If you do not take on this responsibility, please do not complain if your patch is not considered; tested patches will always get priority.

Schedule

We want to release mid-December, preferably no later than December 15, so that the holidays won’t interfere with the release. To that end, here is the current plan:

September 9 – Confirm planned scope.

October 15 – Feature freeze; no new features added after this point, so that testing can begin on a stable-ish product (including usabilty testing of new features).

November 1 – Primary code freeze; any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..

November 15 – Beta period beings; from this point on, no more enhancements, only bug fixes.

December 1 – String freeze; translators rejoice.

December 15 – Release WordPress 3.1

So that’s the current thinking. The leads will be reviewing existing tickets and patches this week and working out the feasibility of including all the items outlined above. Next dev chat should see a conclusion to 3.1 scope planning, with some firm decisions on in/out and dates.