Media Meeting Recap – February 15, 2018

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 15, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@mikeschroder @antpb @blobfolio @flixos90 @jdub233 @sergey @desrosj @azaozz

Transcript: Read on Slack

Gutenberg

  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones have been re-arranged to make it easier to see what is going on.
  • Add block playlist: A discussion took place around how mediaElement should be added to Gutenberg. The two options discussed were to include it in the npm package list or make a global instance of Core's mediaElement Library. Consensus was to go with Core's implementation. @antpb is blocked on the playlist block with lack of mediaElement component. He is working on building a mediaElement REACT component that will need to be utilized in the audio and video blocks. Before this is complete enough to merge, he'll need some help understanding how to make the Core library globally accessible in Gutenberg.

5.0 Tickets

The next part of the meeting was spent on tickets in the next major milestone (5.0).

#33979 – Add filter for 'post_gallery_item'
#38228 – Add filter to default gallery shortcode output

Discussion around how granular gallery filters should be. With #3379 we gain a filter to add  styles individually per item in the Gallery. It was discussed that we will need tickets to add more granular filters going forward for captions and other image attributes. From @desrosj : "Currently the shortcode builds the HTML string as it goes. I think if the attributes were built in an associative array, that could just be filtered, and then the element built at the end. That could allow additional attributes to be added, widths to be changed for specific images making it easier to do different grid layouts." This sparked the question above around how Gutenberg will handle backwards compatibility with filtered attributes.

The following tickets need a combination of code review and approval:

  • #33979 – Add filter for 'post_gallery_item'

Seems good to go as a first step towards more granular Gallery filters if it won’t make it more difficult for Gutenberg to provide backcompat.

Next Meeting

The next #core-media meeting is set for Thursday, February 22, 2018 at 1900 UTC. Hope to see you there!

Dev Chat Summary: February 14th (4.9.5 week 2)

This post summarizes the dev chat meeting from February 14th (agenda, Slack archive).

4.9.5 planning

  • We’re looking for nominations for people to lead this minor release, self-nominations are very much welcome. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • No timeline set for 4.9.5, but minor releases tend to run 6-8 weeks so we’ll go with what fits with the release leads’ schedule
  • Potential focus for 4.9.5 could be support of foundational work needed to support Gutenberg

Updates from focus leads and component maintainers

  • The PHP team shared a recap from their recent meeting, thanks again to them for documenting that discussion
  • The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.
  • The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

  • Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.
  • Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work
  • Meta#3459 created to track this work

General announcements

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #core-php, #dev-chat, #gdpr-compliance, #summary

PHP Meeting Recap – February 12th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

The agenda was to discuss which version to include the notice in and how to deal with the dismissal functionality of the notice.

Release Plan

  • After requesting feedback in the #core channel, there were some concerns expressed about publishing the notice in a minor release (like 4.9.5), particularly because a notice like that suddenly being thrown from a minor release may seem weird.
  • However the amount of users affected by this would be very low, since only users on PHP 5.2 are initially targeted.
  • Releasing sooner than later would allow for quicker feedback and stats, to iterate based on those.
  • The decision was to go with the 5.0 release for now. When the notice has been merged into trunk, it can be reevaluated whether it should be merged in the minor release branch.

Notice Dismissal

  • Four initial possibilities were suggested to be considered:
    • The notice shouldn’t be dismissible at all.
    • The notice should be permanently dismissible.
    • The notice should be dismissible, but come back every month.
    • The notice should be dismissible, but come back every core update.
  • @clorith expressed concerns about heavier support load when bringing the notice back “unexpectedly”, like after a month. On the contrary, the notice being persistent is part to the solution, so people trying to get rid of it otherwise are doing it wrong.
  • If it needs to be brought back, that should preferably happen per (major) update.
  • Option 4 ended up to be the most viable one out of the suggestions.
  • @SergeyBiryukov then suggested to check how the existing Browsehappy notice does that. It was quickly discovered/remembered that the Browsehappy notice is not actually implemented as an admin notice, but as a dashboard widget.
  • That approach sounds promising too, so @flixos90 added he’ll work on an alternative patch for an implementation as dashboard widget.

Next week’s meeting: Admin Notice vs. Dashboard Widget

The agenda for next week is to decide on one of the following approaches to pursue:

Screenshots

Servehappy Admin NoticeServehappy Dashboard Widget

Benefits of admin notice

  • Very visually prominent.
  • Quick overview of details, layout similar like known welcome notice.

Benefits of dashboard widget

  • Not as easy to accidentally click away without looking, as fully dismissing requires to open screen options first.
  • Only shown in dashboard which appears to be more appropriate than everywhere.
  • Follows Browsehappy implementation, so less new code and tweaks required.

If you have any suggestions or feedback before the meeting, please comment on the Trac ticket or the individiual pull requests if applicable.

#core-php, #servehappy

Dev Chat Summary: February 7th (4.9.5 week 1)

This post summarizes the dev chat meeting from February 7th (agenda, Slack archive).

4.9.3 + 4.9.4 update

  • 4.9.3 went out on Monday, 4.9.4 went out on Tuesday; note technical details behind 4.9.4
  • Note final paragraph from the 4.9.4 technical details post:
    • What we’re doing to prevent this happening again We’ll be making a follow up post after we’ve been able to determine how to ensure that this never happens again. We don’t like bugs in WordPress any more than you do, and we’ll be taking steps to both increase automated coverage of our updates and improve tools to aid in the detection of similar bugs before they become an issue in the future.
  • If you have ideas, solutions, or are able to support increasing “automated coverage of our updates” and improving “tools to aid in the detection of similar bugs” then please gather those and add them to the pending post on this topic.
  • @jbpaul17 to see if any process-related changes might help
  • @sergey also asked for ideas on how we can improve the quality and consistency of our code reviews
  • @helen spoke with @dd32 and will look into a way to test auto-updates
  • @desrosj noted that automating some parts of the release process might help

Updates from focus leads and component maintainers

General announcements

  • Comment thread from today’s agenda post on topic of security not able to be addressed as no one from the Security team was present, but @aaroncampbell provided a response ahead of time:
    • Okay, so this is the DoS issue with load-scripts.php and load-styles.php: Basically, the best mitigation for this is at the network level. Hosts and WAFs can rate limit this in a way that makes a lot more sense than anything WordPress can do. Caching would also be extremely useful in this case. Something that we _could_ do is limit the number of scripts that could be loaded at once with those, but the problem with that is all it does is reduce the load by some relatively marginal amount.
  • @leemon asks for review on #43226; @drewapicture to take a look
  • @binarymoon asks for review on #38545; looking for someone to give feedback and get to an agreement so this ticket can move forward
  • @joyously asked whether New Contributor meeting was still occurring; @desrosj to speak with other facilitators and get the meetings re-started
  • @williampatton shared insights into his experience being a deputy release lead on 4.9.3; encourages others to contribute as leads, noting core commit access is not required, recommends pairing with experienced lead; highlighted permissions issues that should be resolved; thankful for support from others during the release process; will help elaborate on minor release handbook page
  • @chanthaboune highlighted the need to “lessen that cognitive load for new/learning release leads”, need to call out contingencies and what’s time-specific; in general how can we make the contribution process easier

Next meeting

The next meeting will take place on February 14, 2018 at 21:00 UTC / February 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #4-9-4, #4-9-5, #core, #core-editor, #core-media, #dev-chat, #security, #summary

Media Meeting Recap – February 1, 2018

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 1, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@antpb @blobfolio @desrosj @karmatosed @mikeschroder @postphotos

Transcript: Read on Slack

Gutenberg

  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones have been re-arranged to make it easier to see what is going on.
  • Milestone #33 is coming up. There are two media issues, but the primary focus is: Add block playlist. A decision was reached to punt this issue to 2.3. @antpb needs some background on the mediaElementobject is used for the media player.

4.9.4 (now 4.9.5) Tickets

The next portion of the meeting was dedicated to going through blessed tickets in the next minor milestone. All three were deemed in a good place with good direction.

  • #42968 – Media: Grid View: new upload, file is in the wrong position in the grid until after upload is complete
  • #43201 – PHP Warning: count(): Parameter must be an array or an object that implements Countable in /wp-includes/media.php on line 1206
  • #42724 – Options Media page hides breaks on desktop

5.0 Tickets

The next part of the meeting was spent on blessed tickets in the next major milestone (5.0).

#42919 – Unable to upload files with the AAC extension

Discussion around whether AAC files could be embedded lead to the realization that AAC also needs to be added to `wp_get_audio_extensions()`. Firefox appears to have a few issues with AAC. Some testing needs to be done to see if this can be done in the same ticket, or if a new one is more appropriate. @desrosj will do some digging.

The following tickets need a combination of code review and approval:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget
  • #42463: Poor Description of add_image_size Params
  • #42017: Parse the creation date out of uploaded audio files

5.0 Suggested Tickets

#9257 – EXIF GPS data

Has good direction, but needs some feedback to make any adjustments. #42479 was closed as a duplicate on the premise that there is no GPS information in audio/video besides any in the associated image. In his initial testing, @desrosj remembers there being some GPS information on video files, but more testing is needed before it can be re-opened. Files from popular devices would need to be provided as well.

#43046has_image_size() returns false for Core image sizes

Backwards compatibility issues need to be fully explored for this ticket. At minimum, the inline documentation should be updated to more accurately reflect what is happening in the function. At maximum, a new boolean parameter could be added indicating whether core image sizes should be included in the list checked against. An example of where this may be very useful is preventing issues when a plugin or theme removes a core image size (if this is possible – needs research).

Next Meeting

The next #core-media meeting is set for Thursday, February 8, 2018 at 1900 UTC. Hope to see you there!

Dev Chat Summary: January 31st (4.9.3 week 3)

This post summarizes the dev chat meeting from January 31st (agenda, Slack archive).

4.9.3 update

Updates from focus leads and component maintainers

Servehappy

  • Question from @azaozz in latest meeting: What if the PHP education page (codename "servehappy") was not on any .org-related website, but inside of core?
  • We'd like to ask for feedback on this, what are all your initial feelings on that? Note that this is separate from the prompt for the user to switch the PHP version in their hosting account.
  • Some considerations:
    • The main condition for this to happen is to have the entire content powered by the .org API. The content will be highly dynamic and may need adjustments regularly, so we must not be dependent on core releases to change it.
    • A new API endpoint would need to be built for that purpose that should send the content of all sections of the page, to some degree targeted to the current request. Parameters like the PHP version active, plugin slug (in case the user is sent to the page because a plugin requires a higher PHP version), data about the host (if available), would be part of the request. This would allow the content to target the user's problem as well as possible.
    • All content that endpoint returns should not be hard-coded, but easily manageable through a backend (maybe a special section in make.wordpress.org/core/?).
    • How is it possible to change the .org API? Who has access? We'd need to figure out how the process of working on that could be streamlined.
    • Summary of thoughts from PHP meeting recap
  • Next step is for the Servehappy team (including @azaozz) to discuss this during the next PHP meeting (on Monday 16:00 UTC) and come back with a recommendation

General announcements

  • @afercia uncertain about what can go in a minor release, specifically about fixes or small enhancements that require a dev note given that minor releases auto-update
    • Changes that require a dev note in a minor release, with such a short notice, don’t give plugin and theme authors the time to update.
    • As further changes to the minor release policy, best to have recommendation prepared for upcoming devchat

Next meeting

The next meeting will take place on February 7, 2018 at 21:00 UTC / February 7, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #core, #core-editor, #core-php, #dev-chat, #documentation, #js, #minor-releases, #servehappy, #summary

PHP Meeting Recap – January 29th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

The agenda for today was to discuss UX mockups and the hosting situation.  However, @jaymanpandya was not around for the meeting and we don’t have any mockup update so we were unable to discuss.  That portion of the meeting was postponed until next week.  @azaozz was present at the meeting and we spent the entire meeting interacting with him with regards to this comment he made.

He expressed some concerns regarding both content (what the servehappy page contains) and location (where the servehappy page lives) of the servehappy page.

For reference and as a reminder, the servehappy information page is the first initiative of the entire project aimed for launch in the first quarter of 2017.  You can read more about it (and how it fits into the larger “servehappy” project in the roadmap, the project readme, the related trac ticket and see the current draft.  Also keep in mind that “servehappy” is a codename for the project.  It won’t necessarily be reflected in any final form for the public facing content.

By the conclusion of the meeting we arrived at the need to focus primarily on location as it is something we haven’t fully worked out yet (it hasn’t received the same level of discussion/planning as the content).  We identified some initial factors that should influence where this servehappy information page lives.  For the purpose of this summary, I’m going to list the headings and capture some of the related discussion under each heading.

Where should the “servehappy” information page  live?

Here’s some factors that can influence the location:

Factor: Privacy

This factor concerns the privacy of any information shared by site owners/sites for the servehappy page generation/content.

Some related background:

  • this landing page in it’s initial form is intended to be a more general encouragement to upgrade PHP, why one should upgrade PHP, and some instructions on how to upgrade PHP (including linking out to various specific host instructions).
  • When the admin notice is implemented, one initiative discussed is to link from that to this page and send along with the link via url parameters some basic information (such as php version and possibly plugin slugs that are on old php versions) that allow the servehappy page to be tailored more directly to the visitor.

Related comments in chat (this is not in chronological order but has been grouped for relevance):

  • concern over passing data via parameters and the privacy implications
  • php version and php info is already sent to the wp.org servers
  • “They are running an unsupported PHP version.” That’s all we need to know (@schlessera)
  • I see it similar to how you prepare a link that contains the language as a URL argument. Don’t think that’s a privacy issue (But IANAL). (@schlessera)
  • access logs can link ip/referring domain to PHP version… (@nerrad)
  • Before we talk about “privacy” issues, I think it’d be good to identify exactly what you think we plan on sending to this page and what is concerning from a privacy point of view instead of ambiguous assumptions. (@nerrad)

Factor: Maintainability

This factor concerns the degree of effort needed to implement, maintain and update the content and anything else related to this server.

Factor: User Trust

This factor concerns how likely user’s will act on something when it conveys something they can trust (i.e. wp-admin, vs external hosted page)

Proposed locations for the Page:

In the course of the meeting we arrived at a discussion on two primary locations where the servehappy information page would be hosted/served.  They are summarized below along with the relevant discussion pertaining to each location.  The plan is to bring this to a future core dev meeting so that we can get some opinions from others in the wider WP core team/community to help with the decision for where this content will live.

External Site:

This includes the potential of being a custom domain/separate site, WordPress codex, or as a page on WordPress.org

  • privacy concerns
  • We’ve already discussed just using an internal WP-org page, but it would be a less focused layout, and be not as optimized to achieve the actual goal. (@schlessera)
  • Seemed to be general consensus that maintaining the content would be easier in this location.

WordPress Core (powered by WordPress.org API)

  • Regarding why the external page, the core notice about PHP initially shouldn’t overwhelm the user immediately with tons of content. A page inside of core would be an alternative, but we would like it to be independent of core version releases. An alternative could be to have a page IN core, however its entire content would need to be powered by the wordpress.org API, so we would need a new endpoint for the education parts. (@flixos90)
  • ‘read more..’ in the notice could point to the page in core.
  • We need to keep in mind though, the more WordPress-centric we build it, the lower the possibility to open it up to collaboration with further projects. That may not be that important of a goal anyway, but something to consider. (@flixos90)
  • We will try to make the content as targeted as possible, but the more targeted it becomes the more information we need to have about different hosts and the more data the new API endpoint for the page needs to support. The fallback will be to send an email to the host with predefined content. (@flixos90)
  • With the API, you cannot easily add/remove elements. Either it’s one blob of content (which will make management a hassle) or it’s separate sections, and we cannot easily add/delete things. (@schlessera)
  • Again, I also want to emphasize it’s hard to tweak the .org API because there aren’t many who have access, but as long as all the actual information is not hardcoded somewhere in there, it sounds alright to me. (@flixos90)
  • I think we could easily manage the content as separate sections and send these individual sections over with the API. And then we could also send call to action data, like host-specific links or a fallback. (@flixos90)
  • We should build the API in a way though that the content is easily editable without any meta trac interaction required. Where could that happen? Which backend of a .org site could power that API? (@flixos90)

Next week’s meeting

  • Next meeting will take place on Monday February 5, 16:00 UTC in #core-php
  • Agenda: Followup on the location discussion, hosts situation, feedback on mock-ups for the PHP Compatibility checker plugin (which will promote the servehappy page), feedback on mockups for the servehappy page.
  • If  you have comments/feedback/suggestions about any of the above agenda items, but cannot make the meeting, please leave a comment on this post so that we can take them into account.

To prepare for the next meeting, here are some mockups for the PHP Compatibility checker:

  • https://xd.adobe.com/view/3f36c02e-6bbb-471c-b52f-78b8f9b7fbee/?fullscreen
  • https://slack-files.com/T024MFP4J-F8ZQ08V4Z-e421fe42bb

PHP Meeting Recap – January 22nd

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

  • The #design team has acknowledged our call for design help for servehappy and added a corresponding task in their Trello board. @jaymanpandya has stepped forward and was assigned this task.
  • We summarized again how we’re envisioning the site:
    • stand-alone design, as including it into the wordpress.org page design would reduce the impact and hinder proper optimization;
    • targeting site owners, with the option to make the content adapt to URL parameters for more precise targeting;
    • focused on easy consumption and avoiding overwhelm, with additional, more detailed content available as needed;
    • hosted on wordpress.org infrastructure and showing a small mention to the wordpress.org project;
    • not collecting usage data or feedback through the site, as that will likely get vetoed.
  • @jaymanpandya is an experienced UX designer and will work on a first set of mockups so that we can get a feel for how this might work as a real site.

Next week’s meeting

  • Next meeting will take place on Monday, January 29, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss UX mockups and hosting situation.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy

Dev Chat Summary: January 24th (4.9.3 week 2)

This post summarizes the dev chat meeting from January 24th (agenda, Slack archive).

4.9.3 planning

  • 4.9.3 beta was supposed to be built on Tuesday, but some tickets were still actively being worked on, so it will be done after dev chat
  • @sergey to post on Make/Core with notable fixes, things to test, and link to JSHint dev note
  • RC and release are still planned for 29th and 30th, respectively
  • Note: 4.9.3-beta1 is out, post is still pending

JSDoc initiative

  • @atimmer prepared a Make/Core post to announce the JSDoc initiative
  • Feedback on the draft is welcomed, send Slack DM to @atimmer with updates
  • It looks a lot like the inline hook documentation and the setup is the same: file by file, everyone can claim a file, at the end all files will be documented
  • @kadamwhite to publish post when its ready

General announcements

Next meeting

The next meeting will take place on January 31, 2018 at 21:00 UTC / January 31, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #core, #dev-chat, #documentation, #js, #jshint, #summary

Dev Chat Summary: January 17th (4.9.3 week 1)

This post summarizes the dev chat meeting from January 17th (agenda, Slack archive).

4.9.2 release

  • 4.9.2 was released yesterday.
  • This is a security and maintenance release for all versions since WordPress 3.7. We strongly encourage you to update your sites immediately.

4.9.3 planning

  • Updated timeline is 4.9.3-beta1 on Tuesday, January 23rd; RC on Monday, January 29th; and still aim for Tuesday, January 30th for release.
  • Currently no major bugs, so planning for a regular maintenance release.
  • Bug scrub times will be announced on Make/Core.
  • 4.9.3 beta will get a Make/Core post to help get people's attention on it.

Updates from focus leads and component maintainers

  • The Editor team recently released Gutenberg v2.0 and will begin regular Gutenberg bug scrubs at 17:00 UTC on Thursdays separately from their weekly meeting. Please ping @jbpaul17 (@jeffpaul on Slack) if you have interest in assisting with bug scrubs.
  • The REST API team wants to get dev opinions on a register_meta change proposal that will becoming to a Make/Core post soon.

General announcements

  • @jorbin: Reminder that breaking changes (even if they are only breaking code that was publicly released for a few months) should always have a Dev Note published on Make/Core.
    • 4.8 and 4.9 had shorter beta/RC windows. It would be interesting to analyze and see how that affected bugs reported during those windows and in the near term after release. It would also be interesting to see how that affected the number of reverts. That data might show longer beta/RC windows are necessary, but we should not rush a decision without numbers backing up the analysis.
    • Note that @jbpaul17 added a step to check for dev notes to the Releasing Minor Versions handbook page.

Next meeting

The next meeting will take place on January 24, 2018 at 21:00 UTC / January 24, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-2, #4-9-3, #core, #core-editor, #core-restapi, #dev-chat, #gutenberg, #summary