Make WordPress Core

Tagged: process Toggle Comment Threads | Keyboard Shortcuts

  • Ryan Boren 5:22 pm on March 4, 2016 Permalink
    Tags: checklists, pitch, process, release-process   

    Release Process Checklists 

    The release process is complex and beyond one person. Releasing is an intricate dance that we haven’t been sufficiently capturing. Knowledge siloed in heads needs to be committed to public, institutional memory. The upcoming 4.5 release is an opportunity to capture every step of the dance so that we can iterate process, automate away lingering drudgery, and improve our cognitive net for the stressful task of releasing to 25%. I like using checklists in this cognitive net. They relieve anxiety, make process transparent, and help teams flow during stress. We already have a couple release checklists. We can build on those while adopting a little checklist culture in a manner empathetic to developers and flow. Pitch:

    Checklist cool tricks


    • distribute power.
    • push power of decision making to the periphery.
    • provide a cognitive net.
    • make the minimum necessary steps explicit.
    • make sure simple steps are not missed.
    • make sure people talk.
    • capture and shape real flow.
    • inspire flow in emergencies and sustain it through the quotidian.
    • capture flow between teams.
    • encourage a shared culture around flow.
    • accessibly capture institutional memory in the context of flow.

    Attributes of a good checklist

    What makes a good checklist? Checklist shouldn’t be about just checking boxes. Instead of being a chore and an admonishing finger, checklists should fit and assist real flow. The Checklist Manifesto offers these suggestions. Ideally, checklists…

    • are not lengthy.
    • have clear, concise objectives.
    • define a clear pause point at which the checklist is supposed to be used.
    • have fewer than ten items per pause point.
    • fit the flow of the work.
    • continually update as living documents.

    See this checklist for checklists and this example checklist for more.

    Stuff to checklist

    The major release checklist attempts to use pause points and follow the suggestions above. The major and minor release checklists are pretty rough and incomplete and overlap with each other. These and the things to keep in mind list need love and unification with help from developers who are in the release flow and handling controls on the release train.

    about.php is…quite the process. It needs the oxygenating powers of a checklist.

    Checklist Feature plugin merges.

    Checklist bundled theme releases so stuff like this makes it into institutional memory.

    Beta and RC releases.

    Plenty of other stuff. 🙂

    Start by capturing. As we walk 4.5 release flows, capture.

    Selected quotes from The Checklist Manifesto

    Checklists supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.

    (More …)

  • Jen 1:42 am on January 5, 2012 Permalink
    Tags: , , process,   

    Dev Chat Notes for January 4, 2012 

    When we talked about process in today’s dev chat, one thing I forgot is that at core meetup we agreed that we should post the notes and action items from each dev chat, then review the action items at the beginning of the following week’s chat to keep track of things. So here goes!

    Today’s meeting focused on the process to be used for the 3.4 dev cycle and the overarching concept of the release scope. To read through it line by line, see the IRC logs for the January 4, 2012 #wordpress-dev chat.

    Core team presence: Jane, Ryan, Mark, Nacin, Koop, Dion. Late arrivals: azaozz, duck_. Absent: westi, matt.

    Agenda: Review new process proposal that came out of Tybee core meetup, discuss; discuss potential focus for 3.4 release cycle; get statements of interest from people interested in taking more formal contributor role in this release.


    At Tybee meetup, I proposed we experiment with our process to try and overcome some of our historical downfalls (lack of good time estimation, resource bottlenecks, lack of accountability, unknown/variable time commitments/disappearing devs, overassignment of tasks to some people, reluctance to cut features to meet deadline), and the core team worked as a group to come to the following process proposal.


    • We’ll divvy up feature development in pairs/small teams rather than assigning anything to one person. Will hopefully lead to better code, happier coders, and more accountability.
    • Each pair/team will ideally have a lead/committer teaming with up-and-coming contributors who want to commit to working on something specific. Leads, committers, and trusted core contribs will be assigned to a team. Newer contributors can volunteer to work with a specific team but probably won’t be part of the core pair if we’re not familiar with your work yet. This will hopefully make it easier for people to get involved and make connections with the core team instead of lingering unnoticed on a ticket for months at a time.
    • Each team is responsible for their feature being delivered on time and meeting interim deadlines (scoping, blog posts, posting patches, etc.).
    • Each team will only be allowed to claim one feature at a time, and may not claim another until the first is complete. No more claiming multiple features and working on them simultaneously.
    • If a partner/team member goes MIA, rest of team needs to find out what’s up, and if something is seriously wrong, escalate to my attention.
    • We’ll have a list of who’s working on what worked into the 3.4 schedule page.


    • 2-week cycles, no soft edges. Every two weeks there is a bit of discovery, a chunk of development, and a period of testing/fixing within the team.
    • Overlapping team cycles. The 2-week cycles will start on a rotating basis so that teams will be in different phases at all times, allowing for fewer bottlenecks and a greater ability to weigh in on assorted projects. In between each cycle will be several days dedicated to Trac maintenance/bug fixes and tickets related to that team’s project, so that casual contributions won’t pile up waiting for a committer to take a look.Proposed graduated schedule diagram
    • Every week, the pair/team must post a progress report to wpdevel (once we have team assignments, we’ll make a schedule for this, like we did with gsoc student posts).
    • At the end of the two week cycle, team must deliver their scoped deliverable (generally a patch). If they are late, a warning will be issued. If they miss the deadline on 2 of the cycles, the feature will be reconsidered for inclusion in 3.4.

    Time Commitments, Time Tracking

    • Each team will estimate how long each feature should take (# hours, # days – estimate both total time working on it, and how long that will be spread over based on team member schedules).
    • We’ll have some mechanism for reporting time spent on the feature so that we can see how our estimates compare. Not sure if this will be manual or if we’ll use a trac plugin. Investigating options now. Individual “it took this long” stats will be private, but the aggregate “this feature took this long” will be public. This will remove any reason to fudge the time reporting out of fear of looking too slow.
    • Like in any job or volunteer gig, we’ll ask people who are assigned to teams to make a specific time commitment per week to working on core in their team. We understand that circumstances change and the time commitments may need to be adjusted along the way, but this is also intended to help us do a better job of preparing scope and using stats to see how we did. If we’ve scoped features that look like they’ll require a total of x hours per week but we only have y in time commitments, we’ll know up front to start trimming scope. Note: making a formal time commitment will not be necessary for casual contributors, only those assigned as an accountable party in a pair/team.
    • Each two-week cycle will be another chance to get better at estimating how long things will take, and over time we will improve at this as a group.


    3.3 was in some ways a multi-featured mess without a unifying theme. This meant lots of disparate stuff going on at once, and a number of features getting pulled due to timing. We want to get back to the idea put forth a year ago about having one overarching concept/goal/theme per release, that all new feature development fits into. We agreed that 3.4’s “theme” would be, “Making it easier to make your site look how you want it to look.” Shorthand: Appearance/switching themes. The idea is that a combination of front-end features, dashboard features, and under-the-hood improvements all tied to managing your site’s appearance will be the focus of 3.4. It will also include smaller things that don’t live in the appearance section but are related to the overarching goal, such as making it possible to have links in image captions. Make sense?

    The individual features will be selected next week, and the proposed list of possibilities will be put up before then in a separate post. We’ll figure out teams, everyone will do their scoping exercises for the features they are interested in working on, and then next week we can hopefully start nailing down who’ll start with what and get the final project plan in place for a dev cycle start the following week.

    High-level, the features would likely include: a theme-setup wizard that would incorporate an option for configuring all the appearance-related stuff before activating a new theme (speaking of, Twenty Twelve is targeted for 3.4), and then specific improvements around menus, widgets, backgrounds, headers, easier static front page process, multisite appearance management, etc.

    Choosing Teams

    This isn’t gym class; don’t be scared. This is, as stated before, mainly about accountability for the core team. In this cycle, anyone paired with a lead should hopefully be able to lead a pair/team in 3.5, and on and on, so we wind up with lots of experienced teams in the mix. For now, that list is fairly short, but if you are interested in having an official assignment or team designation:

    As we divvy up leads and committers we’ll keep your request/offer in mind. If we haven’t seen much code from you, you might want to throw yourself into bug patches over the next week or two so there are some examples of how you approach core code available. Anyone not on a team can work on any ticket and/or bug, and can confer with the appropriate team or with Master Gardener Ryan Boren for assistance as needed.

    Tentative teams so far: Nacin/dd32/Sergey on language packs, Mark/Pete Mall on multisite, Koop/ocean90 on wizard framework. People who already expressed interest in working with a team or making a time commitment: DH-Shredder, jkudish, helenyhou, drewapicture, MasterJake, tw2113, trepmal, japheth, sabreuse, jorbin, MarkoHeijnen, josephscott, maxcutler, aarondcampbell.

    We’ll regroup next week to flesh out the scope.

    Action Items

    In case it escaped you, this is a pretty giant change from how we’ve done development in the past. It’s a risk. It could turn out to be the best thing we ever did, or it could crash and burn. Let’s all try our best to make it super awesome!

    • Joachim Kudish 2:14 am on January 5, 2012 Permalink | Log in to Reply

      Survey filed up! Can’t wait to try the new system out

    • Gabriel Koen 2:18 am on January 5, 2012 Permalink | Log in to Reply

      In the past, I’ve seen an interesting ticket or two in Trac and me/someone posts a patch but the ticket just lingers — never gets closed or updated or otherwise escalated, the patch rots. What’s the best way to drum up some attention for these kinds of tickets and get them closed out with some kind of resolution? https://core.trac.wordpress.org/ticket/10964 is a good example

      • Jane Wells 2:23 am on January 5, 2012 Permalink | Log in to Reply

        In general, post to wp-hackers to get more community input on a ticket, drum up interest in the dev channel, etc. With that specific ticket, it comes down to scribu’s statement: “The status of this ticket is that there’s no clear data on which approach is best, only anecdotal evidence.” When that’s the case, tickets do usually linger until either one approach edges out the others or the bug is seen as growing more serious. We’ve talked about having a time limit on tickets, so that if something lingers too long it gets closed and we move on, but we haven’t come to any agreement on that yet. One step at a time, right?

        • arena 3:32 am on January 5, 2012 Permalink | Log in to Reply

          Following your advice on your previous post i just wrote a mail to wp-hackers@lists.automattic.com updating two patch on two tickets. I am not going to subscribe to the list, just waiting for updates on related tickets.

        • Jane Wells 4:30 am on January 5, 2012 Permalink | Log in to Reply

          @arena: I don’t think you can post to the list without being subscribed.

        • Lee Willis 9:19 pm on January 6, 2012 Permalink | Log in to Reply

          Hi Jane,

          I’d be sad to see anything like auto-closing. I have several tickets (All with patches) that I’d love to see in core, and to which there doesn’t seem to be much debate, but not much attention from anyone with the power to commit them either.

          I’d love to see a dedicated bug stream in any release cycle to make sure we’re not missing out on the small changes that can make everyone’s life easier.

          I’m happy to follow the bugs and update patches based on feedback etc. but I don’t have the time to follow wp-hackers I’m afraid – asking people to spend time reporting it there as well as in trac just seems like duplicated effort

          [Although I accept that if there’s a debate about an approach etc. to be had then it’s probably a better place to do that than on a bug]

          Just my 2p 🙂

        • Matt 9:36 pm on January 6, 2012 Permalink | Log in to Reply

          Lee, what are the tickets?

        • Lee Willis 9:44 pm on January 6, 2012 Permalink | Log in to Reply

          Hi Matt,

          Thanks for your interest. You can find them here. https://core.trac.wordpress.org/report/29?USER=leewillis77

          Don’t get me wrong – I know everyone is busy, and not everything can get done, I was merely arguing that auto-closing would be bad as stuff like this would get lost just because it wasn’t committed quick enough …

    • Japh 3:22 am on January 5, 2012 Permalink | Log in to Reply

      This looks great, I’m excited and hoping to get as involved as I can from now on. Survey completed!

  • Jen 2:46 pm on September 9, 2010 Permalink
    Tags: , etiquette, process   

    The Purpose of the Dev Chat 

    Every now and then it seems like people forget the purpose of the dev chat, or new community members aren’t clear on it, so I thought this, the beginning of a new development cycle, would be a good time to reiterate the purpose of the dev chat. The dev chat is a weekly product team meeting (see About the Dev Chat), not a weekly social gathering/town hall/q&a. For anyone who’s ever worked at a software company, an agency, etc., this should be a familiar concept: The team working on a software project meets, everyone gives an update on their part of the project, any roadblocks/red flags are identified and solutions are discussed, and updated assignments are given/confirmed.

    Each release cycle we remind people that this is the intended use of the dev chat, but somehow along the way we wind up losing track of that, and it turns into a combination of dev chat + ideas forum + wp-hackers live. Because the 3.1 cycle is so short (feature freeze is little more than a month away!), we need to stay focused this time around. We will be much stricter about staying on agenda, and while anyone is welcome to attend, we will ask people who have questions/suggestions that are not on the agenda to either wait until the dev chat is over or to bring it up in another venue, such as wp-hackers, on a Trac ticket, or in the forums.

    It’s understandable that many people want a direct line to the lead developers, and knowing they will be in a specific place at a specific time makes it easy to corner them to pitch pet requests, but please respect that these busy individuals are continually prioritizing the pet requests of hundreds of people and millions of users. Hijacking their product team meeting doesn’t help anyone’s cause.

    “Are you kicking me out?” some people may be thinking to themselves. No. The #wordpress-dev channel is open 24/7, and given the time zone distribution, there’s usually one or more lead developers in there, as well as numerous contributors. Discussion about core topics is welcome in the #wordpress-dev channel any time, and questions are usually answered gladly (and let’s face it, @nacin never sleeps). The weekly team meeting just needs to stay on target, on schedule, and focused on the actual contributing team. Though most people are volunteers working on WordPress core part-time, contributors are part of a product team, and their time should be treated with the same respect that any corporate product team would receive, if not more.

    If you are not working on patches for this cycle, please let the core product team get through its agenda. Hang on to your other questions to ask during one of the 167 hours per week in the channel that don’t have a specific agenda/schedule, or ask in another venue (Trac tickets are best, since it’s asynchronous and acts as the permanent discussion record for each feature). A good guideline here would be to think of another piece of software that you use. Let’s say Firefox or Microsoft Word. If you wanted a new feature, or wished they would code something a certain way so you could do something you specifically want to do for your clients, would you interrupt their product team meetings to ask for it? If not, then please grant the same courtesy to the WordPress developers. If you would interrupt them because you found something so major that it really needed to be addressed asap (like a security problem), then please don’t wait for the weekly dev chat! Get in touch with the developers in the channel right away, so that someone can assess the issue.

    If you’re following along in the dev chat and while the team is discussing a specific feature you think of something about the way they’re approaching it that you feel certain the lead devs/core contributors haven’t thought of yet, you are welcome to speak up (having read the Trac ticket first is a good idea, to make sure you’re not raising something that has already been discussed and dismissed). Maybe your idea is brilliant and everyone will thank you for the suggestion/fresh approach — go you! However, if you make your suggestion and the product team is not inclined to take it, please respect their decision. At that point, the best way to try and convince someone that your suggestion is a better approach is to code the patch yourself and upload it to Trac. Patches speak much louder than words in this case.

    Remember, the WordPress motto is “Code is poetry,” and for this particular hour each week, the poets are the main event. Thanks!

    • Andrew Nacin 3:52 pm on September 9, 2010 Permalink | Log in to Reply

      Well said.

    • Jacob Santos 6:32 pm on September 9, 2010 Permalink | Log in to Reply

      What do you do when you have a patch and it isn’t getting any traction? This might be a good post to do next.

      • JohnONolan 6:51 pm on September 9, 2010 Permalink | Log in to Reply

        Write a plugin? 🙂

        • Jacob Santos 7:46 pm on September 9, 2010 Permalink | Log in to Reply

          Clarification: What happens when you write a patch that isn’t getting any traction that fixes a bug or can’t be handled by a plugin?

        • Jane Wells 8:21 pm on September 9, 2010 Permalink | Log in to Reply

          @Jacob: publicize it, advocate for it, get people to test it and leave feedback on the ticket. If there’s ‘no traction’ it usually means they’re waiting for it to be tested and weighed in on by the community. If they just don’t want to commit something, they’ll say so and close the ticket.

        • Ryan McCue 9:22 pm on September 9, 2010 Permalink | Log in to Reply

          In any case, I’d say just to mention it to a developer, but *after* the dev chat. No reason it needs to be brought up during the dev chat itself.

      • Mark Jaquith 9:36 pm on September 9, 2010 Permalink | Log in to Reply

        I like Ryan’s suggestion. We usually hang around a bit. Fine to wait for and ping us with some tickets we may have not seen or need to revisit.

    • Stephanie Leary 4:18 pm on September 10, 2010 Permalink | Log in to Reply

      This is great information, but I feel like you’re preaching to the choir by placing it here, as most of the people who need to hear this still aren’t aware that this blog exists.

      Maybe a new wiki page linking off the dev chat mention in the channel description…?

      • Andrew Nacin 5:35 pm on September 10, 2010 Permalink | Log in to Reply

        I think very few who idle in #wordpress-dev fail to follow this blog. The exception would be individuals who wander over from #wordpress, thinking that dev is for development in general, versus core development chatter, but those individuals are simply in the wrong place. Those who need to read this post I imagine have read it.

        That said, I think you’re spot on about the lack of good information (as also mentioned in #wordpress-dev earlier) for where patch contributors should go for help, how to get involved, how code makes it into WordPress, etc. Changing that is a very important goal of the core contributor handbook. But back to this, mostly they just are not aware of the IRC resources, not vice versa.

    • arena 10:26 am on September 12, 2010 Permalink | Log in to Reply

      Could it be possible to clean up TRAC for the “Future Release milestone” which has 900 tickets … and counting !!


      • Andrew Nacin 6:04 am on September 13, 2010 Permalink | Log in to Reply

        You’re welcome to assist. If I had to guess, I bet 200 tickets can be instantly closed as a duplicate (potentially since it has already been implemented), wontfix (such as some feature requests better as plugins or ideas), or invalid. Milestones are not editable but that doesn’t stop triage from occurring. And “Suggest 3.1” for example is all it takes for one of us to move the ticket.

  • Jen 10:23 pm on July 1, 2009 Permalink
    Tags: process   

    Starting next week, we’ll be attempting… 

    Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance).

    • Jane Wells 10:24 pm on July 1, 2009 Permalink | Log in to Reply

      I will want to discuss the rankings from the feature poll that we’ll have up by then. It will still be running, but we should have a few days’ worth of votes, which is when we get the bulk of them anyway.

      • Denis de Bernardy 10:29 pm on July 1, 2009 Permalink | Log in to Reply

        If I may, it’s going to be much more important to find the volunteers to code the stuff.

        • Jane Wells 10:56 pm on July 1, 2009 Permalink | Log in to Reply

          True, but we can’t very well assign volunteers to specific feature development if we don’t know the features, and we don’t want to decide features without community input (as opposed to the core devs and or just the dev chat making these decisions). So while finding volunteers is super important and definitely harder than deciding features, we do need to decide the features as well.

        • Denis de Bernardy 7:35 am on July 2, 2009 Permalink | Log in to Reply

          Indeed, but at the end of the day I tend to remain very down to earth on this kind of thing.

          End-user feedback is meaningless if nobody shows up to code their requested features. On the contrary, asking for such feedback can have a negative impact. If those who are coding patches ignore the feature requests and prefer to focus on other things, you end up in a situation where users go “WP Devs ignore their community’s input”.

          Thus, please make sure someone’s willing to code feature A, B, C before submitting it to any kind of vote.

        • DD32 8:35 am on July 2, 2009 Permalink | Log in to Reply

          Voting is the only way to do it.

          Those who vote are those who’ll contribute, If you vote for a feature, Be willing to put the effort in for getting it in.

          In previous votes, Those which no-one is interested in coding(Even if there was a huge community want for) will receive little interest. Thats how it works around here. Yes, You might think this is a “wp devs ignore users” but in reality, Those who are contributing are not payed by the community to do so, Features are implemented when someone with the passion for it comes along and says “I want to do this”.

        • Jane Wells 2:12 pm on July 2, 2009 Permalink | Log in to Reply

          That point of view is in direct opposition to the idea of letting the full community have input into our feature set. Worst case scenario is that the core devs code features no one volunteers for and it takes longer, so knowing the priorities of the broader community is imperative in deciding which features they should focus on first.

          As with every vote, we make it clear that the vote is to influence core decisions, not to make them, so your argument does not convince me that we should forego voting before assigning developers to features. There’s no point in coding something that isn’t important to the broader community, and we aren’t going to put features in core just because a developer offered to code it, if it’s not to the benefit of the wider community.

          Community opinion + technical considerations + developer availability = How core decisions get made. We need all three factors to make a decision.

        • Matt 4:30 pm on July 2, 2009 Permalink | Log in to Reply

          If something is important and worthwhile, we’ll get it done. 🙂 Sometimes that means working on un-fun things but that’s okay.

        • Peter Westwood 7:22 am on July 3, 2009 Permalink | Log in to Reply

          There is no point coding features that people don’t want just because someone wants to code them – that is just adding bloat 🙂
          We need to know what the community desires so that we can focus on the right things.

    • Denis de Bernardy 10:28 pm on July 1, 2009 Permalink | Log in to Reply

      bugs, bugs, bugs, bugs. there are too many in trac, they need to get fixed/addressed, and there are bottlenecks to getting them tested and fixed. I stand by my opinion on this. the short short version is: need… more… committers…

      • DD32 8:45 am on July 2, 2009 Permalink | Log in to Reply

        You’re right, Less tickets would be nice. But its not going to happen by clicking fingers. Nor is it going to happen by more commiters.

        Like you say, There’s bottlenecks to getting them tested, But having more commitors will not help push it along, And it has the possibility of introducing more bugs. Currently there are 46 tickets marked as tested, I’ve just glanced over the “tested” tickets, and in my opinion, over a dozen are not commit worthy(By my standards), Not in the best interest of WordPress or Not really something that needs “fixing” (ie. not really a bug, just not working the way most expect). Those are the major reasons why tickets marked as tested do not get commited.

        There is a line that has to be drawn sometimes about what should be added to WordPress now, and what needs to sit and mature a bit first.

        • DD32 8:46 am on July 2, 2009 Permalink | Log in to Reply

          > Nor is it going to happen by more commiters.
          By that i mean, Nor will it happen by more “decent” commitors who can tell the difference between a good patch, and a bad patch. Adding 20 commitors will certainly get the current patch list down, but i wouldnt want to be the one cleaning up the mess.

      • Matt 4:30 pm on July 2, 2009 Permalink | Log in to Reply

        We need to be careful as we go through tickets — I feel like a blind chasing of low-priority bugs in the last dev cycle delayed the release and the resulting changes introduced instability we haven’t had in a few releases, regardless of the arbitrary metric of # of tickets in trac.

        • Xavier 10:39 pm on July 2, 2009 Permalink | Log in to Reply

          True enough. In my 2.8-presenting post on WPFR, I came out hoping that the sheer number of tickets solved was proof that 2.8 was among the cleanest and most stable release since a long time. Turns out that’s wrong, since 2.8.1 comes with a bunch of bugs that (AFAICT) should have been spotted earlier.

          While I can’t be against more committers, I’d be also in strong favor of asking for more tests, insisting the original reporter (and participants to the tickets) to make sure an issue is indeed fixed without side-effect, and maybe build more automated & user tests?
          Insisting on community leaders to have their staff and community make real-world tests of betas and RCs (with according test plan sheet, even?) ? I’m afraid a lot of us tend to rely on the “hey, core-devs are good, no need to worry. oh shoot, that feature is b0rked. bah, they’ll prolly know about it, it’ll get fixed eventually”.

          Typing while thinking, not sure that’s legible. Short version: moar testing.

        • Denis de Bernardy 8:20 pm on July 4, 2009 Permalink | Log in to Reply

          I partially disagree. The issues that introduced major bugs in 2.8 were, best I’m aware, related to enhancements. What would have been needed then would have been 2-3 more weeks of testing. Or as you like to put things, more testers during the test period we got — the end result being the same thing. 😐

          Either way, it goes down to keeping the contributors interested. The surest way to make them so is to when they quickly get feedback and/or supervision from someone who can end up committing. As things stand, there oftentimes is a second opinion from bug wranglers; but at the end of the day, if the final patch (on which everyone who contributed and expressed an opinion is happy) ends up stale because committers had better things to do, we end up generating frustration (and losing contributors/testers).

        • Denis de Bernardy 8:40 pm on July 4, 2009 Permalink | Log in to Reply

          @xavier: Indeed, but sometimes, you notice that a patch broke things long after it occurs. #10300 is typical of this. We introduced a WP_Widgets class in 2.8, and added an extra patch in 2.8.1 that makes is_active_sidebar() use wp_get_sidebar_widgets() so that a filter gets used. We ended up with a fully broken upgrader for pre-2.2 sites that were using widgets — but you’d only ever notice if you actually verify that your upgrade scripts still work, and the odds are slim that you would until it’s too late.

          As for “insisting on community leaders to have their staff and community make real-world tests of betas and RCs”, I’m pretty sure they all do. FWIW, though, my own beta for the 2.8 WP occurred when 2.8.1 was already in beta. Also, my old timers have learned better and no longer upgrade to a new major version of WP before the first minor release that follows.

        • Andrew Ozz 10:43 pm on July 5, 2009 Permalink | Log in to Reply

          Not exactly. Widgets support was introduced in WordPress 2.2 by adding the then very popular Sidebar Widgets plugin to core. As part of that a function was introduced to help the users of this particular plugin by converting their old settings for use with the new core functionality as the plugin couldn’t be used any more. Unfortunately in some rare cases this conversion was interfering with another conversion needed for WordPress 2.8, changing the default widgets settings from single to multi-instance format.

          The upgrade from WordPress <= 2.1 to 2.8 is working properly regardless of the patch in #10300 as long as all plugins are disabled during it which is the recommended way of upgrading. Of course the user would have to visit the widgets screen and possibly refresh some of the settings as many widgets have changed quite a bit too. The same is true for the rest of the WordPress settings.

          Re: minor bug-fixes. Still see quite a few tickets in trac marked as tested, commit, highest, blocker, etc. that fix something small but introduce another problem or needless overhead. Some even add regressions. I understand that in some cases it's easier to change the core to make a particular plugin work but does that warrant pushing these changes to millions of users when they would only be needed by several hundreds and possibly breaking other plugins in the process?

        • Matt 4:17 am on July 6, 2009 Permalink | Log in to Reply

          “Also, my old timers have learned better and no longer upgrade to a new major version of WP before the first minor release that follows.”

          That perception of our releases horribly toxic, and exactly what we’re trying to avoid. (And did with 2.7.) It’ll take a while to earn back trust, though.

        • Denis de Bernardy 3:20 pm on July 6, 2009 Permalink | Log in to Reply

          @Andrew: I’ll take your word for it regarding the patches that introduce problems etc. But if so, these tickets should be explicitly marked as such, occasionally closed as wontfix if we actually don’t want to fix the thing. In short, they need some kind of feedback. Currently, the patches stand there with no feedback, and that gives a devastating impression. Picture a new potential bug wrangler, whose only feedback from potential committers is that his patch become stale after a few months? It just makes no sense. Fixing this very point should, imo, get a higher priority than adding any kind of feature.

        • Peter Westwood 9:37 pm on July 6, 2009 Permalink | Log in to Reply

          @Denis: The thing is that for an end-user it is new features that drive the upgrade cycle not bug fixes. If we don’t have any new features there is no point in doing a major release.
          Each release should get a dose of bug fixes, but as Andrew says we need to avoid introducing regressions or just doing things to make a plugin work. I am all for adding filters and hooks to allow plugins to be created but very much against doing things in the wrong way just because it makes a plugin work.

        • Denis de Bernardy 6:38 am on July 7, 2009 Permalink | Log in to Reply

          @Peter: The key point I’d like to make isn’t that we should fix each and every on of them — even though I’d find this very desirable. Rather, it is that these bugs and many other tasks in trac are getting the attention they deserve. The key issue is we lack traction, and we do so for several reasons:

          On the one hand side, we’ve bug wranglers, a dozen or so of which might qualify as regulars. They open tickets, write patches, test and review patches by others… On the one hand side, we’ve a tiny number of core devs with commit access who, at the end of the day, are the only ones who can arbitrate.

          With only 2 core devs on a full time basis, and 2 on a part time basis, there is only so much time that they allocate to each ticket. As the number of tickets is gargantuan, a significant number of them end up ignored even with a perfectly valid patch creeps up.

          The issue goes down to how the core devs manage their time and that of others.

          I think everyone is fine with the idea that committers want patches reviewed by regular bug wranglers. It’s a perfectly valid idea: newbie wrangler shows up, reports a bug, offers a patch, awaits feedback, regular bug wrangler tutors him into writing a better one that he things can make it in core.

          Then what? The ticket gets marked as needing dev attention in trac. But as core devs are busy worrying about their own todo lists, that ticket gets no feedback or attention. Sure enough, it’s stale a few weeks later, and the ticket ends up rotting in trac for months. The newbie wrangler left in disgust, and he’s right. Time helping, the regular bug wrangler feels discouraged.

          How about inverting the core dev’s priority list, for a change? Instead of going through their todo lists first, go through what others are doing first. Close tickets we don’t want fixed. Express reserves about patches when there is a doubt on this or that point. Reject patch with similar feedback. Commit the patches that are worthy of committing.

          In short, their highest priority item should be to keep the wranglers interested, and to work as a team with them.

          Picture a software project manager who does every mistake in the book: not only does he allocates part of the work to himself, he distributes bit size tasks to his staff and allocates 99% of the work to himself.

          In the above sentence, read software project manager as core dev, and staff as volunteer bug wranglers. It’s exactly the situation WP is in. You’ve a potential army of contributors out there. Use it.

        • Jane Wells 12:35 pm on July 8, 2009 Permalink | Log in to Reply

          @Denis: We get it. You think the core devs don’t do enough, or at least you think they don’t do things in the right order. (For the number of hours they work, they are definitely doing more than the average person.) While I agree that the experience for new contributors is not optimal and could be improved, including perhaps scheduling specific times when each core dev would sift through Trac and reply to tickets (even if it’s just a boilerplate, “Checked this patch, needs more testing”), we can’t fix every single issue with the open source project’s organization at once. For today’s meeting, we’re going to focus on the 2.9 feature implementation stuff we agreed should be our focus when we spoke last week. The issue of the way the core devs handle Trac is bigger and would require more time. Also, Ryan will likely not be at today’s meeting, so talking about this would not be the best use of everyone’s time, since the discussion would just need to be repeated.

          The core devs are not the only ones who could do better. I’ve noticed a lot of tickets being marked as “tested” or “commit” by one person with absolutely no information about what environments they were tested with, and no confirmation by additional testers. This kind of marking slows things down. *Everyone* should be leaving more information/comments in Trac, not just the core devs, to prove something has been adequately tested (and not just on one person’s dev environment) before it should be considered for commit status.

      • Peter Westwood 7:20 am on July 3, 2009 Permalink | Log in to Reply

        Just because there are a lot of bugs in trac does not make the software very buggy.
        We need to hit the big issues and deal with some of them each release.
        Any attempt to “fix” all the bugs in trac in one release cycle would just make things worse.
        I don’t see that adding a huge chunk of committers improves anything.
        We need a small number of good well tested patches which hit the big bugs.
        A slower more heavily tested and reviewed development process produces more stable software than one where you just chuck all the fixes in you can find and hope they work.
        Getting more people involved in things like automated test writing would be a big help – this means we can get good validation on the functionality at a low level which we are building upon

        • Denis de Bernardy 8:45 pm on July 4, 2009 Permalink | Log in to Reply

          Nonetheless, reviewing and applying patches that fix bugs, rather than enhancements, should be much higher on the committers’ priority list imo. The end-result would be that the occasional contributor feels gratified and ends up contributing new patches. As things currently are, the odds are that many get the impression there is no real interest in their bug and/or patch, and they end up moving on.

    • Jeff Waugh 6:21 pm on July 3, 2009 Permalink | Log in to Reply

      A fairly minor enhancement suggestion for 2.9, with patch… prettier (Tango style) smilies in core:


      Thanks. 🙂

      • Jane Wells 3:30 pm on July 7, 2009 Permalink | Log in to Reply

        Committed to core, so not on agenda for this Wednesday. 🙂

      • Lloyd Budd 4:24 pm on July 7, 2009 Permalink | Log in to Reply

        Jeff, some interesting feedback from wp.com users http://en.forums.wordpress.com/topic/new-smilies

        • Jeffro 10:44 pm on July 10, 2009 Permalink | Log in to Reply

          A little more than interesting. Although I’d say the feedback regarding the change is negative from a vocal minority, I’m in line with the suggestion that this is one of those things that definitely could have had the opinion of the community. In fact, I think a much better idea would have been to put the call out to redesign a new smiley pack for WordPress like they did for the icons in WordPress 2.7 while also providing an easy way to swipe out smilies with a new pack unless of course that has always been plugin territory. The bottom line is, you make a sudden change like this that is strikingly visual, you’re going to upset a lot of people. I know this can’t be done for everything that goes into core, but at least with the visual elements that are seen by many people, I would think this would merit such a case.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar