Ready to get started?Download WordPress

Make WordPress Core

Tagged: agenda Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 3:26 am on February 5, 2014 Permalink
    Tags: , agenda   

    Please suggest agenda items for the weekly developer meeting, Wednesday, February 5, 21:00 UTC.

    If there’s a task or ticket we need to work through, or need volunteers for, let’s get those spelled out now. Maybe we can even work through some of them pre-meeting.

    I’ll again be asking for a sentence or two (or more, if necessary of course) from each person/team working on a 3.9 task. You can also post those here if you’d like — please cross-reference any relevant tickets or discussions. Worked out great last week. For the state of things as of last week, see Mike’s weekly roundup.

    • Pippin Williamson 4:05 am on February 5, 2014 Permalink | Log in to Reply

      Not sure if there’s much discussion needed on them, but I’d love to see the remove/has_image_size() tickets shored up:


    • Jeremy Felt 4:19 am on February 5, 2014 Permalink | Log in to Reply

      I’d like to chat a bit about the direction of domain routing. I’ll be around pre-meeting as well.

      I opened #27003 last night with a patch that introduces `wp_get_network()` as a way to retrieve a network by it’s domain and path. This isn’t an absolutely necessary abstraction from `wpmu_current_site()`, but it does remove the functionality away from the `$current_site` global and focuses on retrieving just the requested information. In the process, `wpmu_current_site()` gets cleaned up quite a bit. It should be pretty straight forward to write unit tests that cover `wp_get_network()`.

      IMO, this is a first step toward cleaning up a bit of the load process. If we’re good with this direction, the next step will be to do the same thing for site discovery ($wpdb->blogs). I have more notes written up here on the multisite load process in general for anyone that wants an overview of how things are working.

    • Pippin Williamson 5:17 am on February 5, 2014 Permalink | Log in to Reply

      I’ll throw out another one. I’d LOVE to see further discussion on better custom comment types, per https://core.trac.wordpress.org/ticket/12668

    • Weston Ruter 8:14 am on February 5, 2014 Permalink | Log in to Reply

      There was a really good discussion today on #wordpress-dev regarding feedback for Widget Customizer. So I think we have a path forward for important issues to address. I’ve created a milestone on GitHub to track these issues: https://github.com/x-team/wp-widget-customizer/issues?milestone=4&state=open

    • Robert Chapin 11:27 am on February 5, 2014 Permalink | Log in to Reply

      3.9-early tickets, please

    • Manuel Schmalstieg 12:49 pm on February 5, 2014 Permalink | Log in to Reply

      For international users, improving the handling of accents/diacritics in file attachments would be a big win: https://core.trac.wordpress.org/ticket/22363 – the ticket has patches, and @markoheijnen has proposed it for 3.9 …

    • Tom Auger 7:59 pm on February 5, 2014 Permalink | Log in to Reply

      I’d like to discuss https://core.trac.wordpress.org/ticket/21811 and see if my patch / suggestions are salvageable, given the much bigger development effort around the entire Media Modal. The feature I was working on (prior to the whole Media Modal overhaul) was a very small, targeted, incremental enhancement that was kinda “shoehorned” in under that trac ticket, but really addresses something different and much smaller in scope.

    • Tom Auger 8:37 pm on February 5, 2014 Permalink | Log in to Reply

      Update: I see @gcorne has done some great work demonstrating how this could get integrated into Media Modal. I’ll continue this week and see if I can bring these things together. As for today’s meeting – we just got massively dumped on in Toronto, so I’ma head out of the office now and may not get back online in time to catch this week’s meeting.

  • Andrew Nacin 12:13 pm on January 29, 2014 Permalink
    Tags: , agenda   

    Please propose agenda items for the development meeting today at 21:00 UTC. Let’s try to keep it to under an hour, like last week’s.

    Some to start us off:

    • Consider the Widgets Customizer plugin for 3.9 merge. If you haven’t looked at it yet, please spend some time today before the meeting. Obviously, we all like the idea, but we need to study the implementation and provide feedback. Please comment on that post if you haven’t already.
    • I’d like to propose an initiative for cleaning up a group of 556 tickets during the 3.9 cycle. (It has details, will explain in the meeting.)
    • Quick situation reports for various 3.9 tasks. If you’re working on something, please come armed with a sentence so we can do these rapid-fire — or post it in the comments thread. Some things are moving forward quickly, some aren’t. Where can we help? Here’s a list of what was proposed for 3.9 (see also the comments, which were updated after the last meeting). We need to take the “proposed” label off soon…
    • I’d like to get moving on the Trac component re-organization; I’ll see if there are any questions. We will need some help to move around tickets (ideally adding feedback to them along the way), so I’ll be looking for volunteers and talking about what is needed.

    Aren’t familiar with how these meetings work? They’re especially good for breaking logjams — whether that means talking through a major sticking point, finding volunteers to help with something. We also use them to plan out schedules and tasks, make sure everyone is on the same page, and do release post-mortems to see how things went. (As 3.8.1 was released on Thursday, could be good to discuss this and 3.8.2, for example.)

    The meeting takes place in IRC on chat.freenode.net in the #wordpress-dev channel. See you then!

    • William Bowles 12:27 pm on January 29, 2014 Permalink | Log in to Reply

      I like it! One of the problems with WP has always been the amount of time spent moving between the various components that make up the site. I’d like to see a lot of the backend stuff move to the Customize sidebar and the popout access to other widget tools seems to work perfectly.

    • Tom Auger 2:06 pm on January 29, 2014 Permalink | Log in to Reply

      I have moved forward with https://core.trac.wordpress.org/ticket/21811. Still trying the time to upload an actual patch, but could use some eyes on the last two plugin ZIPs that were uploaded to see whether there’s any buy-in on my proof-of-concept approach to modularizing the Image Editor.

    • Tom Lynch 2:43 pm on January 29, 2014 Permalink | Log in to Reply

      I’d suggest considering talk around some of the older parts of wp-admin that have static coded HTML tables that don’t have any hooks or filters, nor use the Settings API to actually make it possible for people to develop management plugins.

    • John Blackbourn 3:11 pm on January 29, 2014 Permalink | Log in to Reply

      We should have a think about how we can start to build this new “easy first bug” report on Trac.

    • Jen Mylo 3:28 pm on January 29, 2014 Permalink | Log in to Reply

      GSoC 2014. I’ll post about it on this blog before the meeting, but would like to take a few minutes during the chat to discuss areas of interest for projects and people who’d be interested in mentoring/co-mentoring so I can get the application started.

    • Andrew Ozz 4:16 pm on January 29, 2014 Permalink | Log in to Reply

      Decide on JavaScript actions and filters, https://core.trac.wordpress.org/ticket/21170. We need JS hooks in core, either our own implementation or standardize on jQuery( document ).trigger( 'event-name' ). I know @koop had more thoughts on this but he hasn’t been around for a while.

    • tomdryan 4:17 pm on January 29, 2014 Permalink | Log in to Reply

      I may not be able to make it today, but I would like to propose creating a new task force that can look at existing plugins that would be good candidates to get moved into core. Most of the core efforts appear to be in developing new functionality, which is critical, but there are existing plugins that also fix gaps in the core feature set. The goal would be to identify those plugins and approach the authors to see what there interest level is in contributing their code to core. This approach unitizes WP excellent plug in architecture and plug in community to move WP core forward more rapidly.

      I love to hear comments about this idea (post here). I’ll try to make it to today’s meeting, but if not, I love to talk about this subject in the near future.

    • Bryan Petty 6:07 pm on January 29, 2014 Permalink | Log in to Reply

      I have an upstream update to PHPMailer in #25560. There are a couple decisions that still need to be made: include the full library, or strip it down without docs, tests, and examples (both patches are there), and a quick review of the approach on back-compat. This does need to in early in the cycle though, so about now is a good time, and hence why I bring it up now.

  • Andrew Nacin 8:25 pm on December 18, 2013 Permalink
    Tags: agenda   

    Proposed agenda for today’s dev chat (~35 minutes from now):

    • Initial debrief for 3.8. Start to think about what we can learn from 3.8.
    • Status report of bugs/regressions for 3.8.1. Look at a tentative 3.8.1 timeline.
    • Initial 3.9 discussion. Discuss potential feature plugin candidates, timeline, and release leads.
  • 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

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