Setting Scope

Posted December 25, 2009 by Jen. Filed under Development.

Merry Christmas! One of the things that was discussed at the core commit team meetup was release scope (and scope creep). Now that 2.9 is out and it’s time to start thinking about 3.0, we think it would be appropriate to stop and take a breath before diving in, and make a plan in advance. What winds up happening is that during each release cycle a few new features are selected for inclusion, but then right up until feature freeze (and/or beta cycle), people keep adding feature requests, patches for enhancements, and ongoing bug reports. This means each release winds up getting pushed out later than planned, and with so many things going in per release, it becomes harder to catch new bugs.

The as-long-as-we’re-not-in-freeze-yet model isn’t working. People wind up waiting months longer for new features they want, like Trash and Image Editing, because we’re still adding other things and then we need to test them all. If we kept the releases smaller feature-wise, we could push out the new stuff sooner (3 releases per year is the goal) and have more focused beta testing, making the releases themselves better. It’s hard, because everyone has their pet features and fixes, and if there’s a patch, why not get it in this release rather than waiting? Sometimes people complain that a patch has been waiting to be committed for weeks or months, but what no one ever seems to bring up is that sometimes patches introduce new bugs, and the more we add at once, the harder it is to keep it all well-tested on various platforms, in different hosting environments, etc. So. What’s our proposal?

We take a page from the world of project management and we make a project plan before we jump into the dev cycle. We let everyone propose features and enhancements, and we choose a limited number to include in 3.0 (in this case we need to be especially stringent, because the merge of WordPress and WordPress MU will automatically mean a lot of work) and set a realistic release date that we stick to. We create a tentative set of features for the next two releases, to be re-evaluated at the beginning of the next cycle, so that people know the community is committed to certain features, as opposed to the vague “future release” label we now use for everything not included in the current version. We fix bugs that are reproducible and affect a large number of users before focusing on edge case bugs or bugs that haven’t been well-described or reproduced. We stop diverting our attention from agreed-upon goals when a “squeaky wheel” decides we should all be focused on something else. There are always things that pop up unexpectedly, but we need to do a better job of restraining ourselves when it comes to trying to sneak things into the current release (I include myself in this, of course…as a UX person I always wish we could do everything all at once!).

As an open source project, we accomplish more when we work together than we do following individual agendas, and we need to keep our project focused on commonly-agreed-upon goals instead of following tangents whenever a community member starts to take us on one, regardless of whether it’s to follow a cool idea that everyone loves or a suggestion based on a personal agenda, and regardless of whether it’s a newbie who doesn’t know any better or a frequent contributor or committer who has a strong opinion and a loud voice (so to speak). The issue here is that it’s easy to get distracted, so we need to create a structure that will help us keep moving forward instead of getting sidetracked. We need to keep Trac clean for the current dev cycle so that it includes confirmed features and bug reports, and all new feature suggestions go into a different milestone.

We think it’s at least worth a try. When we re-start the weekly IRC dev chats in 2010, the first meeting will be to talk about the scope of 3.0. When we’ve got a general agreement about what will be included, we’ll create the appropriate Trac tickets, and punt tickets for non-3.0 feature requests/enhancements to a future release so we can stay focused. New bug reports will still come in to the current milestone. It’s going to be hard. There are at least a dozen new features that I feel like we’ve pushed back multiple times that I’d like to see in core, but for this experiment, I’m just going to keep reminding myself, “You can do that with a plugin!”

Sound off on the features you would like to see in version 3.0.

6 Pings

RSS feed for comments on this post.

  1. […] einem langen Blog-Beitrag auf WordPress.org hat Jane Wells die künftige Entwicklung von WordPress skizziert und zwar nicht inhaltlich sondern […]

    Pingback from WordPress-Entwicklung soll fokussierter werden | Peruns Weblog on December 25, 2009

  2. […] Christmas Day, WordPress announced the launch of WordPress 3.0, and with it, the inclusion of WordPress […]

    Pingback from WordPress 3.0 to include WordPress MU (multiuser) » K4 Media Web Design Cambodia on December 26, 2009

  3. […] Los chicos de WordPress no paran de trabajar y es que apenas llevamos unos días con la nueva versión de WordPress y ya nos piden el apoyo a los usuarios para que propongamos lo que mas nos gustaría en la versión 3.0 de este magnifico CMS. ¿Quieres algo en especial y diferente en WordPress?, esta es tu oportunidad. […]

    Pingback from Solicitud de propuestas para version 3.0 de WordPress « Walhez on December 26, 2009

  4. […] with wp.  As I was logging in to the blog today I noticed a little article about setting scope.  Click here to read the article.  One of the things I didn’t know about the development cycle of WP is that they were […]

    Pingback from James Giroux » Blog Archive » Open Source Gets Focused on December 27, 2009

  5. […] start working on 3.0, where the merge of wpmu will be rolled in. In case you missed it, Jane has called for suggestions of anything else you would like to see, and set up a forum thread for anyone to participate […]

    Pingback from Merge news and Buddypress awesomeness - WPMU Tutorials on December 27, 2009

  6. […] Jane’s post on setting the scope for future releases shows that WordPress’s process is continuing to mature. Notably: […]

    Pingback from On Setting Scope « Geof’s Relentless Kvetching About WordPress on December 27, 2009

See Also:

Want to follow the code? There’s a development P2 blog and you can track active development in the Trac timeline that often has 20–30 updates per day.

Want to find an event near you? Check out the WordCamp schedule and find your local Meetup group!

For more WordPress news, check out the WordPress Planet.


Subscribe to WordPress News

Join 3,088,280 other subscribers

%d bloggers like this: