Ready to get started?Download WordPress

Make WordPress Core

Tagged: agenda Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:14 pm on November 1, 2013 Permalink
    Tags: , agenda   

    @matt will be running a WordPress 3.8 feature planning/decisions meeting on Monday, November 4, 21:00 UTC. Now that Daylight Saving Time has ended for both Europe and the U.S., note that the weekly Wednesday meeting is now moved from 20:00 UTC to 21:00 UTC (4 p.m. EST, 1 p.m. PST). (Americans, change your clocks on Sunday.)

    I’d strongly encourage everyone to study, test, and weigh in on the four 3.8 proposals before the meeting. I believe the goal of the meeting will be to establish what exactly gets merged into 3.8.

    API enhancements, bug fixes, etc. can/will continue as usual — it would be awesome if we had a surge not unlike 3.7. But for now, 3.7.1 is out, so stare at the download counter sip some tea, and relax this the weekend. :)

  • Andrew Nacin 5:29 pm on October 16, 2013 Permalink
    Tags: , agenda   

    Agenda for today’s meeting in #wordpress-dev at 20:00 UTC.

    • Go over the last few days of progress, as well as what we’ve been learning via statistics for background updates. (Spoiler: excellent.)
    • Need a commit or revert on #20316 (garbage collect transients). It has a patch — the queries need testing and review.
    • Need a decision on #24963 (IIS stuff).
    • Finalize the about page. It’s going to be text-heavy as there’s nothing to show off UI-wise. What about a single giant three-column image across the top? I mean, it can be a picture of a sunrise for all I care. Or some screenshot of the WordPress admin. Or some photos from the crowds at WordCamp San Francisco and WordCamp Europe. Anyone have any ideas?
    • WordPress 3.7 Release Candidate 1 (by tonight).
    • Branch WordPress 3.7 (after RC1).

    @dd32 and I are working on #10787 this afternoon as well.

  • Andrew Nacin 7:38 pm on September 25, 2013 Permalink
    Tags: , agenda   

    Meeting today: Road to WordPress 3.7 Beta 1 

    For the meeting today (starts in ~20 minutes), we need to work on getting to 3.7 Beta 1. I think if all goes well, we can release Beta 1 tonight or tomorrow morning. @dd32 has been doing some incredible work on automatic updates. If you haven’t read his post on them, please do!

    So, there are a few things we need to discuss and make decisions on:

    1. Search results ordered by relevance, #7394. Do we take a chance on this?

    2. Should we begin to require that users supply their current password in order to change their password? #20140.

    3. Should we consider a slightly more conservative different approach to transient garbage collection? We do not want updates to be blamed for breaking sites. #20316. What would this approach look like?

    4. How should individuals be notified via email when it comes to automatic background updates? #10787.

    5. How should individuals be notified their own dashboard that their site will be safe if there is a security release?

    Proposal for points 4 and 5: A green checkmark on about.php and update-core.php will let them know their install is OK and good to go for automatic background updates for security releases. (We can easily verify this without prompting the user.)

    If for some reason we attempt an automatic background update and it fails to complete, then we need to email get_site_option( 'admin_email' ). We need text for this email.

    If they don’t have a green checkmark, we should wait five days, after which we email them reminding them a security release is available. A timestamp five days from the point of release will be pushed via the API. Once that time is crossed, an email will be sent. (For a particularly critical situation, we could shorten the timeframe. For a non-security minor release, we might avoid having an email sent all together). We also need text for this email (which will be a fairly nice email).

    This does not accomplish all of #10787 (“Email administrators that an update is available for core, plugins, and themes”) but it seems to be a good security balance.


    My target is Beta 2 early next week, and Release Candidate 1 as early as next Friday. Here is our current progress on tickets:

    • There are no more enhancements or feature requests open on the 3.7 milestone.
    • There are under 20 tasks remaining for 3.7. Many of these are near completion. These need to be cleared by Beta 2.
    • There are 150 bugs open on the 3.7 milestone. We need to reduce this number to about 75 by Friday, and to zero by the end of next week. As in, these need to be cleared by RC1.

    We’ll likely branch 3.7 at the WordCamp Europe contributor day on October 7, which means anything that is punted out of 3.7 can still make it into 3.8 starting in just two short weeks from now. A reminder, this is a very short release cycle, and 3.8 is just a few months away and begins in earnest very soon. Here is what our philosophies document says about fast, agile release cycles with crisp deadlines:

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    If we’re not confident that three weeks is long enough for something to properly soak in trunk, let’s not be afraid to wait until 3.8.

  • Andrew Nacin 5:37 pm on September 4, 2013 Permalink
    Tags: , agenda   

    Today’s #wordpress-dev developer meeting (20:00 UTC) should be fairly brief. Let’s do a quick status report on different 3.7 tasks and then hammer on any Trac tickets (especially complex ones or ones that need a decision, since many core developers will be present).

    Please suggest any items for discussion, or any tickets we should consider.

    After this meeting, at 21:00 UTC, will be a 3.8 office hours meeting (like last week) in #wordpress-core-plugins in IRC.

  • Andrew Nacin 6:56 pm on August 28, 2013 Permalink
    Tags: , agenda   

    Agenda for today’s 3.7 chat at 20:00 UTC:

    • It looks like we’ve closed more than 800 tickets since 3.7 started. We increasingly need to develop some patterns here so we can sustain this. Let’s talk about how we can start targeting individual components, keywords, ticket statuses; and also we need to start to getting the 3.7 report in shape.
    • Discuss a timeline for the release. When should we have stuff ready for a beta 1, when should we hit RC, and when should we aim to release? What should we done for beta 1, versus what must be done for RC1?
    • The JavaScript working group decided on QUnit as our JS testing framework. There is an initial patch, which necessitates we move our PHP tests into a directory. Quick discussion and decision on where it goes.
    • Approve a Trac organization plan to use milestones for features-as-plugins and for Twenty Fourteen.
    • Work is starting on upgrades. We need to build out a proper task list and see where people are willing to help. (More on that in this blog post.)
    • Version 3.6.1 discussion and triage. It’s been four weeks, we should get things ready.

    I’d like to keep this chat to 30-40 minutes, followed by 20-30 minutes of unstructured office hours / Trac ticket review / 3.6.1 triage. The 3.8 meeting starts right after, at 2100 UTC.

    • Andrew Nacin 7:02 pm on August 28, 2013 Permalink | Log in to Reply

      Moving our tests around. Currently we have tests/ which is our root for PHPUnit tests. Individual test cases are in tests/tests/. The suggestion is to move to tests/phpunit/ and tests/qunit/. For reference, individual test cases would become tests/phpunit/tests/. The other option is to use js and php instead. It seems that using the actual library name is a bit more common, is more forwards-thinking, and immediately identifies which library we are using.

      • scribu 12:06 pm on August 30, 2013 Permalink | Log in to Reply

        What’s the plan for unit-test.svn.wordpress.org ?

        a) keep it up to date with commits from develop.svn.wordpress.org/trunk/tests/phpunit/ or
        b) leave it at the current revision? https://core.trac.wordpress.org/log/tests/

        • Andrew Nacin 12:49 pm on August 30, 2013 Permalink | Log in to Reply

          Seems like there are three options: a) leave it as is, b) sync commits over, c) make unit-tests.svn.wordpress.org/trunk an external of develop.svn.wordpress.org/trunk/tests/phpunit. I am not sure if that’ll work OK. Option C seems best; option B seems like a pain compared to option A.

          • scribu 3:59 pm on August 31, 2013 Permalink | Log in to Reply

            Making it an external would be one step backwards in terms of being VCS agnostic. git-svn doesn’t handle externals at all.

            • Dion Hulse 5:25 am on September 1, 2013 Permalink

              I believe the thought would’ve been to make develop.svn.wordpress.org/trunk/tests/phpunit be an external in unit-test.svn.wordpress.org, so those checking out unit-tests would actually be checking out an external.

              Unfortunately, that’s probably not a viable solution, as it would break anyone who has checked /trunk/ out directly.

          • scribu 4:02 pm on August 31, 2013 Permalink | Log in to Reply

            Also, wasn’t one of the major points of this re-organization to have the tests in the same repository? You can’t make changes to both the source and the tests in a single commit if the tests are in in an external.

    • Andrew Nacin 7:10 pm on August 28, 2013 Permalink | Log in to Reply

      Trac organization. Any plugin under the features as plugins plan that has moved beyond the initial conceptualization stage can apply for space in Core Trac. As these features are intended to be a part of core (and, were it not for our rich plugin architecture, they would be feature branches), it makes sense to to treat them as a part of core.

      One issue could be noise, but that’s already a problem with Trac. We’re working on fine-grained notifications which would include the ability to subscribe to a particular milestone, whether it is a release milestone or a feature milestone. When a feature gets pulled into core, its tickets will be reassigned to a component for that feature and its milestone will be changed to the release milestone. (It doesn’t appear any Trac plugins implement sub-milestones at this time.)

      I think we should automatically assign (and otherwise hide from forms) a “Feature Plugin” component. The “MP6″ (or whatever) milestone should be enough for a particular plugin. The exception would be 2014, which can continue to use the Bundled Theme component, but we’ll assign them a Twenty Fourteen milestone. Whatever we do, component and milestone will be linked and a reporter or contributor won’t need to know how to set them.

      Milestones currently aren’t settable by non-bug gardeners; this will change to make room for this plan.

      • Andrew Nacin 7:13 pm on August 28, 2013 Permalink | Log in to Reply

        An alternative is to have a “Feature Plugin” component, which sub-components like “MP6″ and such. Tickets could either be automatically assigned no milestone, or set to “Future Release”.

        What are our goals?

        • Sam Sidler 7:24 pm on August 28, 2013 Permalink | Log in to Reply

          I think I prefer sub-component to milestone as far as feature names are concerned. But I’d add a new milestone – “Feature Plugins” or similar – so the milestone overview would only have feature plugins components, making tracking easier (like the 3.7 overview above).

          • Andrew Nacin 7:28 pm on August 28, 2013 Permalink | Log in to Reply

            Yeah, this might make things easier as well. It requires us to install a subcomponent plugin, but we have been planning to do that anyway. The key here is just making sure the milestone is automatically assigned for these components — We can look into doing that, but it isn’t a blocker for proceeding here.

    • Andrew Nacin 7:26 pm on August 28, 2013 Permalink | Log in to Reply

      Timeline for release. I am currently thinking Beta 1 the week of September 16, RC1 the week of September 30, and release no later than October 14.

      What should be done by Beta 1? All work for updates, language packs, passwords; and any UI changes, new APIs, or enhancements. By RC1, all work on non-critical bugs stop, and we shift gears to release the moment things are ready. If all goes well, we’ll be able to branch 3.7 during this time, and immediately start working on everything again for 3.8.

      We’re at the point where report/6, at 324 tickets, needs to be paid down. I’m going to stop triaging old tickets and start working on committing stuff that others have already triaged, and I’ll encourage other committers to do the same. I think it is great for contributors to still look for solid patches in tickets not yet slated for 3.7, but let’s take it easy on moving tickets into 3.7 unless they have a solid and ready patch.

  • Samuel Sidler 9:35 pm on August 27, 2013 Permalink
    Tags: , agenda   

    WordPress 3.8 agenda for tomorrow 

    Our next WordPress 3.8 chat is tomorrow, August 28 at 21:00 UTC, following the 3.7 dev chat. Here’s our agenda:

    • Answer questions/comments about the features as plugins process (see yesterday’s post).
    • Review projects with no lead or weekly chat.
    • New feature presentations. Is there a new feature you want to work on that’s not being tracked? Now’s the time to present it. Bring as much information as possible and comment on this post beforehand.
    • Office hours.

    Hope to see all of you tomorrow!

    • Charleston Software Associates 3:24 pm on August 29, 2013 Permalink | Log in to Reply

      I am new to the make/core process but would like to start contributing to improving WordPress. I have some “contributor newb” questions:

      • Is creating a Trac ticket the best way to log new concepts for the admin UI?

      Assuming the answer is yes…

      • Is there a way to get Trac to show me more than 10 results at a time?

      I want to log my “wish list items” while working with WordPress over the next couple of weeks. For example:

      • Admin tables Infinite Scroll
      • Adding “delete permanently” w/ “are you sure?” confirmation to bulk actions (skipping trash = one less step in some cases)
      • Adding a page length option to admin tables v. the fixed 20 items limit.

      I’m not clear on the process, but thought it should start with a formal enhancement ticket in Trac. That at least organizes the wish list so myself, or another code geek, can come back and create a MP6-like plugin for a future release of WordPress.

      My other thought was a GitHub / Bitbucket project with an independent issues list, but that just feels wrong as it fragments the community and efforts to improve core. However I can see the benefit of not filling up trac with concepts, many of which do not belong in core.

      Maybe a new “wishlist” Trac?

  • Andrew Nacin 6:50 pm on August 21, 2013 Permalink
    Tags: , agenda   

    Agenda for today’s dev meeting:

    • Review why/how we’re doing features-as-plugins for post-3.7 releases (@samuelsidler)
    • Start cranking on tickets, discuss any major tickets we need to discuss, check if anyone is stuck or wants something to work on (@duck_)
    • A number of people are working on make/core posts to kick off some 3.7 initiatives (updates, language packs, inline docs, develop.svn ideas list) or jumpstart conversations for future dev meetings (CSS preprocessor pros/cons) — let’s aim to get these done this week.
    • This meeting will be followed by 3.8 office hours at 21:00 UTC. There is no 3.8 meeting tomorrow — postponed for this week.

    Also, the JavaScript meeting (IRC logs) went great:

    • @kadamwhite and @carldanley will be enumerating JS style preferences and working on a jshintrc
    • @jorbin and @kadamwhite are working on JS unit tests (#24870, #25096, #25088)
    • We’ll be formally adopting JSDoc for inline documentation (same basic style as PHPDoc)
    • Also discussed include JS actions/filters (#21170)
    • Andrew Nacin 6:52 pm on August 21, 2013 Permalink | Log in to Reply

      Suggest any items for the dev chat in the comments.

    • Carl Danley 6:55 pm on August 21, 2013 Permalink | Log in to Reply

      Also – i’m putting together a formal approach on design patterns to further enhance our consistency in JS. I’m hoping this will help to introduce a standard that developers can conform to; something that promotes both ease of use and a clear definition for how we should be approaching implementations. Will have this content ready a little later in the week.

    • Unsal Korkmaz 7:11 pm on August 21, 2013 Permalink | Log in to Reply

      Sorry if i miss, what happened to post formats?

    • WraithKenny 7:34 pm on August 21, 2013 Permalink | Log in to Reply

      I’m totally down for the pro’s side of css preprocessors. Grunt supports lesscss.org

  • Samuel Sidler 11:15 pm on August 14, 2013 Permalink
    Tags: , agenda,   

    Present your 3.8 feature idea at tomorrow’s meeting 

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

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

    • What problem(s) are you trying to solve?
    • What proposal solution(s) are you interested in exploring?
    • When and where is your group communicating?
    • Who has joined your group so far?
    • If you’ve selected someone to lead your group, who is your lead?
    • If you’ve already started work on your plugin, bring a link to your plugin page.

    See you tomorrow!

    • Matt Mullenweg 11:21 pm on August 14, 2013 Permalink | Log in to Reply

      And as many mockups / visuals / links to existing solutions as possible.

    • tomdryan 12:23 am on August 15, 2013 Permalink | Log in to Reply

      It’s not a feature per se, but is there a group looking at global usability improvements throughout WP that would make using WP a more pleasant experience, especially for new and casual users?

      I would happy to lead or participate in such a Usability group.

      • Sam Sidler 12:25 am on August 15, 2013 Permalink | Log in to Reply

        In general, I think you want the UI group. Minor usability updates can take place in any release cycle, including 3.7.

    • Justin Sternberg 12:31 am on August 15, 2013 Permalink | Log in to Reply

      I’m not ready to claim a big-picture group, but we at WebDevStudios have put some time and effort into re-thinking the admin’s widget admin page.
      A good post summarizing our vision, and some proof of concept mockups: http://webdevstudios.com/2013/08/14/webdevstudios-take-on-a-wordpress-core-widget-ui-refresh/
      Our p2 for discussion around the subject, open to the public:
      A github repo with the skeleton of a plugin for iterating:

      There are also other discussions revolving around the subject both new and old.
      Shuan Andrew has some really intriguing thoughts & mockups and even a prototype:
      & has posted a survey for the subject on this blog:

      Ipstenu has two posts discussing the subject (which we based a lot of our ideas on):

    • shaunandrews 12:39 am on August 15, 2013 Permalink | Log in to Reply

      I’ve been thinking a lot about widgets, menu’s, post-formats-as-content-blocks, and a grid-view for the media library. A few links to share for tomorrow:

    • Konstantin Obenland 12:56 am on August 15, 2013 Permalink | Log in to Reply

      Featured Content.
      It is part of Twenty Fourteen and it would finally provide a canonical solution that is portable between themes. I talked to a lot of people in the last week, the group that has assembled around it is fairly impressive, and @wonderboymusic has already updated the base plugin with a first proposal.

    • Ryan McCue 2:30 am on August 15, 2013 Permalink | Log in to Reply


      Working on it for now as part of GSoC, which means only I can write the core code for it at the moment, but there’s tonnes of extras around it that need doing until GSoC ends, and plenty of feedback to get at this stage. @japh, @jshreve, @mzaweb, @mordauk, @coenjacobs, @markoheijnen have all expressed interest in this for 3.8, plus @bpetty and @ericmann who are my current mentors.

      • Ryan McCue 2:35 am on August 15, 2013 Permalink | Log in to Reply

        GSoC’s pencils down date is September 23 (about 6 weeks away), which is when I’ll call the GSoC part done and move on to the core project part. In the meantime, anything out of scope is free game, including multisite, further JS API work, integrated unit tests, and any other new APIs (options? widgets?).

      • Japh 2:36 am on August 15, 2013 Permalink | Log in to Reply

        Yep, would love to get in on this one.

      • Andrew Nacin 3:13 am on August 15, 2013 Permalink | Log in to Reply

        I think this will need more time. Which, by the way, is completely OK. Let’s just be wary of saying “for 3.8″ — it should remain as a plugin until it and core are both ready.

        • Ryan McCue 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Definitely. I’d like to push hard to get it ready for 3.8, but if it ends up slipping then that’s not a big deal, IMO.

        • Bryan Petty 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Right, definitely, but worth mentioning that it could be awesome to see a large focus on this with a full team and lots of eyes.

          This probably should not be happening, but I know there’s at least one mobile project putting bets on this making good progress quickly.

    • Matías Ventura 3:19 am on August 15, 2013 Permalink | Log in to Reply

      Theme Experience for 3.8 and beyond, or THX38 for short.

      To significantly improve and re-imagine the admin theme screens for a better user experience. More beautiful, visually focused, fast, and up to date with the current times of mobile ubiquitousness, flexible resolutions and retina devices. Aiming to bridge the admin themes.php and the .org directory experiences, so that searching for and installing a theme is equally rewarding and consistent no matter where you start. Initial thread. Anyone who is up for this, please, chime in.

    • Mel Choyce 2:37 pm on August 15, 2013 Permalink | Log in to Reply

      Content Editing User Experience (CEUX)

      This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start.

      Currently involved in this group are @wonderboymusic, @saracannon, @DavidHickox, and to a lesser extent @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team. @jenmylo has graciously agreed to advise this group. We’ll be working out a time and place for meetings shortly.

      The content blocks plugin has been set up here.

    • jacob.dubail 3:47 pm on August 15, 2013 Permalink | Log in to Reply

      I was bummed that I missed the last 3.8 meeting. Hoping it’s not too late to get involved. See ya’ll online in a couple hours.

    • Siobhan 5:19 pm on August 15, 2013 Permalink | Log in to Reply

      Admin Help

      This group will focus on creating useful help for WordPress users within the admin. We’ll start by conducting research into the problems that users are having, and research into the tools available to us. We’re also looking into how other platforms implement admin help. Once we have identified the problem we will select the right tools and get to work with mockups then plugin. We have put together some specs for the project, started work on user testing, and looking at tools.

      So far involved in the group are: me, @trishasalas, @jazz3quence, the docs team, and we will be getting input from the accessibility team. Other people who expressed an interested are @japh, @ipstenu, @dllh, @JerrySarcastic, @kimparsell We’ve been using make/docs for discussions so far (under the admin help tag), and will set a regular time for meetings soon.

    • George Stephanis 6:08 pm on August 15, 2013 Permalink | Log in to Reply



      • George Stephanis 6:26 pm on August 15, 2013 Permalink | Log in to Reply

        DNS has been sketchy, so wanted to get a slug in first.


        Back when working on 3.5, @lessbloat worked up a new Welcome Screen that we worked on. In the trac ticket, #21368-core, @rhc3 mentioned his Hopscotch plugin that indexed the page’s links to provide suggestions and autocomplete for when someone was having a hard time tracking down what they wanted to do in the menu. It also included hooks to let third parties offer results as well. Some of this functionality was later duplicated by Japh Thompson of Envato, as a part of WP Butler.

        The search functionality wound up getting sacked, but I’ve had the idea of a ‘search-everything’ field in my mind ever since then.

        I built it out, wound up rolling it into Jetpack as a central core, to quickly iterate and make available but it’s built extensibly so any plugin can provide results. I think it’s a terrific UX win, and would like to test it and offer it for inclusion into core.

        • Japh 10:24 pm on August 15, 2013 Permalink | Log in to Reply

          I’d like to be involved with this (obviously, as I built WP Butler to serve a similar function)

    • MartyThornley 6:10 pm on August 15, 2013 Permalink | Log in to Reply

      I started a quick plugin as a proof of concept ( very early ) for rethinking the user and site signup and login process, especially concerning multisite. The idea is to consolidate and streamline it all. Also, to make things easier, make the urls more friendly – with /signup, /signin, /signout. https://github.com/MartyThornley/better-signups

    • @ubernaut 6:14 pm on August 15, 2013 Permalink | Log in to Reply

      here’s an idea which may be too crazy and it’s very basic so far no mock ups or anything but basically it to as much as possible do away with the distinction between front end and back end. Inspiration of this idea belong to Matt’s 2013 Stat of the Word speech and the problem of blog abandonment also some belongs to the existence of p2 as well.

      i have found that when teaching people that are new to wp that dichotomy between front and back end (which makes perfect sense to me btw) is a tumbling block and doing away with it may be very beneficial for learning curve.

      Obviously there are some task and admin stuff that would still need to exist but i think it could be very limited fro many user roles.

      • Avryl 12:45 am on August 16, 2013 Permalink | Log in to Reply

        @ubernaut I’d really like to help with this in any aspect. Who’s currently working on this? Are the people here still interested?

        • @ubernaut 5:23 pm on August 16, 2013 Permalink | Log in to Reply

          Great! Well trishasalas also expressed interest and George Stephanis also agreed to help me break down my idea to see exactly what it would take.

          Right now i’m just taking a day or two to think out the different aspects of how i invasion the all to work. mainly the idea i think in my head at least at this point is basically bring all the tools normally only accessible in the admin area to the front end via sort of context sensitive modal overlays.

          i guess i wanted to throw together a few simple mockups together so people could see what i’m thinking. I’m going to try to get a thread started so it will be easier to collect our thoughts on the will update here with a link once i have that going.

      • paaljoachim 2:54 pm on August 19, 2013 Permalink | Log in to Reply

        Frontend editing is an area that really needed to make things easier in learning about how to use WordPress. I helped a friend of mine who uses wix.com and it uses the frontend to edit the page. Wix is more basic but it has two important features: Easy for the user to select a skin/theme/template and from there they use the frontend to edit the skin. There is a video showing some of this on their web site. Incorporating backend features into the frontend is as see it a must. I look forward to helping in whichever way that I can.

        • @ubernaut 10:23 pm on August 19, 2013 Permalink | Log in to Reply

          • paaljoachim 9:54 am on August 20, 2013 Permalink | Log in to Reply

            Hey ubernaut. I see your screenshots and my mind began thinking. I have posted the below on your web site as well:

            Thinking out loud about the process…
            WordPress installed.
            The first thing one sees is the default theme front page. A box up in the right corner to login. The user logs in. The dashboard bar shows at the top. Since it is the first login a link below the login box is seen: “tour the interface.” User clicks and a short video is seen.


            • How to select a theme from the front end. Perhaps a link all the way to the right of the Dashboard top bar with the name of “Choose Theme”. Click the link and see a drop down of small thumbnails and at the bottom of the drop down a see additional themes option. As the user moves the cursor over the thumbnails they are automatically bigger to the side of the drop down showing 2-3 fairly large screenshots with some key info below the screenshots. The user selects a theme and the front end automatically adjusts to show the theme selected.
            • Hover over elements on the page an outline is seen and one can click inside and an edit bar is seen.
            • Drag elements around to replace.
            • Turn on grid to align elements.
            • Click directly on an menu link to move to the page.
            • At the top Dashboard bar click the +New (OR use the Template button next to it to use an existing saved page) to create a post/page/category.

            A blank page is seen and blocks are seen on the right side (depending on if it is a post/page/category). Main elements – Header, menu, sidebar, content, footer.
            Elements (widgets, shortcodes, block elements all in one).
            One drags the various elements to create the page. Click the save button top right to the left of the login area. Beside it is the copy page button on hover it will say save as template.
            Create a new page – and at the top right – save, copy, use template button.

            A lot of these things can be very similar on the backend and frontend.

    • Helen Hou-Sandi 6:23 pm on August 15, 2013 Permalink | Log in to Reply

      New overall admin style, by way of MP6. I will serve as interim lead while MT is on sabbatical.

    • lessbloat 6:31 pm on August 15, 2013 Permalink | Log in to Reply


      I plan to play around with some ideas for ways to update the dashboard. Perhaps simplify it a bit. Look at ways to possibly make it more easily extensible/customizable.

  • Andrew Nacin 3:07 am on August 7, 2013 Permalink
    Tags: , agenda   

    WordPress 3.8 meeting Thursday, August 8 

    In his State of the Word keynote, @matt announced that WordPress 3.7 and 3.8 will be developed simultaneously. Trunk would represent 3.7, while for 3.8, potential new features would be developed first as plugins. (3.8 starts at 35:00 in the video.)

    This “features as plugins” method* will allow teams to conceptualize, design, and fully develop features before landing them in core. This removes a lot of the risk of a particular feature introducing uncertainty into a release (see also 3.6, 3.5, 3.4 …) and provides ample room for experimentation, testing, and failure. As we’ve seen with MP6, the autonomy given to a feature team can also allow for more rapid development. And in a way, 3.7 provides a bit of a buffer while we get this new process off the ground.

    As announced at WordCamp San Francisco, Matt is leading the 3.8 release. He identified MP6 as a likely candidate for 3.8, along with the Twenty Fourteen theme. WP 3.7 will be released in October, at which point we’ll begin short window (probably two to three weeks) for any features to be merged for 3.8. If a feature isn’t ready for release by this point in the development cycle, it doesn’t land in core and moves to the next release. The target for WordPress 3.8 is early December.

    On August 8 at 18:00 UTC, Matt will host a WordPress 3.8 meeting in #wordpress-dev on Freenode.

    Thursday’s meeting is a great time to propose features that you’re interested in working on, keeping in mind they may or may not make it into WordPress 3.8. But keep in mind an early December timeline sets up WordPress 3.9 to kick off no later than January. Bring your ideas and thoughts as 3.8 development begins!

    To recap this post and the previous 3.7 post:

    • Wednesday, August 7 at 20:00 UTC — WP 3.7 initial planning meeting, #wordpress-dev
    • Thursday, August 8 at 18:00 UTC — WP 3.8 initial planning meeting, #wordpress-dev

    * Yes, this is more or less “feature branches,” but our rich plugin architecture makes it an obvious choice to follow the plugin-based model set by MP6. We have built features in plugins before — distraction-free writing in 3.3, the customizer in 3.4, and media in 3.5 all started as plugins. But they were pegged to a specific development cycle and did not have full teams developed around them, two issues we are now trying to fix.

    • Andrew Nacin 3:16 am on August 7, 2013 Permalink | Log in to Reply

      Just a note: All future weekly development meetings (Wednesdays, 2000 UTC) will cover both 3.7 and 3.8 updates and discussion items. Individual 3.8 feature teams will likely schedule their own office hours and such, as well. I understand how 1800 UTC is a terrible time for our friends in Australia and we’ll try to keep them a little more sane without upsetting our friends in Eastern Europe. :-)

    • Gage Morgan 3:34 am on August 7, 2013 Permalink | Log in to Reply

      That’s a very inspirational AND smart idea – building plugins are like making a model piece by piece to demonstrate what the software should look like before actually making any promises that the software will make it into core – if it doesn’t look right, rebuild it or just take it out completely. This will make the design process faster. Indeed, very smart indeed.

      • Scott Kingsley Clark 5:14 am on August 7, 2013 Permalink | Log in to Reply

        Agreed, and building as a plugin should help keep things well abstracted so it can be coded well, or other developers can provide their own ‘take’ on it too.

    • Eric Andrew Lewis 4:04 am on August 8, 2013 Permalink | Log in to Reply

      So working on two versions simultaneously is a practice that won’t be continued, at least for 3.9?

  • Andrew Nacin 7:17 pm on August 6, 2013 Permalink
    Tags: , agenda   

    WordPress 3.7 meeting tomorrow, August 7 

    If you haven’t caught @matt‘s State of the Word keynote at WordCamp San Francisco last weekend, you should. It contains a lot of great insight into how WordPress is used (using data from the 2013 user survey) and what should be expected for WordPress 3.7 and 3.8. (Talk about 3.7 starts at around 33 minutes in.)

    Here’s what was announced: WordPress 3.7 will be released in two months — early October. (Wat.) Jon Cave (@duck_) and I will be leading the release. It will be a quick “platform-focused” release, with a focus on stability and security.

    There are three main things we’d like to get done — language packs, auto-updates for minor releases, and some enhancements to help strengthen user’s passwords. Beyond that, though, the major goal of 3.7 is to offer a bit of a “reset” — which includes a huge cleanup of Trac. We’re currently at 3,800 open tickets, and we’d like to whittle that down as well as make things more manageable for the future. That includes reorganizing our Trac components, making it easier to contribute to certain areas of core (rather than, say, drinking from a single Trac firehose), and trying to organize teams around these components.

    Outside of core, there will also be work on developer.wordpress.org, which will include a hosted code reference and developer handbooks. As part of this, there will be a lot of inline documentation cleanup in 3.7 — potentially including an inline documentation standard for actions and filters.

    Better development tools will also be a goal in 3.7 — see also the post on develop.svn.wordpress.org from earlier.

    This is just the beginning. Please join me on Wednesday, August 7, 20:00 UTC for our weekly developer meeting in #wordpress-dev on freenode.net. I expect 3.7 to be a bit crazy, with a high volume of commits (oh, the days of WordPress 3.0), but also with increasing organization that can help set the stage for future releases. Daily bug scrubs! Rapid development! High tempo! Yay! Who is with me? See you tomorrow.

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