Francesca Marano 1:08 pm on April 22, 2020
Tags: , 5-5, 5-6, ,   

Dev Chat Agenda for April 22, 2020

Here is the agenda for the weekly meeting happening later today: Wednesday, April 22, 2020, at 20:00 UTC.

Announcements

If anyone has any announcement to make, now is the time!

Upcoming Releases

  • Work has started on WordPress 5.4.1 lead by @whyisjake
  • All the maintainers have been pinged about 5.5. Some replied, some didn’t – please do, so scope and schedule can be proposed.
  • Work for 5.6, aka all-women release, continues. All the women that expressed interest have been contacted. @chanthaboune, @angelasjin, @cbringmann and I will work on phase 2: identifying missing roles and cohorts to organise the team that will ride along with 5.5

Highlighted blog posts

Components Check-in

I have pinged Meta about having a weekly scheduled post to check Components status – @dd32 expressed some concerns about the noise that it will create. I would still suggest to move on with this for a three-month test.

But in the meantime… the usual:

  • News from components
  • Components that need help/Orphaned components
  • Cross-component collaboration

Open Floor

Got something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-4-1, #5-5-2, #5-6-2, #agenda, #devchat

Paal Joachim Romdahl 11:03 am on April 21, 2020  

Editor Chat Agenda: 22nd April, 2020

Facilitator: @paaljoachim. Notetaker: @annezazu.

This is the agenda for the weekly editor chat scheduled for 2020-04-22 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • The plan is to ship a release candidate of 5.4.1 this week and a final release next week.
  • Monthly Plan & Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

Ajit Bohra 7:28 pm on April 20, 2020
Tags: , , ,   

Editor chat summary: Wednesday, 15 April 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, April 15, 2020, 14:00 UTC.

WordPress 5.4 Adderley was released and Issue/PR’s for WordPress 5,4,1 are being kept track of using “Backport to WP Core” label.

Gutenberg 7.9.0

Gutenberg 7.9.0 was released which introduces block design tools, new block patterns, lighter block. Check out the release note for more details.

Priorities

The priorities are still the same though and available here

Task Coordination

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.

@youknowriad

  • Working on the new inserter UI, hopefully, it will land in the next plugin release
  • PR reviews Cover Alignment, Block Context API and more
  • Triaged and closed issues
  • Worked on various fixes for widget screen &button block
  • Continue work on the inserter UI

@zebulan

@sageshilling 

@itsjonq

@michael-arestad

@brentswisher 

  • Continue to work on adding storybook stories and the story shot-addon.
  • Work on a PR to remove the story shot integration, which should speed up and simplify the story creation process, as well as make the js unit-tests in Travis more stable

@karmatosed

  • Focus on navigation for this week, Both in nav-menus.php and iterations to the block

@andraganescu

  • Worked on various issues around the navigation menus replacement experiment

@aduth

  • Progress on a new “Block Context” API
  • There have also been some interesting side-effects of this work, including an experimental (backward-compatible) revision to the PHP render_callback function signature to receive the full block object, not just the attributes.
    https://github.com/WordPress/gutenberg/pull/21467

@desaiuditd 

Open Floor

@check2020de

Fixing height hardcoding for spacer block https://core.trac.wordpress.org/ticket/49862#comment:3

  • it is not good that there is a hardcoded 20px value on the spacer
  • however, the reason is that we need a min-height to make that block selectable by tapping and for better a11y in general
  • however, it may be that the incoming block padding/margin will also solve this problem
  • needs further discussion & decision to better handle the spacer on desktop & mobile

@mboynes

 How does one petition to get a GitHub issue reopened? asking in the ticket doesn’t appear to do the trick

Looking if/when we can get to it:

On the topic of closing issues, as a relative outsider to the project, decisions to close issues feel somewhat unilateral to me. I would like to propose a new process where closing issues requires two people (except in obvious cases, like closing as a duplicate). taking a page from the stack overflow book, the first person could add a “close-vote” label, and someone else, in reviewing “close-vote” issues could then review and close it.

We have some guidelines already about issues triage here https://developer.wordpress.org/block-editor/contributors/repository-management/

It’s totally fine to close and reopen issues.

@joostdevalk

Pinning behavior for plugins has changed

Regression/bug in plugin pinning .

@marekhrabe

Looking for a designer to confirm or update the approach on Media & Text resizing we came up a year ago and it got stale.

More info https://github.com/WordPress/gutenberg/pull/14483

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

Jon (Kenshino) 4:04 pm on April 20, 2020
Tags: ,   

X-post: We’re applying to Season of Docs

X-comment from +make.wordpress.org/docs: Comment on We're applying to Season of Docs

Grzegorz (Greg) Ziółkowski 10:59 am on April 20, 2020
Tags: ,   

JavaScript Chat Summary: April 14, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript).

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

Internet Explorer End-to-End Testing

(Slack conversation)

Context: https://github.com/WordPress/gutenberg/pull/21528

Feature Proposal: https://github.com/WordPress/gutenberg/issues/16509

Discussion: The above pull request seeks to introduce a new package incorporating a Selenium-based web driver to run Internet Explorer tests through BrowserStack’s automation API.

Discussion Points:

  • It’s been something of a pain point in Gutenberg’s history of browser-specific bugs that can’t be captured with the current set of testing tools.
  • It ought to be done with careful consideration since having multiple test setups for end-to-end tests is prone to introduce some confusing developer experience.
  • @adamsilverstein could imagine there might be other ways to leverage Browserstack as well, e.g., if we want to cover additional browsers.
  • Running on merge to master seems fine, although that means you’ll be fixing things after they are broken.
  • @aduth raised that typically Browserstack is a paid service (“$12.50/mo for Freelancers” plan is the cheapest). They offer free open source testing, which he applied for and was accepted. But that doesn’t help for local testing since we’d not want to be sharing our credentials.

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.

  • Dave Ryan posted a reflection on the recent WPBlockTalk conference. One standout observation he made that I took note of:
    • “The Block Editor is great, but perhaps some of the biggest potential for the Gutenberg project exists in the relationship Blocks can have with the external, web ecosystem — both how edits in the Block Editor can be pushed to other services and how external systems can automate content creation and edits on the WordPress side.”

#core-js, #javascript

Lara Schenck 2:42 pm on April 17, 2020
Tags: ,   

Chat Summary: 16th April 2020…

Chat Summary: 16th April 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1587071014211100

I (@notlaura) facilitated the meeting.

CSS audit updates

@isabel_brison gave an update on the screehshot testing work in (49606)[https://core.trac.wordpress.org/ticket/49606] and mentioned it proving troublesome to pass the Travis build, and that would be a secondary concern. The most useful part of the tests will be when we are actually making changes to the code and checking for breakage vs. running them on every changeset. I clarified that the workflow would be something like first, generate/update the reference screenshot to contain any changes, and second, run the tests as you develop to check for unintentional changes.

@ryelle shared a custom script for running various audits: https://github.com/ryelle/css-audit – this is a big step for ticket (49638)[https://core.trac.wordpress.org/ticket/49638] and determining the audit methodology. @ryelle‘s scripts are organized by categories like colors, selectors, and important, and each audit outputs a set of data points. The current script outputs audit results in a .txt file, and I mentioned that could certainly be updated to JSON or another format that can be displayed on WP.org or elsewhere. Very cool!

I also pointed out a few tickets mentioned by @isabel_brison on the last chat summary regarding IE 11 hacks. When looking into audit data points for IE hacks or “outdated layout practices”, these would be good to reference: https://core.trac.wordpress.org/ticket/46015, https://core.trac.wordpress.org/ticket/49696 (but if the patch for 46015 makes it through, we have no need for an audit data point!)

Open Floor

I noted a message from @kburgoine regarding experience with IE11 support and color schemes – it’s not necessarily a straightforward task! @isabel_brison mentioned that there may be existing color scheme tickets and that the global styles work in Gutenberg includes custom properties. @sabernhardt mentioned the admin color schemes repo from @ryelle and a feature plugin started for Dark Mode. I suggested a boldly titled ticket “Replace wp-admin color schemes with CSS custom properties” so that we can track the conversation, and responses were positive!

That was all for this week!

#summary #core-css

Jeffrey Paul 1:45 am on April 17, 2020
Tags: ,   

Proposal: Core Team Rep Elections

It’s been an eternity since team reps were updated for the Core Team.  @helen and I (@jeffpaul) have been serving since before Gutenberg development began, way longer than team reps usually would… so it’s time to talk about how we update Core team reps.

The Role

In the WordPress open source project, each team has on average one or two representatives, abbreviated as reps.  Some teams have more than two, but for the sake of sanity sticking with two for now keeps things simpler.  And for the historians out there, the role goes way back to 2012.

Historically with the Core team, the team rep duration was around a year, though some reps stuck around longer if there was a particularly good fit.

Anyone who serves as a “team rep” is responsible for communicating on behalf of the Core team to the other contributor groups via weekly updates, as well as occasional cross-team chats.  Reps are also consulted on Contributor Day, helping find someone within the Core team attending an event who can help lead a Core table.  Full details on the Team Rep role is on the Team Update site.

It is not called “team lead” for a reason.  While people elected as team reps will generally come from the pool of folks that people think of as experienced leaders, remember that the team rep role is designed to change hands regularly.

This role has a time commitment attached to it.  Not a huge amount, but in my experience, it’s at least one hour a week.

Here are the main tasks:

  • Writing regular Core team recaps and posting it in Updates
  • Keeping an eye on the moving parts of the team to be able to report for quarterly updates (example)
  • Occasionally helping release leads with devchat agenda posts, chats, and summaries

More details on coordinating devchat are available in the Core handbook.

The Community Team has been running the following process which makes for a tried and tested model for the Core Team to similarly try out.  Hat tip to @francina for sharing these details!

Nominating

Nominations happen in the comments of a Core Team Reps Election post (here’s a sample Community Team nominating post).  Self-nominations are welcome.  The deadline for nominations should be around two weeks.  

If you want to nominate someone in private, please reach out to @current-team-rep-1 and @current-team-rep-2 on Slack.

Disclaimer: if you get nominated, please don’t feel like you have to say yes.  The polls will only include the names of the people that are responding positively to a nomination.  So feel free to reply with a “Thank you, but no thank you”.

Once the deadline has passed for nominating, a comment will be added and pinned to the top:

Nominations are now closed and voting is open until <voting deadline>. Voting details and link here: https://make.wordpress.org/core/<voting-link>/

Voting

After nominations have ended, a poll for voting will be opened and linked from a voting announcement post (here’s a sample Community Team voting post).  It will stay open for around two weeks.

Once the deadline has passed for voting, a comment will be added and pinned to the top:

Voting has concluded and the new team reps will be announced on <date> during the Core devchat.

Once the results have been finalized and announced, a comment will be added and pinned to the top:

Selected Core Team reps are announced here: https://make.wordpress.org/core/<results-link>/

Results

After voting has ended, results should be shared in an announcement post (here’s a sample Community Team results post).  Similarly, the new team rep(s) should be updated on the Team Reps page.

The outgoing team rep(s) should plan to be available for questions and consultation from the incoming team rep(s) as there will undoubtedly be a learning curve as new rep(s) get into the role.

Next steps

I will bring this proposal up in the next devchat on <date> and lacking any major concerns, will work to publish a nominating post after that devchat.

If you have any questions, please feel free to ask in the comments.  I will be happy to reply (or look to past team reps for input)… thanks!

#proposal, #team-reps

Jb Audras 9:54 pm on April 16, 2020
Tags: , ,   

Devchat meeting summary – April 15, 2020

@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

Highlighted blog posts

Upcoming Releases

WordPress 5.5 major release

WordPress 5.5 Call for Tickets is still open for feedback.

@sageshilling shared that the Editor team is working on a Gallery block update for WP 5.5.

WordPress 5.4.1 minor release

@audrasjb shared that on the 13 tickets in the milestone, 12 are already committed and one ticket still needs some work.

@whyisjake self nominated to lead WordPress 5.4.1. @davidbaumwald added that if anyone is interested in helping with 5.4.1, they can get in touch with @whyisjake. @audrasjb expressed his interest.

The idea is to ship a release candidate next week and a final release in two weeks.

Components Check-in

@imath shared an update on Comments component:

  • He is working on a plugin to progress about #35214
  • It would be nice to get some feedback on #49236, since it would be nice to have a patch committed early
  • Feedback is also needed on #49179

@clorith pointed out that it would be nice to move forward on Dashboard Namespace introduction in REST API. Volunteers are welcome to contribute to the associated tickets.

@audrasjb shared the Accessibility team main focuses for WP 5.5:

@audrasjb also shared an update about WP Auto-updates feature plugin: version 0.5 was released just before the devchat. It addresses all the feedback received from the Design and Accessibility teams.

Open floor

@audrasjb raised a question concerning WP Auto-updates feature: should it provide a way to rollback to the previous version of an auto-updated plugin? This feature was proposed in a GitHub issue.

@imath believes WordPress could make it easier to come back to a previous version of a plugin.

@timothyblynjacobs pointed out that one of the big issues with rolling back, is that if a plugin does any kind of DB change, it can’t necessarily rollback without data loss or other breakage.

@clorith added that it might “double” the time needed per update in doing so, maybe even triple if it needs to revert as well, the increase in memory consumption, and processing time adds a new layer of potential failures as well.

@afragen raised this could be detected by the new WSOD so at least it wouldn’t white screen a site. @timothyblynjacobs answered WSOD protection would notice the error, but wouldn’t automatically deactivate the plugin.

@timothyblynjacobs thinks it would also be worth clarifying whether this would be limited to the updater automatically rolling back, or it being available for the user to take action.

For @sageshilling, ideally, the update if automated, would check for known problems and either notify site owner if detected during import.  If possible, stop import, roll back and allow the site owner to address it.

@clorith thinks the correct approach is yes, keep a backup until the update is completed so it can be reverted, and introduce an actual feature for plugins/themes to run upgrade tasks after the fact, that way the site can be confirmed still functional without triggering any DB upgrades for example.

@timothyblynjacobs thinks there would be value to plugins being able to rollback the same way core does if the actual upgrade process fails. But he think having a WP-Rollback [note: it’s a plugin available on the repository] type solution in core should be a separate project.

As WP Auto-updates co-lead, @pbiron added an other question to the discussion: if one want to rollback, is that something that should be in the feature plugin or can that be worked on after the feature plugin is merged into core? He think the WP_Automatic_Updater class has enough hooks that we could work on it in the feature plugin, but it might be difficult.

@desrosj point out that the way core handles rollbacks currently is a rollback URL is provided in the API response, and it gets retrieved if a severe failure occurs. There is no equivalent link returned in the API response for plugin updates.

@imath believes it’s better to have a way to manually upgrade/downgrade a plugin in WordPress before merging the feature into Core.

@desrosj thinks that for the first iteration, the WSOD may be enough for a non-technical to recover from an issue. Enabling auto-updates for plugins and themes will be opt-in, so maybe there just needs to be appropriate messaging when the site owner enables an auto-update for the first time.

@clorith agreed, when/if the feature is enabled by default, it needs rollback, but for a first iteration with manual enablling, let’s roll with what a manual way of reverting, sounds reasonable.

@audrasjb pointed out that managing updates rollback is a project in itself as it is something that should be currently available for manual updates.

@afragen asked: aren’t core rollbacks only for critical errors? Any plugin downloads and updates correctly but results in a fatal because of a coding issue sets a higher bar than we have for core.

@pbiron added that the current scope of the feature plugin has been providing a UI for enabling/disabling auto-updates, and rollback seems to be another feature plugin itself. Also, there is a notification email that gets sent with updates successes and failures. Also @timothyblynjacobs added that WSOD would send a recovery mode email if a site has fatal error on protected endpoints. @desrosj added that in the current process to manually upgrade a plugin in the dashboard today, there is no protection for a fatal error or coding error in the plugin.

@audrasjb raised that a rollback feature would be a nice improvement to WordPress Core, but it’s useful for both manual and auto updates.

#5-4-1, #5-5, #feature-autoupdates

Lara Schenck 5:52 pm on April 15, 2020
Tags: ,   

CSS Chat Agenda: 9nd April…

CSS Chat Agenda: 16th April 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, April 16, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS audit status update
  • Open floor

#agenda, #core-css

Lara Schenck 5:39 pm on April 15, 2020
Tags: ,   

# CSS Chat Summary: 9th…

Chat Summary: 9th April 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1586466056120100

I (@notlaura) facilitated the meeting. A bit delayed in posting the summary – will do better next week!

CSS audit updates

We reviewed the process for the audit and discussed the high-level ticket “Create a report outline for Audit” #49637. What should a report outline look like? Currently it exists in this Google Doc as a place to collect data and gradually organize it.

@joyously asked if the report would be an ongoing process or pinned to a specific release which brought up an idea and conversation around how to express the audit data. @michael-arestad suggested a publicly hosted page that runs and updates on each release. This could be immensely helpful for tracking improvements to the codebase! That hinted at another high level ticket, “Determine methodology recommendations for audit” #4963 – which may be a mixture of automated processes and manual work depending on the data we need.

How would we pull off recurring, release-based audit results? I proposed that the first steps are getting the data the first time and keeping track of how we did it, while determining how we want to present the data e.g. by edit screen or by category, other, or all of the above.

@joyously suggested incorporated the automated audit results alongside the PHP reference in the developer subdomain and .org.

To close up the audit update, I identified the following as some items that would be good starting points for contributors willing to do some manual code inspecting:

  • < IE 11 Hacks – maybe start by finding an example of a few and seeing if they are in mutliple locations
  • State of comments – what are the comment styles that are used
  • Location of outdated or brute-force layout practices (e.g. floats, positioning and pixel nudging)

Open Floor

@joyously posed the age-old question: “When does our browser support for IE11 go away?” @michael-arestad answered with “When fewer users use the browser. Tell your friends.” Wise words! We reviewed the browser support best practices and that when IE 11 is < 1% usage, we can abandon support. Current usage information can be seen here.

The conversation then turned to custom properties and replacing the admin color schemes with custom properties which seems like a great candidate for introducting them to core. No ticket for that … yet! @michael-arestad mentioned the benefits of keeping in sync with the NPM components used in Gutenberg. After the meeting, we discussed the intricacies of using the JS components in wp-admin, and if you’re interested, check out the meeting transcript here!

That was all for this week!

#summary #core-css