WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from December, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:47 pm on January 6, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Lots of improvements to Core Trac 

    Over the holidays, I was sick for two weeks (boo). While resting and recovering, I took to working on our tools (yay). Specifically, Trac. Here’s an overview of the added features, enhancements, and bug fixes. There’s a lot (and more on the way), so I’ll try to keep each point brief. If you have any questions I’d be happy to elaborate in the comments.
    (More …)

     
  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

     
  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta – meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

     
    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply

      Finally.

    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! :D

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (http://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (http://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.

      (+1)

    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

  • Mark Jaquith 4:46 pm on February 19, 2013 Permalink
    Tags:   

    Dropping Editorial Flow 

    I’ve decided to drop the Editorial Flow feature from the 3.6 roster. A few things happened. We looked into what the main feature (“forking” a published post and allowing it to be edited then reintegrated) would involve, and found that there were some really fundamental hurdles that were unlikely to be resolved in the time given. A lot of time was spent on the planning stage, and we just kept surfacing more questions. Moreover, because the hurdles were so low-level, they would have required a significant amount of time from a core lead like me, @nacin, or @ryan — time that we just didn’t have to give this cycle due to other responsibilities. What that left was #12706 — a somewhat related ticket with a long-running monster patch. This similarly needed (and still needs) a core lead to dedicate a lot of time to planning, reviewing, and committing it. That might happen, or might not. It didn’t seem fair to keep @danielbachhuber and @kovshenin responsible for something that might or might not make it, subject to other people’s availability.

    Though disappointing, this effort wasn’t wasted. We learned a lot about the challenges involved, and we’re better positioned to tackle it in the future with more advance planning and a better understanding of the core team resources that need time dedicated to it.

     
    • Alison Foxall 4:49 pm on February 19, 2013 Permalink | Log in to Reply

      Understandable. I had been loosely following what was going on and it just seemed like a huge task to undertake. Looking forward to getting more involved in the future.

    • Marko Heijnen 4:58 pm on February 19, 2013 Permalink | Log in to Reply

      I guess for 12706 it makes sense to develop it on Github. Like what happend with WP_Image_Editor. You still get an monster patch in the end but the changes can be better maintained. If I would make a change on the code now literally no one would find out precisely what I changed.

    • scribu 5:18 pm on February 19, 2013 Permalink | Log in to Reply

      Is there some place where the lessons learned from the planning stage are summarized?

      At the very least, links to some IRC logs would be good.

    • Robert Lilly 8:45 pm on February 19, 2013 Permalink | Log in to Reply

      Sorry to hear this won’t make it into the next release, but glad to realize that the issues involved are being thought through and that this will be addressed in the near future. I think this is a feature that is really needed whenever there is more than one person involved in creating/editing/maintaining posts.

      In my fantasy I’m imagining something like the Review feature of Microsoft Word, specifically the Track Changes and Add Comments functions.

  • Andrew Nacin 8:34 pm on February 17, 2013 Permalink
    Tags: , slashing   

    Slashing (in)sanity 

    As many have you have noticed, changeset r23416 (ticket #21767, Remove stripslashes from API functions) has caused issues with quite a few plugins. (For more, read the detailed commit message.)

    Yes, trunk is very alpha right now. Yes, expect breakage.

    These aren’t “bugs” in plugins per se. At least not yet. For now, plugin authors should be alerted to follow #21767.

    We’re not jumping to revert things as @ryan and I want to take a wait-and-see approach on this. By going all-out initially, it provides us a lot of data to help us plot a modified course of action. We’re working to compile a list of grievances, so please, if something you were doing broke, please post specific code to #21767. We can then make adjustments to avoid major compatibility issues.

    We strive to remain compatible from version to version, but sometimes it just requires dropping a commit bomb to see how certain changes will actually play out in the wild. Thanks for testing, and no need to panic. :-) We’ll clean this up before beta. Bear with us, and help us out if you can!

     
  • Andrew Nacin 5:31 pm on August 22, 2012 Permalink
    Tags:   

    Suggest agenda items for today’s developer chat.

     
  • Jen Mylo 8:20 pm on May 23, 2012 Permalink
    Tags: ,   

    Pre-RC Dev Chat 5/23/2012 Live Blog 

    • #16079 Automatic excerpts don’t work well with Chinese txt (word counting): Nacin is handling. Westi closed for 3.4.
    • #20703 wp.getComments logs in the user (1 + #comments) times: Unit tests = fast track to commit. Ryan doing so.
    • #20699 AJAX Actions now pass the action name as an arg: reverting to 3.3 behavior, Ryan will handle it. Re-assess for 3.5.
    • #20448 Update Twenty Ten and Twenty Eleven to use 3.4 features: Koop and Nacin to review Lance’s patch.
    • #20554 3.4 Feature Pointers: Change position of the one on Headers to be side pointer. Jane talking to Ryan Ozz.
    • #19599 Localizations should not need to worry about the default secret key: Nacin’s top priority.
    • #8759 Word count function doesn’t work in several languages: Nacin is handling. Westi closed for 3.4, wants new tickets for 3.5 as needed.
    • #20737 Improve appearance of “choose from library” link for headers and backgrounds: Wait and standardize in 3.5.
    • #20507 3.4 Preview/Customize page “Return to Manage Themes” link doesn’t work as expected: Koop says nacin is handling.
    • #20600 Customize and display_header_text(): Koop will fix, patch needs some more love before committing. (Don’t we all.)
    • #20692 Handle unsaved changes in the customizer: change to button style per Jane’s comment on ticket. Helen will try patching.
    • #20736 Move customizer to wp-admin/customize.php: Nacin.
    • #20582 Theme Customizer: IE 8/9 compatibility: @ryan‘s top priority
    • #20733 Theme customizer doesn’t order sections based on order added: @dkoopersmith couldn’t reproduce, others could. Jane suggested punting, but Koop/Ocean90/Sergey looking and will fix if a simple one. Otherwise, a nicety that can wait for 3.5.
    • #20423 About WordPress page for 3.4: Closed. Reopen if any typos, credits will be updated from wordpress.org .

    Tally for remaining ticket assignments:

    • Nacin – 6
    • Koop – 3 + 2 reviews
    • Ryan – 3
    • Helen – 1
    • Ozz – 1
    • Ocean/Sergey – 1
     
  • Andrew Nacin 10:40 pm on February 16, 2012 Permalink
    Tags:   

    Results of 2/15 Dev Meeting 

    The teams and status document has been updated to reflect current cycles. Yesterday’s dev meeting focused on identifying issues pertaining to blockers and resources, and whether any adjustments or corrections needed to be made, across all teams. As I didn’t keep a general summary, you may find the log is here.

    I did take notes on who needs resources from whom:

    And there may be a few others I didn’t catch. Ideally this will all happen before our meeting next Wednesday.

    Two teams were added: @georgestephanis and Zach Abernathy (thezman84) working on tablets, and @aaronjorbin working with Tom Auger (tomauger) on favicons. I have been communicating with both teams to help get things off the ground.

    If you want to get involved, there are 198 open tickets on report 5, many of which fall under no team. If they do, find the team during office hours or contribute directly to the ticket, as many have done.

    Next meeting is 2/22 at 2100 UTC.

     
  • Jen Mylo 10:53 pm on December 18, 2011 Permalink
    Tags: ,   

    Core Team Meetup Recap – Part II 

    Picking up where we left off….

    Friday

    We kicked off Friday with a discussion about the high-level roadmap for 2012. Using our earlier talk about process and scope, we identified areas/userflows that we could use to focus a release. Areas of interest included changing themes/customizing your site, uploading a bunch of photos, interacting with audience/feedback loop. (There were more, but let’s face it, there are too many things we’d like to improve to do them all at once.)

    We all donned WordPress gear so that people would recognize us at the happy hour later.

    Dion

    Dion (dd32) modeling the latest swag

    Dion and Andrew

    Dion and Andrew Ozz before lunch

    Lunch: Went to The Sentient Bean in Savannah.

    The Sentient Bean

    The Sentient Bean

    Back patio at the Sentient Bean

    Back patio at the Sentient Bean

    Koop and Mark, Dion and Ozz in the background

    Koop and Mark, Dion and Ozz in the background

    Next we went to ThincSavannah, my coworking space in downtown Savannah. We did the livestreamed Town Hall/Q&A (recording coming soon), answering questions from that forum thread I put up last week and a few that came in live from IRC.

    Core team town hall video screen cap

    Core team town hall

    After that was happy hour at Jazz’d. Only two people came to hang out with us (and to think we dressed up especially!), but they were two great people, so we were fine. Some drinks and appetizers later, we departed for WordPress on Ice, in which we went ice skating at the Civic Center.

    Nacin and Koop on skates

    Nacin and Koop on skates

    Nacin, Mark, Jane, Matt, Jon, Daryl

    WordPress on Ice! Nacin, Mark, Jane, Matt, Jon, Daryl

    Then a stop at Huc-a-Poo’s, then home.

    Saturday

    We spent the morning talking about mobile apps and their place in the WordPress ecosystem, as well as making the dashboard a better experience when viewed in a mobile browser.

    Lunch: Went to AJ’s and ate on the deck. Continued talking about mobile. This eventually morphed a bit into a discussion about the lines between .org/.com.

    Core team at lunch at AJ's Dockside

    Core team at lunch at AJ's Dockside

    After lunch we talked about the default theme for 2012, including what it should do/be that our current themes don’t already accomplish, and the process for its creation. Breakouts followed. One was focused on multisite, while the other was focused on hosting/diagnostics/health check. We tested doing a Google Hangout with screensharing as a way to collaborate more effectively throughout the year, and agreed we would try to do them once a month. For dinner we got takeout BBQ from Gerald’s Pig & Shrimp. We pretended @ryan was with us by playing a video of him from last year’s meetup. Afterward, Koop gave a primer on JavaScript.

    Sunday

    When we started this morning, we tried to at least quickly hit the things we hadn’t gotten to yet, since today was the last day. These included: Google stuff, core plugins, how leadership in core does/does not translate to leadership of the whole project, wordpress.org site, pairs (creating process to make collaborative/non-solo development the norm), and CMS stuff.

    Since a lot of us were pretty interested in making the theme customization process a focus of the next release, we starting identifying what the chunks of that might look like under the new process and with people working in pairs/teams. We continued talking about this over brunch at the Tybee Island Social Club, where @nacin and @dkoopersmith drank bacon bloody marys.

    Bacon Bloody Mary

    Bacon Bloody Mary

    Nacin attempting to consume a bacon bloody mary

    Should Nacin eat the bacon or drink the bloody mary? He can't decide.

    After brunch, @markjaquith and @dd32 left for the airport, and @joncave and @azaozz left two hours later. Bye bye, core team!

    Now we begin a 2nd mini meetup. Matt, Nacin, Koop, and I are staying, and have been joined by @otto42 and @chexee. The next couple of days we’ll be doing some planning and starting projects to make visiting wordpress.org a better, more useful experience. Tonight, though, everyone is catching up on some individual work after a week of long days.

    We’ll post summaries of the specific core meetup discussions over the coming week.

     
    • Michael Beckwith (@tw2113) 11:26 pm on December 18, 2011 Permalink | Log in to Reply

      Very curious to see how the focus on theme customization process turns out, and maybe I can jump in and help a bit with that as it’s one areas I love focusing on.

    • Andrew Nacin 12:12 am on December 19, 2011 Permalink | Log in to Reply

      Worth nothing a few things:

      First and foremost, that bacon bloody mary was good. Really good. Who cares how you consume it.

      Second, please don’t interpret the lack of a mention of any peculiar topic to mean it wasn’t discussed — only that only so much can fit in one of these posts. For the developers, we had some discussions on security practices and procedures, unit testing, and core architecture (and planning for the future). The word “multisite” escapes with a single mention, but in that meeting we came away with a number of immediate action items, as well as a potential roadmap for the next year. And if you didn’t catch the livestream, you may have also missed that we’ve committed to a JSON API in core to go alongside RSS.

      This was just the day-to-day play-by-play. There’s a lot more we need to write up. Woo.

    • David Johnson 2:46 am on December 19, 2011 Permalink | Log in to Reply

      Thanks for the recap write-up!

      Any word about backup/restore/migration issues within the WordPress core? It seems like basic security and backup should be in the core installation..but maybe I’m missing something.

      Thank you WordPress core team for allowing the community to be involved and aware of the goings on within WordPress.

      • Jane Wells 2:24 am on December 20, 2011 Permalink | Log in to Reply

        Security is definitely something that was talked about, but a backup utility is more suited to a plugin than core (though we did discuss the possibility of a core/canonical plugin for backups).

    • Adam W. Warner 2:34 pm on December 19, 2011 Permalink | Log in to Reply

      It’s great to get an “insider” view of your meetup, so thanks, the community appreciates it and all the work you all do to make the World a more open and accessible place for many to have their voices heard.

      Also, @Nacin, thanks for the additional mention of Multisite. I’m an avid user and am pleased there will be some additional focus.

    • Lance Willett 3:00 pm on December 19, 2011 Permalink | Log in to Reply

      Great job with all these newsy updates, Jane. Kudos.

    • mitcho (Michael 芳貴 Erlewine) 3:07 am on December 22, 2011 Permalink | Log in to Reply

      Wait, is the “Nacin and Koop on skates” photo the answer to my request!?

      Here was the original ticket:
      https://twitter.com/#!/themitcho/status/147901791776935937
      :D :D :D

    • havahula 3:51 am on December 23, 2011 Permalink | Log in to Reply

      ok. i’ll bite. where does one get those fancy, baby blue track jackets Dion, Ozz and Matt are wearing? and did Nacin have one too before he drank the bacon bloody mary, which turned his brown?

  • Jen Mylo 12:54 pm on December 16, 2011 Permalink
    Tags: , ,   

    Core Team Meetup Recap – Part I 

    As most people know, the core team (leads, primary committers, Matt) is having its annual meetup this week, packed into a house in Tybee Island, GA with an hour by hour schedule to try to get through as many things as we can. We’ll try to do recaps of everything we talk about to keep everyone in the loop (feel free to ask questions in the comments).

    Monday/Tuesday

    Matt, Mark Jaquith, Westi and I arrived (well, they arrived; I live here) on Monday and had a day to plan out the agenda topics and work out how we wanted to schedule the week. Rather than plot out a unique schedule every day, we put together a repeatable pattern for morning and afternoon that looked like this:

    Schedule chart

    For the record, “Break” means “Check email, catch up on Trac tickets, etc,” not, “Hang out on the couch watching Hulu.”

    On Tuesday we also took a field trip to buy a cable modem capable of handling the bandwidth increase we’d ordered. That night, everyone else arrived: Nacin, Koop, Dion (dd32), Andrew (azaozz), and Jon (duck_). We had dinner at the Crab Shack and planned an early start on Wednesday.

    Wednesday

    Wednesday was our first day as a full group. We followed the schedule fairly well, though as always with us, some things took longer than expected. :)

    Breakfast: We went to eat at the Breakfast Club, where a bunch of the guys had Blackhawk burritos in honor of our absent member, Ryan Boren.

    Our first main topic was a 3.3 debrief to discuss for about 45 minutes how the 3.3 development cycle went. (Going to split out the notes from these sessions into separate posts, or this post will be a mile long.)

    After that we had breakout sessions, where the intention was for smaller groups to brainstorm/discuss an issue, then come up with a proposal/recommendation to present to the group. The two topics were QA and Updates (specifically the road to auto-updating and how we could get there). Mark assigned people to each session and half the group went upstairs. Coincidentally, that was the UPdates group. (sorry) Afterward, we regrouped and caught each other up on our proposals.

    Lunch: Blackhawk burritos keep you full for days, so people just made sandwiches.

    Round 2 started bringing in @ryan via Skype video from his home in Texas. The main discussion centered on our development cycle/release process/scoping/timelines. We discussed a number of things we could try to keep the cycles more consistent, reduce bottlenecks, and improve accountability.

    Dinner: It was my birthday, so we all went to the Tybee Island Social Club for “Winesday” and continued our talks about everything from the wordpress.org site to growing local developer and user communities. There may be a picture of Koop and/or Nacin wearing a child’s birthday hat. Mark Jaquith has the footage.

    Thursday

    Breakfast: Miscellaneous breakfast stuff at the house. Pretty sure there was a bunch of bacon involved.

    Morning session: Plugins, plugins, plugins. You name it, we talked about it. Findability in the directory, improving the repo and developer experience, plugin review, encouraging collaboration, 3rd party repos, communication with authors, and more.

    Both breakout sessions were plugin-centric. In addition to general recommendations, each subteam was required to identify two discrete action items to help us move forward in their assigned area. One subteam (Me, Westi, Jon Cave, Andrew Ozz) was focused on planning upcoming wordpress.org sites in the Make and Learn areas, while the other (Matt, Nacin, Koop, Dion, Mark) focused on improving the directory.

    This day we did an actual fun outing to get us out of our chairs and away from the laptops for a bit, and went out on a boat for an hour so the guys could get a tour of the river/marsh and hit the ocean as we looped past the Cockspur Lighthouse.

    Core team, on a boat

    Dion (dd32) and Matt

    Mark and his lens

    Koop

    Matt and Cockspur Lighthouse, Tybee Island

    After the boat, we went to lunch at North Beach Grill. There were conversations about infrastructure, performance, automated testing, and crawfish poppers. Before going back to the house, we did a 5-minute walk down to the water.

    Westi on the beach

    In the afternoon, rather than doing another block of heavy discussions, everyone worked on their computers. Some of you may have had some issues accessing svn etc last night, and so did we. So that took a while. After that it was general hackery and miscellaneous discussions about functions, bugs, and the usual things wp devs talk about when they are together. This lasted into the evening, so instead of going out to dinner we ordered pizza from Huc-a-Poo’s and kept working.

    Friday

    Today we’re having a modified schedule because Westi leaves to go home this evening, so we’re trying to get certain things finished before he leaves. We’ll be working this afternoon from a coworking space in downtown Savannah, and will be recording video responses to some of the questions on the forum thread I posted last week. If bandwidth supports it, we’ll livestream this while we record, and could possibly take more questions from people in #wordpress-dev. If we do it, we’ll use the Ustream “WordPress” user channel, and it will be mid-afternoon eastern time (maybe around 3pm?). Once we get there after lunch and can tell if the livestreaming will work, I’ll post on this blog with the verdict.

    Off to Friday’s sessions! We’ll start posting the session writeups as time allows, but will get them all up there no later than the end of next week (there are a lot of notes).

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel