Dev Chat Summary: July 19th (4.8.1 week 5)

This post summarizes the dev chat meeting from July 19th (agendaSlack archive).

4.8.1 schedule

  • Access to Mission Control was lacking and delayed 4.8.1 beta release
  • Working to commit #40974, #38964, #40794 for 4.8.1 beta
  • Final planned bug scrub is Thursday, July 20th 16:00 UTC / Thursday, July 20th 16:00 UTC
  • Bug scrub will be focused on punting anything not headed towards a commit by Friday
  • If tickets in milestone drops to zero, we will continue with the planned 4.8.1 schedule:
    • RC – Monday, July 24th (hard string freeze)
    • Launch – Tuesday, August 1st

General announcements

#4-8, #4-8-1, #dev-chat, #summary

PHP Meeting Recap – July 17th

This recap is a summary of the second weekly PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @drewapicture @flixos90 @jdgrimes @joyously @mte90 @psykro @ptasker @schlessera @screamingdev @sergey @sobak @varjik

Chat Summary

In the beginning of the meeting, the discussion from last week about investigating ways to increase the amount of sites on a supported PHP version was continued.

  • It was highlighted that a possible notice displayed to admins of sites on old PHP versions should have pluggable parts that would allow hosts to serve upgrade instructions specific to their platform. The minimum required there would be a host-specific link to a page with detailed instructions, which could for example be set through environment variables. This should be possible independently from core so that further integrations or changes would not require a new core release.
  • There should also be a general “Browse Happy”-type information page on wordpress.org, that the notice could link to either as a fallback or in addition to the host-specific URL. Such a page should explain what PHP is and why it matters that a supported version should be used. It should be an easy-to-understand and precise document that could also be shared in other instances. A GitHub repository could be set up to start work and beforehand gather similar sites that have already been created by third parties.
  • While we have mentioned before that plugins should be able to define their minimum required PHP version (see #40934), it should also be possible to define the PHP version the plugin has been tested up to. Otherwise we could only prevent installs of newer plugins, but outdated ones could still break on a new PHP version without any further notice.
  • In regard to that, while it may be impossible to do that, it would be great if WordPress had the possibility to automatically scan installed plugins and show a message to the admin that, for example all their plugins work correctly with PHP 7 or that some specific plugins might cause trouble on PHP 7. While the recommendation is to upgrade to PHP 7, there are several plugins that are not yet compatible, and a user should not learn that the hard way.

Later in the meeting @drewapicture emphasized that we had so far skipped a significant part: While everyone that was part of a discussion had apparently been convinced that WordPress should push for a more modern PHP version, we had never framed the actual problem (or problems) that this is currently causing. Therefore it was decided to take a step back and think about what those are. Even if WordPress is not going to raise the minimum requirement, the task is to specify why it is worth pushing hosts and users to a newer version. A good idea to approach this is to phrase problems like “WordPress supporting legacy PHP is…”. Here are some of the initial takes that came up:

  • WordPress supporting legacy PHP is making the developers spend more time chasing obscure bugs and less time building new features.
  • WordPress supporting legacy PHP means it will at some point completely lose connection to current PHP.
  • WordPress supporting legacy PHP has become more of a liability than a feature for its users.
  • WordPress supporting legacy PHP means other platforms will outpace WordPress soon.
  • WordPress supporting legacy PHP causes most development to just evaporate as compatibility friction.

These were just a few first thoughts that came up, and it’s important to spend more time on clearly defining the problem before proceeding, and especially consider how this causes a global problem for WordPress aside from specific groups like administrators, hosts or developers.

We need solid arguments to get backers, and we’d also need to figure out who the decision-makers are, get them involved and their buy-in. If you are reading this and you are a lead developer, long-time core developer or another kind of stakeholder in the project, we would be happy to have you onboard, or at least join the meeting for next week to help us frame the problem of WordPress supporting unsupported PHP versions.

In the aftermath of the meeting, there have since been several good thoughts and discussions happening in the channel which should also be considered in next week’s meeting. If you’re interested, please take some time to browse through the recent chats in the channel.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and we will take this meeting to bring forward and discuss the problems that supporting an outdated PHP version in WordPress results in. If you have ideas but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

Multisite Recap for the week of July 17th

Office Hours Recap

The agenda for this office hours meeting was to review the current state of the multisite roadmap and plan out how to complete it for publishing as an official document on the make blog.

The meeting’s chat log

Attendees: @desrosj, @earnjam, @feshin, @flixos90, @jeremyfelt, @jmdodd, @johnbillion, @maximeculea, @spacedmonkey, @stephdau, @stevenkword

Chat Summary:

  • @jeremyfelt shared a link to the draft roadmap document for review.
    • @desrosj suggested using the Taxonomy roadmap posts an example
    • We agreed that the roadmap should be broken up into specific sections for REST API, Internal APIs, and Implementation, with each of those sections having their own users, sites, and networks areas.
    • We will also need a section of the document dedicated to “bootstrap” or file organization and load order. See #40647, #40948, #29684, #40646
  • The first priority should be the REST and Internal APIs. Once those are in better shape, they can be used to make improvements to the multisite UX/UI and we can focus on the different network admin screens that need attention.
  • Because networks are managed in widely varying ways, the primary goal of multisite should be to provide standardized data structures and low-level database APIs to support a range of network and multi-network implementations through plugins and custom code. The roadmap should reflect this philosophy.
  • We will need to discuss the “global” state (data spanning multiple networks) and make decisions on what should be implemented there. Right now users are the only global data, but even things like number of users are stored per-network and not globally.
  • Before getting too detailed on the actual roadmap document, we will spend the next few office hours meetings discussing specific items that will go into and affect the direction of the roadmap, including network meta, global state, and some Internal API decisions (See #40180 and #40228)

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub was to continue going through the list of multisite-related good-first-bug tickets for new contributors, review their status, and adjust keywords as necessary.

The meeting’s chat log

Attendees: @earnjam, @euthelup, @flixos90, @greatislander, @maximeculea

Chat Summary:

  • #40363Remove current_blog_ cache invalidation from clean_blog_cache()
    • Waiting for feedback from @jjj and @jeremyfelt over possible backward compatibility concerns with removing these
  • #41163: Display active theme name on Sites screen
    • This could make use of a wp_blogmeta table if it gets implemented, but in current form would require switch_to_blog() calls for each row in the list table.
    • Related to #40268
    • good-first-bug keyword removed since it will require further discussion across multiple tickets.
  • #41168: Identify the active theme when editing a site’s themes
    • Discussion revolved around disabling ability to disable the active theme to protect users from not being able to switch back after changing the theme.
    • Because of a possible inconsistency with network-enabled themes and a common paradigm of deprecating old themes by disabling them, the agreed upon suggestion was to only apply a label for the active theme and not change the enable/disable functionality.
  • #41166: .htaccess config should not be shown on network setup screen when Nginx is in use
    • Existing patch is in good shape, but needs minor update to use $is_nginx global
    • Suggested updates to the codex for subdirectory/subdomain configuration
  • #41169: Inaccurate descriptive text when adding a new site
    • Slight verbiage change to patch suggested.
    • Patch has since been committed and ticket closed.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Multisite Recap for the week of July 10th

Office Hours Recap

The agenda for this office hours meeting included a discussion around the introducing a wp_blogmeta table and related *_site_meta() functions to store arbitrary data for sites, particularly as a means to extend the future sites REST API endpoint. See #37923 for the respective ticket.

The meeting’s chat log

Attendees: @dac @earnjam @flixos90 @jeremyfelt @jjj @maximeculea @spacedmonkey @stephdau @stevenkword

Chat Summary:

  • There is a feature plugin available for installing site meta (the database table is called blogmeta for legacy reasons).
  • A consensus was reached for proposing a new blogmeta table which will be beneficial but not required for the planned REST API sites endpoint.
  • Priority for the 4.9 release will be the introduction of this new table with focus on adding a related meta_query to wp_site_query deferred to a subsequent release. See #40229.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub was to go through the multisite good-first-bug tickets. We worked off of this report with the aim of general gardening, adjusting keywords as necessary and removing good-first-bug keywords for tickets that are overly complex or have been open and without activity for an extended period of time.

The meeting’s chat log

Attendees: @danhgilmore @earnjam @flixos90 @pcarvalho @pmbaldha @stevenkword

Chat Summary:

  • #20537: Don’t spawn cron requests for suspended blogs.
    • We successfully applied the latest patch and provided a request for user testing.
  • #37799: Add progress indicator to “Upgrade Network” page
    • We successfully applied the latest patch and provided UI feedback.
  • #39213: Audit the network pages notices.
    • We successfully applied the latest patch and provided a request for user testing.
  • #39419: Explicitly globalize global variables in ms-settings.php
    • We successfully applied the latest patch and provided a request for documentation.
  • #41167: Remove help text duplication on Site editing screens in network admin
    • We successfully applied the latest patch and provided a request for a refreshed patch that resolved warnings from trailing CRs.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Dev Chat Summary: July 12th (4.8.1 week 4)

This post summarizes the dev chat meeting from July 12th (agendaSlack archive).

4.8.1 planning

  • @westonruter to commit #40951: Add legacy mode to Text widget to trunk, all trunk commits need to be merged into the 4.8 branch
  • Custom HTML widget needs to be amended to an existing file to be part of the minor release, agreement to utilize wp-includes/default-widgets.php solely for the benefit of 4.8.x
  • Testing, especially #40907 and #40951 (testing steps)
  • Beta – Monday, July 17th (soft string freeze, translations begin on about a dozen strings)
  • RC – Monday, July 24th (hard string freeze)
  • Launch – Tuesday, August 1st (🎉)

Editor / Gutenberg

General announcements

#4-8, #4-8-1, #core, #core-editor, #dev-chat, #feature-plugins, #summary, #widgets

PHP Meeting Recap – July 10th

This Monday the initial weekly PHP meeting took place. This recap is a summary of which ideas and decisions came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @flixos90 @jdgrimes @joyously @mte90 @ptasker @psykro @schlessera @screamingdev @tfrommen

Chat Summary

The topic we discussed this meeting was solely the current minimum PHP version requirement of WordPress, as it is the foundation that many code improvements are likely to rely on.

We came up with several ideas on how to raise awareness and increase pressure on hosting companies to upgrade PHP in a reasonable manner. We did not discuss these in detail yet, it was mostly a brainstorming session. Here is a list of what we came up with:

  • The first item has already been around (see #41191): There should be a nag in the WordPress admin dashboard indicating that an unsupported PHP version is being used. Security and performance are two examples of how to make an upgrade attractive to users. The most important part though will be to make it understandable and reasonable to people not tech-savvy.
  • The second item also exists already (see #40934): It should be possible to specify a minimum required PHP version for plugins. Once this is supported by core, it is likely that more plugins will raise their minimum requirement, so it will eventually be another way to make people aware. It should probably only happen in combination with the point above though, since otherwise there would not be a clear explanation of what PHP even is and why a supported version matters.
  • Related to displaying an admin notice, it could be valuable to gather data on which sites the notice appears to make a solid case for the business benefits of upgrading. However there were concerns expressed about privacy. The good part is that WordPress already collects some information during the update API requests and we could use some of that data to evaluate. A GitHub repository could be used to document the results.
  • Until core provides a solution, every plugin developer should consider showing a nag about the PHP version itself in case the plugin requires a higher version. This implies that the plugin’s main file must be PHP 5.2-parseable, even if the rest of the codebase requires a higher PHP version. Plugins that simply use modern PHP syntax in the main file provide a bad user experience by deliberately causing a fatal error and do not educate users about why the plugin does not work. There is a library by Yoast that can easily be integrated into any plugin and even provides more help than simply saying that the PHP version is outdated. It even makes sense to be integrated if the plugin supports PHP 5.2, in order to raise awareness, and the PHP versions for which it shows can be manually set by the plugin integrating it.
  • It could be helpful to have an article about the issues with a title like “Your WordPress might be insecure” and have that post appear in the admin dashboard news feed. This would be an easy way to raise at least some awareness and would not even require a WordPress update.
  • We could also reach out to the authors of very popular plugins and ask them to publish a post about the topic. It would reach a lot of WordPress users, also via newsletter.
  • The topic could be addressed in WordPress meetups around the globe. If you are a meetup organizer, consider bringing up this topic to educate people why they should upgrade and how to do it.

In addition to the above ideas we took the second half of the meeting to take a closer look at #41191 and think a bit more about the details of how the admin nag should work. These are the results of our discussion and the rough plan going forward:

  • The notice should recommend to jump to a PHP version >= 5.6. In addition it should highlight that jumping to a version >= 7.0 would be even better (especially for performance), but also carefully indicate that outdated plugins might have a higher chance of not working there properly.
  • The notice should initially only show on PHP 5.2 setups. While we want sites to go to a maintained version, this is a huge task and for WordPress to raise the minimum required PHP version it is most important at this point to decrease the number of sites running on PHP 5.2. Only showing it on 5.2 setups instead of everywhere below 5.6 will also reduce the support burden for hosts. Over time, once we are satisfied we can iterate to show the nag on higher versions as well, until we reach 5.5.
  • Once the number of PHP 5.2 sites is low enough, we can bump WordPress core’s minimum requirement to PHP 5.3. While that version is still outdated, the language-specific features of that version justify an upgrade more than any of the other planned upgrades, and furthermore the bump is already drastic enough like that. Jumping from PHP 5.2 to PHP 5.6 would likely result in a disaster. Again, over time we can iterate and bump the requirements until we reach a supported PHP version.
  • Once we are convinced that the time is right to move away from PHP 5.2, it would make sense to set up a clear roadmap for the subsequent version bumps. This gives hosts as well as developers a solid plan and overview so that they are prepared.
  • We still need to figure out which specific goal we should set, in order to determine when to bump the minimum requirement of WordPress to PHP 5.3. This will be a topic in a future meeting.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, and we will continue talking about the PHP version bump and related plans there with the goal of figuring out which of our ideas are realistic and which timeframe we should be prepared for. If you have thoughts on the above or other ideas but cannot make the meeting, please leave a comment on this post so that we can take it into account. See you next week!

 

#core-php, #php, #summary

Dev Chat Summary: July 5th (4.8.1 week 3)

This post summarizes the dev chat meeting from July 5th (agendaSlack archive).

4.8.1 planning

  • #40907 is committed to trunk, but needs user testing
  • #40951 has a good patch, but not committed yet and needs user testing
    • Main holdup is the best use of pointers (or another notice mechanism) to inform users to use the Custom HTML widget going forward for adding arbitrary HTML
    • Another possible use of pointers is when a user pastes HTML into TinyMCE, to correct years of pasting into the Text widget’s textarea
  • Aiming to make a 4.8.1-alpha release build to make it easier for those testing, will also note testing steps on respective tickets
  • Will schedule bug scrubs next week & post those times separately to Make/Core

REST API: image permissions model

Editor

General announcements

#4-8, #4-8-1, #core, #core-editor, #core-restapi, #dev-chat, #summary

Multisite Recap for the week of July 3th

Office Hours Recap

The agenda for this office hours meeting was to focus on the new sites CRUD API (not the REST endpoint).

The meeting’s chat log.

Attendees: @flixos90, @jjj, @maximeculea, @schlessera, @spacedmonkey.

Chat Summary:

  • Discussion about sites CRUD API (not the REST endpoint), see #40364. The goal here was to determine how we could refactor the site insertion and installation.
    • We’re planning to implement wp_insert_site()(for adding a row to the wp_blogs table) and wp_install_site() (for installing the site’s DB tables, populating options, etc). Both should be wrapped by a new wp_create_site() which will become a replacement for wpmu_create_blog().
    • Similarly, we will have wp_delete_site() and wp_uninstall_site() wrapped inside wp_remove_site(), which are counterparts of those before. The latter may not be clear enough, so we might need to find a better name. The naming discussion will continue on the ticket, and we’ll provide a summary about all the new functions.
    • About the technical details, a patch has been posted couple weeks ago. It seems to be a great first pass. However it passes around WP_Site objects which was the result of previous discussions, and there were concerns expressed at WCEU due to inconsistency with similar core functions. We therefore decided to use the common “$args pattern” instead for now, but maybe a chat could take place in #core-php at some point especially about consistency and new patterns.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub was to look through multisite tickets without a response and provide feedback.

The meeting’s chat log.

Attendees: @afragen, @andy, @flixos90, @ipstenu, @jmdodd, @maximeculea, @sergey, @spacedmonkey.

Chat Summary:

  • As we only had two tickets, we gave feedback and asked for more details to the first one, #40459.
  • The second one (see #41177) was more tricky. We had a chat about site deletion which is not triggering an AYS notification. As pointed, this should not be a JS Driven AYS but more be handled with a separate page which is showing up. A patch has been submitted.
  • In addition, we highlighted a great new feature for multisite development: Thanks to @loreleiaurora, it’s now easily possible to setup VVV development multisites for both subdirectory and subdomain setup.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Multisite Recap for the week of June 26th

Office Hours Recap

The agenda for this office hours meeting included/was continue the previous week’s discussion on component maintenance with a particular focus on onboarding of new contributors.

The meeting’s chat log

Attendees: @afragen @desrosj @drew @earnjam @flixos90 @jjj @maximeculea @pmbaldha @spacedmonkey @stevenkword

Chat Summary:

  • Weekly agenda and recap posts should be published. Preferably responsibility for these should rotate between contributors.
    • To make the process of writing such posts easier and more consistent, boilerplates are available as GitHub gists (for agenda posts and recap posts). These are drafts and open to feedback, but should be used as a foundation for new make posts from now on.
  • Regarding new contributors, the main priority is to ensure those who are interested find their spot. It should be as intuitive as possible where and how to help.
    • Long-term contributors, particularly the person running the meeting should make sure to ask who is around initially and preferably reach out to new people after the meeting per DM to offer help. Even those who are only reading along should be encouraged to let everyone else know they’re around and interested.
    • Having a multisite setup available in the basic VVV configuration would be very helpful. There is an inofficial temporary solution available, which is not quite the best approach to solving the problem, but yet it should be considered to be added in the official setup until a better solution is available (which might take some time to work on). This topic will be picked up again once VVV maintainer @jeremyfelt is back around.
    • More efforts should be put into gardening tickets with the good-first-bug keyword. Several of those tickets already have a patch, but are not obviously highlighted as such, others have turned out to be far too complex, making the search for such tickets time-consuming and possibly frustrating. This particularly affects the agenda of weekly ticket scrub meetings.
    • Anytime when looking at tickets, it is important to not only take tickets in the “Networks and Sites” component into account, but also those that have the “multisite” focus applied. The latter group gets overlooked by the multisite team too often. This Trac query is a good starting point.
    • An idea from the community summit about a mentorship program was brought up. It may be useful to invest possibilities to dedicate a specific mentor to each new contributor that is interested. This should be discussed in a broader scope though, together with other components.
    • A common issue for new contributors is that sometimes Trac tickets are overlooked or no action taken. Sometimes even when tickets are assigned, it’s a long time for any action or response. Regardless of whether a ticket simply needs more discussion, whether it is considered low priority or too complex to tackle at the moment, the multisite team should ensure to always provide at least a response about why a certain ticket is in its current state. More precise workflow keywords could help describe a ticket’s state as well. Having a weekly ticket scrub is at least a good starting point as it gives a chance to look at those tickets more regularly.
    • A few minor workflow issues with tickets could be improved. An idea was to automatically apply the has-patch keyword once a new patch is uploaded.
  • While the original agenda included discussing the improvements to the sites API, this discussion was postponed to a later meeting.
  • Several contributors were not aware of the weekly ticket scrub. It should be added to the list of meetings on https://make.wordpress.org/core/. A further idea was to set up reminders for both meetings on Slack.

The next office hours will take place on Tuesday 16:00 UTC. An agenda for it will be posted in advance.

Ticket Scrub Recap

The agenda for this ticket scrub included/was to look through multisite tickets without a response and provide feedback.

The meeting’s chat log

Attendees: @andy @desrosj @earnjam @flixos90 @jmdodd @kraft @pmbaldha @sergey

Chat Summary:

  • We got the count of tickets without a response from 14 to 6. One ticket was committed, the others are either on a good way or further feedback or updates have been requested. The process will continue next week to hopefully get that list to a count of 0.

The next ticket scrub will take place on Monday 17:00 UTC. An agenda for it will be posted in advance.

If you were unable to attend one of these meetings but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in one of next week’s chats. See you next week!

#4-9, #multisite, #networks-sites, #summary

Dev Chat Summary: June 28th (4.8.1 week 2)

This post summarizes the dev chat meeting from June 28th (agendaSlack archive).

4.9 ideas

4.8.1 planning

  • #40951 & #40907 will be core to the 4.8.1 release being targeted around the last week of July
  • General bug scrub to be scheduled after the 4th of July holiday on the 4.8.1 milestone
  • Component maintainers please review your 4.8.1 milestone and punt to Future Release / 4.9 as necessary
  • Reminder that we are “approaching 4.8.1 tickets as more traditional regression types of issues”

Editor update

Customize update

  • appreciate more people testing 40951.3.diff
  • also appreciate testing of the HTML widget in trunk (see #40907)

REST API update

  • had a lot of new docs contributions at WCEU contributions day
  • have some momentum and hope to build upon it in coming weeks

Dev chat coordination

  • @jbpaul17 looking for 1-2 others out there to help run the weekly dev chats similar to how the Core Weekly Updates are split up
  • A great way for product/project management or otherwise non-engineers to help contribute to WordPress Core
  • Please ping @jbpaul17 if you have interest in helping out!

New contributor bug scrub/open office hours

  • idea is a weekly bug scrub/open office hours focused on new contributors
  • would include tickets tagged good-first-bug and any tickets new contributors wanted to work on
  • Likely to schedule for Wednesdays at 19:00 UTC
  • @adamsilverstein, @welcher, @stevenkword, & @flixos90 to help run the meetings
  • Please ping @adamsilverstein if you have interest in volunteering as well

General announcements

  • @m1tk00: looking for help with the Gallery Widget in the Customizer regarding the edit button
    • need to know how to send the already selected ID’s, when someone wants to edit the gallery
    • will ping @obenland or @timmyc in #core-customize for help
  • @enricosorcinelli: #21676 patched and awaiting review, how to get it more attention?
    • added needs-testing to the ticket, will ping @obenland as Themes component maintainer to review
  • @pbiron: would like to start a “feature plugin” project to work on rewriting the exporter
    • would like to rework ALL of the XML related code in core (e.g., using XMLWriter instead of echo statements, etc)
    • using XMLWriter and with some pretty drastic changes to the WXR markup
    • should be putting the 1st version up on GitHub in few days
    • also written an XML Schema for WXR 1.2
    • will add the feature proposal as a comment to the 4.9 wishlist on last week’s dev chat summary
  • @flixos90: thinking about ways to improve Trac workflow
    • wondering whether it would be possible to automatically set a has-patch keyword once a patch is uploaded?
    • It’s a bad experience for new contributors to search through tickets without a patch, but finding ones that already have one
    • will drop by #meta-tracdev to continue the conversation
  • @jnylen0@enricosorcinelli working on #39732 and #39730
    • 39732 is a sanity improvement and a follow-up to work done around 4.7 in the API, should land soon for 4.9, but it would be good to get more eyes on it especially someone who has worked on comments before
    • 39730 may as well land at or around the same time as the above
  • @welcher: would love some eyes on Load word-count and do not allow our wp-utils script to clobber it

#4-8, #4-8-1, #4-9, #core, #core-editor, #core-restapi, #dev-chat, #summary