JavaScript Chat Summary, June 11, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Component Props Documentation

Slack Conversation

Question: How can we eliminate human error from components documentation?

Context: @dsifford‘s recent pull requests can sort of speak for themselves so far as demonstrating the current inaccuracies in components documentation. He’s discovered them while working on type definitions added to DefinitelyTyped for @wordpress/* packages and he’s tracking progress on Trello board. If anyone is interested in helping the effort let us know.

Options discussed:

  • Improve current JSDoc documentation.
  • Add support for React.PropTypes.
  • Introduce TypeScript.

Action items:

Open Floor

Slack Conversation

Some of us are traveling to WordCamp Europe next week, so we agreed to cancel the meeting planned for next Tuesday and pick up again on June, 25th.

#core-js, #design, #javascript

Editor chat summary: June 5th


This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, June 05, 2019, 13:00 UTC.

Announcement

@danr, @andraganescu and @noisysocks will be starting up a new contributor triage meeting in #core-editor for APAC timezone.

First meeting is planned on Thursday 13th July at 6AM UTC and then every two weeks.

Tasks Coordination

Open Floor

  • @manooweb asked about security in development with React, updating docs to cover the same was agreed upon.
  • @soean asked about agenda for Contributor day at WCEU.
  • @gziolo shared rough agenda for Contributors day at WCEU:
    • onboard a few new contributors, collect the feedback and work on documentation improvements to make the process smoother.
    • go through the list of open issues trying to identify tasks which would be an excellent fit for new contributors.
    • explore how we could automate the detection of pull requests sent by new contributors to ensure they get enough support from others.
    • triage issues looking for those which can be closed because they are no longer relevant, are duplicates or should be moved somewhere else.
    • triage pull requests seeking for those which can be closed, need to be updated or can be merged after short review and testing session.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

#meeting-notes, #core-editor, #editor, #gutenberg

JavaScript Chat Summary, June 4, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: June 18 Meeting Planning

Slack Conversation

Neither @adamsilverstein nor @aduth will be able to host the meeting scheduled for June 18. Is there anyone willing to host that day, or should we plan to cancel the meeting for that week? This is the Tuesday before WordCamp Europe, so there may be lower-than-usual attendance.

Decision: There will be no JavaScript meeting on June 18.

Agenda: Dependabot Follow-up

Slack Conversation

Discussed in last week’s meeting, a bot has been submitting security update pull requests to the gutenberg-examples repository. It was discovered that this was a default behavior from GitHub’s acquisition and integration of Dependabot.

Proposal: If there will be a workflow which requires corresponding upstream patches for the WordPress core project, we should document it.

Since the pull requests are not being submitted to the Gutenberg repository, this workflow may not be necessary. The examples repository is standalone and is not mirrored upstream in any fashion.

Agenda: Broader Impact of Gutenberg Patterns

Slack Conversation

@nerrad raised a concern that patterns developed in Gutenberg may conflict or overlap with patterns in the broader wp-admin interface.

Example: The “Snackbar” iteration is relevant in the conversation about notifications in the administration screens.

Question: Are features which land in the plugin guaranteed to make their way to stable WordPress release? Answer: It’s not intended to be a given, iterations and feedback are to be solicited, and features can be guarded behind feature flags or dropped altogether. But ultimately, the current release workflow does result in most of these being put on a track toward a stable release.

Question: How do we avoid siloed decision-making?

Considerations:

  • These should be discussed beforehand in relevant teams with audiences outside Gutenberg specifically (#design was raised as having discussed this specific “Snackbar” iteration).
  • There should be some Trac conversation for the broader implications of the specific feature, and if/when this exists, regular updates should be provided to share iterations and solicit feedback.

Next Steps: Discuss the question of process for how decisions made in Gutenberg are handled in making their way to WordPress core. What are the problems, and who makes the decisions? Consider as a discussion point for a future devchat.

Open Floor

Slack Conversation

@nerrad shared that the useDispatch React hook is now available for use in Gutenberg master (pull request, documentation). This complements the useSelect React hook which had been merged last week (pull request, documentation).

@nerrad plans to publish a post about these new hooks on his own personal blog, and may cross-post or adapt the content into a post for Make/Core (this blog).

@gziolo shared that he has been making progress on improvements to the @wordpress/scripts package tools, including default paths for linting scripts, ensuring the build folder is ignored from validation (pull request), and supporting multiple entry points for build (pull request).

#core-js, #javascript

Dev Chat Summary: May 1

Announcements

Josepha (@chanthaboune) has published a 5.0 retrospective wrap up. There are two questions at the end of the post that you are encouraged to discuss in the comments. Thank you for the time and care you have put into this, Josepha! You can find this retrospective wrap up at the following post:

5.2 updates

RC2 is planned for tomorrow with the target release date ~5 days (May 7).

Josepha brought attention a few items pending:

  1. #47093 – related to the recovery mode email translations. There’s a potential solution being worked on, but it needs review.
  2. #47070 – related to the Recovery Mode Exit button. Design input and a patch is needed, and then it will also need review.
  3. #46901 – related to the About page. A final patch is incoming that will need review.

Most tasks pending for the above tickets have an owner, but it was mentioned by Jonathan (@desrosj) that particular testing and attention to #47093 – recovery mode email translations is encouraged and appreciated.

@audrasjb asked for an idea of the timing for RC 2 tomorrow. Josepha mentioned that it will likely be in the windows of between 1430-1630 UTC and again around 2030 UTC. The earlier window is preference.

5.3

It would be great to start planning scope/teams/timing etc. for 5.3. (potential agenda item for next week!) Jonathan mentioned that we may be able to start the 5.3 branch in trunk after RC2 has released.

Open Floor

WP Campus’ Accessibility audit released today

A big thank you to WP Campus for this important initiative! You can find the blog post announcing the audit here: https://wpcampus.org/2019/05/gutenberg-audit-results/

#5-2, #core-editor, #design, #devchat, #summary

#core-privacy April update

This is a cumulative update for #core-privacy office hours and bug scrubs held in April 2019.

Office hours are held every Wednesday at 19:00 UTC in the #core-privacy channel on Making WordPress Slack. Bug scrubs are Mondays at 15:00 UTC.

5.2 release

5.2 has been a monumental team effort by core-privacy. The team has shipped all 24 of its tickets earmarked for the release. These included 15 bugfixes and 9 enhancements.

Special props go to @garrett-eclipse for being the driving force behind the team’s 5.2 ticket success.

The “biggest win” was #44005, introducing the new privacy policy page helpers.

General fixes include:

#46098 – The Privacy Policy guide help notice is now displayed on both the classic editor and the block editor.

#44707 – Users are now able to make additional requests when identical previous requests are in a complete or archived state.

#44644 – The ‘Download Personal Data’ admin action no longer triggers a completion of the request.

Also in 5.2 some privacy nags were removed; post-4.9.6, these notifications had served their purpose:

#45999 – Remove the Privacy Pointer

#46819 – Remove the Privacy Bubble

Some i18N-Privacy wins were:

#44721 – The Personal Data Erasure Fulfillment email is now in the User’s Locale

#46056 – The Personal Data Export email is now in the User’s Locale

Tickets shipped since the March team update included #44175, #44644, #44047, #46819, and #46098. Props @knutsp, @desrosj, @joshuawold, @birgire, @mechter, @subrataemfluence, @xkon, @saimonh, @audrasjb, @dejliglama, @ianbelanger, @iandunn, @pento, @sergeybiryukov.

@earnjam wrote a post in Make/Core on the developer-focused privacy updates in 5.2.

@williampatton wrote a dev note in Make/Themes on the new privacy policy page helpers coming in 5.2.

5.3: export and erasure

For 5.3, @xkon would like the team to focus on finalising all outstanding issues with export and erasure requests. @audrasjb has given @xkon access to his repo for the front-end forms for export and erasure, with a view to using this as our first team feature plugin. (#44013)

5.3: privacy notice updates

The team has discussed #44538, #44669, #46687 as an opportunity for collaboration with the #design team.

Plugin privacy audit

@idea15 has finished writing beta version 1 of the plugin privacy audit workflow, with the help of feedback from many team members and plugin developers. Please feel free to test the workflow on your plugin and provide the team with feedback in #core-privacy.

WordCamp Europe

@idea15 has signed up for a slot for the team at the WP Cafe at WCEU. This will be a friendly hangout and chat space with no set agenda.

As with last year, #core-privacy will have a team table at the WCEU contributor day. As with last year, @idea15 @xkon @pputzer @postphotos will take turns secretly disconnecting the wi-fi.

Cross-project privacy cooperation

Members of the #core-privacy team who participate in the cross-project privacy initiative will be participating in the Mozilla Global Sprint in May to standardise file formats for data portability exports and imports across our CMSes, and to identify the export and import functionality which may need to be created within each project. All are welcome to join in. Dates TBC.

Conference talks

New on WPTV:

@rhyswynne at WordCamp Edinburgh 2018: How to integrate the 4.9.6 privacy features into your plugin

@mainplus at WordCamp Belfast 2018: Follow the data

@riankinney at WordCamp Rome 2018: The differences between U.S. and EU privacy law

New talks:

@idea15 participated remotely in a privacy BOF at Drupalcon Seattle on behalf of the #core-privacy team.

@pputzer gave an outstanding talk at WordCamp Vienna on 27 April focusing on active #core-privacy tickets from a developer/site owner perspective. The slides are available here.

Other matters:

@javorszky started a review of the wp.org privacy policies which is currently active and available for discussion & review here.

Dev Chat Summary: April 24

Announcements

Josepha (@chanthaboune) is working on bringing us a 5.0 retrospective wrap up, a project digest, and a team lead interest form. She is planning to publish the retrospective wrap up this week and potentially the project digest soon after in the following week. Thank you, Josepha!

5.2 updates

#46898 WSOD Protection could use some copy review

RC1 is planned for today, with the *target release date in ~2 weeks*

Josepha brought attention a few items needing help:

There were 11 tickets open in the 5.2 milestone but that is now down to 3 as of writing this summary. @pento worked through a bunch the evening prior to devchat and @sergeybiryukov has been lending a hand today. Many of these will be moved out of the milestone, but if there are any still at this link, feel free to discuss or do the next step.

The about page outline will be ready for RC1 and will be final in the final release. Most of text should be in by RC-1 but it is not “frozen” in this time period.

Dev Notes

There are a few dev notes that are still in draft. @jeffpaul is working through the field guide and adding placeholders for those. It would be much appreciated if you’d finalize your notes so we can include them! Ideally these would release along side RC1.

Please use the following link as a list of what is pending for dev-notes: link here. If the dev note has been made, please remove the needs-dev-note keyword. 🙂

Open Floor

Influx in Forum issues/Trac Tickets

There was discussion around the continued cadence and nature of Minor/Major releases. @joyously said that she has noticed an influx in forum posts focused around bugs. Joy reminded us that directing folks to create tickets in the forums will help greatly in identifying common bugs. This also serves as a reminder that there are teams for triage in both Trac and the Gutenberg Github repo that would greatly appreciate the help. The Gutenberg triage has recently moved to a weekly cadence and the times are as follows:

Gutenberg #core-editor triage times are – Monday at 13:00 UTC

Gutenberg #design triage times are every Tuesday at 16:00 UTC

@jorbin punted #46293 as there was no decision made and there is a need to freeze strings. Many thumbs up emojis agreed. 👍

#5-2, #devchat, #summary

Dev Chat Summary: June 20th (4.9.7 week 5)

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

4.9.7 planning

  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @tristangemus, @pbiron, and @danielbachhuber open to help contribute during 4.9.7
  • Potential focus for 4.9.7 so far “Try Gutenberg” prompt and privacy fixes
  • Release timing for 4.9.7 will be determined after a release lead is named
  • No confirmed interest in release leads from other team reps and component maintainers or from WCEU, but #design team likely in future minor releases
  • Looking to increase diversity in release leads by asking for nominations or suggestions outside just devchat and summary posts, please share any ideas you have on this… thanks!
  • For those with interest and availability, please review the Releasing Minor Versions handbook page and the Release leads feedback on 4.9.5 post
  • Will look to make decision on 4.9.7 release leads in next week’s devchat

Devchat coordination

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats
  • So far @joemcgill, @audrasjb, and @antpb have graciously offered their time, hoping for 1-2 more people to help to help share the load
  • If you’re open to collecting agenda items and publishing an agenda, running the actual devchat meeting, and/or publishing a devchat summary then please comment here or ping @jeffpaul if you’re able to help out… thanks!

Updates from focus leads and component maintainers

  • The Gutenberg team would like to encourage testing of the next few releases as they get closer to feature complete
  • The JavaScript team shared an update on the process of adding inline docs, so if you’re interested and able to contribute please check it out. They also posted a summary of their meeting covering documentation, polyfills, and deprecation strategy for WP JS code.

Next meeting

The next meeting will take place on June 27, 2018 at 20: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-7, #core, #core-js, #dev-chat, #gutenberg, #summary

PHP Meeting Recap – May 28th

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

  • We started with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • 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, #summary

PHP Meeting Recap – May 7th, 2018

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

At this meeting there was some continued conversation around plugins & theme php version requirements (see parent ticket here)

  • @sergey has made some progress on technical restrictions
  • #design feedback will be needed as a part of implementing how restrictions are communicated to the user.
  • Initial goal for this is block installation of plugins in environments that don’t match php requirements for the plugin.
  • @flixos90 is going to get in touch with the design team regarding feedback on the mockups.

Also on the agenda was continued conversation around design/layout work for the PHP upgrade page. We took a look at this mockup that was done by @jaymanpandya, however for the most part we felt that in order to progress on this, the feedback needs to come from the #design team itself and those involved in the design of the overall WordPress.org site. To that end, @flixos90 has created a ticket in meta for tracking this and this is a callout to anyone involved in #design (and particularly with regards to the overall design of WordPress.org and how this would fit in with that) to review the current mockup and add comments.

Next Meeting

Next meeting will take place on Monday May 14, 15:00 UTC in #core-php

Agenda:

  • Followup on php requirement restrictions for plugins/themes (hopefully with some design feedback).
  • Followup on PHP upgrade page design feedback (if there is any).

#php, #summary

PHP Meeting Recap – April 30th

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

  • We first discussed whether we could have the current widget implementation backported to the upcoming minor release 4.9.6. @desrosj was positive about doing this, but left it open for a final review and someone with the willingness to actually commit it. One benefit would be to include this with the privacy policy changes, which has translators already be aware that a portion of new text strings need to be translated. Also, getting it in as soon as possible will finally allow us to get real feedback on its reception and effectiveness.
  • The “Upgrade PHP” information page needs a visual overhaul. It currently is a pure wall of text, and any change in that regard will be an improvement at this point. @schlessera will work on changing the page for a few quick wins to make it more digestible, and the discussion with the #design team needs to be relaunched.
  • As the first two components of the “Servehappy” initiative are now in a usable state, it is time to focus on the third component: enforcing the “Requires PHP” plugin header information.
  • There are several different mechanisms that need to be changed for enforcing the PHP version requirement, and we agreed to split the main ticket up into smaller subtasks so that blocking issues in one will not block progress in others.
    Here are tickets for the current subtasks:
    1. Disable “Install” (plugin) buttons – #43986
    2. Block updates to new plugin releases – #43987
    3. Allow filtering plugin searches by required PHP version – #43989
  • @afragen has already built a proof of concept that shows a basic implementation for blocking updates. This immediately points out a problem with the current API, which can only serve the plugin information for the latest release of a plugin. If we need to cycle to prior versions to do something like “find the latest version that still runs on PHP 5.2”, we’ll have to work on infrastructure changes as well.
  • Blocking updates does have security implications. We want to block updates to new versions that would bump the required PHP version past a version the server provides, but at the same time, we still want to provide the possibility for plugin authors to push security updates.

Post-meeting update

  • The Servehappy nag widget was not included in the beta of release 4.9.6. We should work on getting it backported early in the 4.9.7 release cycle.

Next week’s meeting

  • Next meeting will take place on Monday, April 7th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how best to relaunch the #design process and go over the individual tickets for enforcing the “Requires PHP” header.
  • 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, #summary