David Baumwald 6:32 pm on January 20, 2020
Tags: ,   

Bug Scrub Schedule for 5.4

Now that 5.4 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 16:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 17:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.

Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.4-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.4, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-4, #bug-scrub

Francesca Marano 8:17 pm on January 22, 2020
Tags: , , ,   

Dev Chat Agenda for January 22, 2020 (5.4 Week 2)

Here is the agenda for the weekly meeting happening later today: Wednesday, January 22, 2020, at 09:00 PM UTC.

Announcements

Highlighted Blog Posts

Blog Posts Needing Review/Feedback/Help

Components Check-in

Open Floor

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

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

#5-4, #agenda, #core, #devchat

Francesca Marano 8:11 pm on January 22, 2020
Tags:   

Release Model Working Group – Kickoff, January 29, 2020

Thank you for your patience, it took longer than I predicted to kick off this working group, but here we are!

On Wednesday, January 29th let’s have the first meeting for the Release Model Working Group at 19:00 UTC. It’s the same time slot as the New Contributors Meeting and we can alternate meetings with them.

The problem we are trying to solve

Many fixes and enhancements are made continuously in WordPress core, the Gutenberg block editor, and third-party libraries, but everyone has to wait up to four months to see these due to the cycle of three or four major releases per year. This has a negative impact on both end-users and developers.

What will the Release Model Working Group do?

This working group will spend some time during the 5.4 release cycle to:

  • Evaluate the technical changes needed to speed up the release process
  • Evaluate if those changes are doable with the existing resources and tools

The group will also document the existing release process in order to achieve the above.

The end result will be a few factual, non-opinionated documents which outline the above.

Why do we need a working group?

A working group is a bit of a fancy name for a group of people who come together to spend time focused on a particular problem – in this case, the issues caused by the current release cadence – and identify potential solutions and their feasibility.

We need this because increasing the rate at which new versions of WordPress are released has a big impact not only on end-users but on those involved in the release.

When

A meeting can be held in the #core Slack channel every two weeks, alternating with the New Contributors chat, and it will be mostly a status report so everyone is aware of what the findings are so far, and what everyone is doing.

How will the group work?

The group is self-organising based on experience, skills, and interest. Team members should commit to one of the above-mentioned areas.

Which approach to use for the research and which tool to use for collecting the results has to be determined: please leave your comments below, so by next Thursday we will have a few ideas to pick from.

I can take on the role of facilitator, with main tasks being:

  • Pinging people to remind them of their commitment and deadlines 😉
  • Remove blockers if necessary
  • Check overall progress

Who is the team made of

Many people raised their hands in the call for volunteers post. Thank you for your enthusiasm and generosity!

I am spending the next few days reaching out to each one of you to see how your experience and expectations, together with the capability of being self-organised, aligns with the group.

The chats will be public, so everyone can see what is being discussed.

Initial research: The different aspects of a release

I took some time to explore all the aspects involved in releasing a new version of WordPress and divided them into macro areas. The list is not exhaustive but a starting point. At this point it’s not necessary to go too granular, that’s what the working group is for.

This list should give the working group a starting point of areas to focus on.

Stages of the release cycle

  • Alpha
  • Beta
  • Release Candidate
  • General release

Issue tracking

  • Bug reporting
  • Bug gardening
  • Code writing
  • Testing
  • Committing

Planning and coordinating

  • Scoping the release
  • Putting together a release team
  • Scrubs scheduling
  • Collecting feedback and status reports from everyone involved

Communication of the release

  • Blog posts in /news for each stage
  • About page
  • Dev notes
  • Field guide
  • Bug scrubs (schedule and hosting them)
  • Dev chats (agenda and hosting them)

The people involved in releasing

  • Coordinator
  • Mission control
  • Core committers
  • Security team
  • Systems

Thank you for making WordPress!

#release-process

Ella van Durpe 4:44 pm on January 22, 2020
Tags: , ,   

What’s new in Gutenberg? (22 January)

The second Gutenberg release of 2020 includes 159 PRs by 56 contributors!

The navigation block received again quite a few improvements this release. You now have the ability to set text and background colours!

Screen Shot 2020-01-10 at 6 36 18 PM
New colour options fo the navigation block.

This release we’ve also made some considerable performance improvements. The average time of an input event has almost been reduced by half (47.76%) and the loading time of a fairly large post by 29.25%! This is the result of making the block DOM tree lighter, meaning taking the block controls out of the block rendering and DOM tree and removing div element wrappers.

There’s a new block collections API which can be used to group blocks in the block inserter.

registerBlockCollection( namespace, { title, icon } );

Included are also new post layout blocks (author, date and excerpt) and improvements for the site editing experiment.

7.3 🇬🇷

Enhancements

  • Add border to table header & footer 19450
  • Add the new replace flow to the cover 19583, media text 19198, file 19174, audio 19158 and video 19162 block.
  • Components: improve ToolbarButton 18931
  • Sibling inserter: fix dead zone between blocks 19719 19729
  • Top toolbar: adjust tab order 19623
  • Regions: position publish region after sidebar 19427
  • Better accessibility labels for blocks 18132
  • Breadcrumb: add accessibility label 19597
  • Navigation: add background color 19108

Performance

  • Lighter block DOM:
    • Put sibling inserter in popover 19456
    • Remove extra div wrapper 19010
    • Remove inner div wrapper 19593
    • Split out toolbar rendering 19564
    • Put side inserter in Popover 19406
    • Rewrite drop zone with hooks (useDropZone) 19514
    • Merge effects 19617
    • Fix alignments 19704
    • Clean up after control removal 19618
    • Reposition tabbable inserter 19596
  • Avoid rerendering every block when caret moves in and out of formatting 19524

Bug Fixes

  • Navigation:
    • Format the allowed styles 19477
    • Show recent pages as default suggestions when creating Nav Links 19458
    • Define allowedFormats option for NavigationLink 19507
    • Rename the LinkControl’s edit button title 19505
    • Use underline instead of bottom border for nav links 19538
    • Do not output navigation links with empty labels 19652
    • Remove draggable from all navigation-link blocks 19648
    • Remove duplicate CSS from Navigation that is aleady in Navigation Link CSS 19540
    • Remove the text color button double border on the navigation block toolbar 19567
    • Replace, on editing a navigation link, the current label with the title of page or post 19461
    • Add description for the Link Settings Description in the Link Block settings 19508
    • Fix Navigation Link url escaping 19679
    • Fix alignment on left border between menu navigation controls and menu item 19511
    • Styling fixes after navigation feature merge 19455
  • Add support for align wide to deprecated versions of gallery block 19522
  • Block top toolbar: fix mover direction 19574
  • Editor keyboard shortcuts: fix Toggle Sidebar 19605
  • Editor: Fix Block Embed Input size 19438
  • Fix ServerSideRender component showing className 19555
  • Fix writing flow focus capturing 19621
  • Fix small visual select glitch 19590
  • Fix the height of the tags tokens 19592
  • Fix buttons block Link shortcut not working with multiple buttons 19492
  • Disable HTML on navigation link 19483
  • Fix managing page break in the block manager 19303
  • Show predefined colors in the navigation block 19493
  • Update CSS rule on the widgets screen required for drag & drop 19428
  • Multi block selection: fix tabbing 19700
  • Multi block selection: set focus back after attempt 19720
  • RichText: don’t set focus when applying format 19536
  • Writing Flow: fix list selection 19721
  • Fix Color Picker Format Toggle placement 19607
  • Fix Columns block pattern picker item margin. 19494
  • Fix block styles for More block 19745
  • Block: fix hasMovers BlockList setting for top toolbar 19619

New APIs

  • Components: add ImageSizeControl component 17148
  • Add block collections 17609
  • Add Text component 18495
  • Add warning package 19317
  • Components: add isFocusable state to Button 19337

Experiments

  • Edit Site:
    • Add a Post Author block 19576
    • Add a Post Date block 19578
    • Add a Post Excerpt block 19579
    • Implement Template Part block editing 2 19203
    • Add template loading 19081
  • Block Directory:
    • Change ‘update’ icon to text to be more communicative 19451
    • Update the action button label to read ‘Add block’ 19412
  • useColors:
    • Fix contrast check 19500
    • Directly pass ref for color detecting 19474
  • InnerBlocks: Fix toolbar capturing 19530

Documentation

  • Add js syntax highlighting to documentation 19467
  • Add lint-md section to scripts readme 19716
  • Add linting of source in markdown files 19518
  • Document packages-update wp-scripts command 19711
  • Linting Documentation 19543
  • More visibility to the theme opt-in styles documentation 19463
  • Remove spaces in title for consistency with other components and docs 19466 19464
  • Update block-filters.md 19595 19684
  • Update contributors guide with docker-compose info 19362
  • Add js syntax highlighting to documentation 19465
  • Use import statement instead of deconstruction in docs 19469 19471
  • Fix Navigable Container component usage code 19615

Various

  • Block Editor: Remove (more) legacy “editor-” class name compatibility 19489
  • Block toolbar: rewrite toolbar forcing 19527
  • Breadcrumb: isolate logic 19573
  • Contain selection logic in useMultiSelection 19529
  • Move navigation and selection logic to WritingFlow 19397
  • LinkControl
    • Refactor LinkControl API 19396
    • Remove Popover from LinkControl component 19638
    • Add search results label for initial suggestions 19665
    • Prevent space being reserved for scrollbar when items fit box 19633
    • Remove non-public fetchSearchSuggestions from LinkControl documentation 19710
    • Update Nav Block to use new showInitialSuggestions prop on LinkControl 19667
    • Flatten LinkControl components by mocking useSelect for tests 19705
  • Remove core editor usage from block editor rich text 18789
  • Add script to automatically update core packages 19448
  • Adds tests for horizontal mover descriptions 19549
  • Remove: Gradient Picker from cover block placeholder 19712
  • Add SVGR support to wp-scripts 18243
  • Add storybook for Panel component 18541
  • Add supports html: false to new website blocks. 19646
  • Add: Block editor keyboard shortcuts on the widgets screen 19432
  • Added 8px padding to search input block. 19452
  • Adds a “(no title)” label to links to pages or posts with no title 19528
  • Array type attribute source query comma missing 19717
  • Block Editor: Make initial inner blocks non-dirtying. 19521
  • Block Popover: editor canvas as boundary 19322
  • Check for existing of avatar_urls array before trying to return the avatar img part of user autocomplete fragment 18259
  • Update downshift dependency to v4.0.5 19661
  • Components: replace console.warn with wordpress/warning 19687
  • DOM: Mark stripHTML as unstable 19725
  • Decode HTML entities for publish link 19517
  • Expose custom gradient picker 19480
  • Gallerys ids are saved as numbers 19163
  • Media & Text: Remove “Insert from URL” from the replacement flow. 19606
  • Page template previews 19106
  • Post-Author: Move HTML tags outside of the translatable string 19675
  • Priority Queue: Invoke callback when flushing queue 19282
  • RichText: split out inline warning 19545
  • Storybook: Update to latest 5.3 19599
  • Update npm-package-json-lint-config docs 19584
  • Update the float on the Spinner to none 19338
  • Wrap color palette in fieldset with label inside of a legend 19546
  • Check Symbol.iterator not Symbol.toStringTag (redux-routine) 19666
  • Skip intermittent end to end test on the button block 19653
  • Fix e2e test failures via console log exception to handle temp wpnonce error 19532
  • Packages: Mark build-styles as side-effectful 19535
  • docgen: Omit unknown type tag from Markdown format output 19571
  • Build Tooling: Skip package for build if package.json unreadable 19439

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 7.3.0 4.550s 33.8ms
Gutenberg 7.2.0 6.431s 64.7ms
WordPress 5.3 6.481s 69.865ms

#core-editor, #editor, #gutenberg

Mervin Hernandez 7:55 am on January 22, 2020
Tags: , ,   

WP Notify Meeting Recap – January 20 2020

This is a recap of the WP Notify meeting held on Monday, January 20, 2020, 14:00 UTC. You can read the meeting discussion here.

Based on feedback received at meetings and comments, we focused on making the Objectives section in the requirements document more concise.

We also added a Use Cases section, based on feedback from the previous meeting recap post.

Use Cases

This is the excerpt of the “Use Cases” section as compiled by @folletto and @psykro.

Section 2. Use Cases
1. Action required: the plugin wants the user to take a decision, i.e. “you got a comment” (action, notification)
2. Onboarding: the plugin wants to provide guidance on a specific feature, i.e. “try this feature” (action, on-page/notification)
3. Informative: the plugin wants to inform the user about something, i.e. “backup completed” (no action, notification)
4. State: the plugin changes its state, i.e. “settings saved” (no action, on-page)
5. Marketing: the plugins wants to advertise something or suggest an upgrade, i.e. “buy an upgrade!” (action, on-page)

Requesting Feedback

  • Should we address possible unintended uses (example: Notifications of subscribe/unsubscribe from site which may include a profane username?) @folletto
  • For implementation, should we port notifications (such as marketing notes) only to the user who activated the plugin? @m1tk00
  • Further comments / remarks on the 📄 Requirement Document are welcome, and we added appendix references of related projects for inspiration (https://docs.google.com/document/d/1SoIaFqXkXiVzq5mizbZQafMfL36bD0WKj8iwYM823MI/edit#)

Next Slack Meeting

📅 Monday, January 27 @ 14:00 UTC

A note about how we hope to advance the project forward at a steady pace: by working together on the requirements document during meetings, and as time allows in between with comments and channel talks. Once we gather feedback on our goals and actionable steps in the best interest of a merge-able project, then we will progress with next sections of the document and work. @psykro @hrmervin

#feature-plugins, #feature-notifications, #summary

Andrew Duthie 3:02 pm on January 21, 2020
Tags: ,   

JavaScript Chat Summary: January 21, 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.

New “create-block” package

@gziolo has opened a pull request to propose a new “create-block” package, intended to be used by plugin authors to scaffold new blocks. This is the result of work which had been previewed during a previous meeting’s open floor.

Discussion points:

  • Separate package vs. part of the existing scripts package?
    • Needs to be separate to be usable as an npm init initializer.
    • We could decide later to add something to scripts which “proxies” commands to the separate package
  • Differences from the existing WP-CLI scaffold script?
    • Embraces build tooling, vs. intention of WP-CLI script to be run-and-done
    • Can be run outside a WordPress environment
  • Future goals

Action Items:

Open Floor

  • @epiqueras shared a problem which has surfaced in development of the block editor relating to values in inner blocks contextual to their ancestor blocks. He has worries about the performance impact of the current approaches, and has proposed an idea for a solution to improve the block API in a way which creates a shared context for block values.
  • @davilera raised an ongoing discussion regarding date function inconsistencies. This was also discussed during last week’s meeting. As an action item, he would like for a decision on the desired behavior and function signatures. We want to avoid backwards-incompatible changes. The pull request in its current form is sufficient for fixing an existing bug. After some discussion, a plan emerges that changes toward a more desirable API can and will be made within the current pull request without introducing breaking changes.

#core-js, #javascript

Tammie Lister 1:15 pm on January 21, 2020
Tags: ,   

X-post: The proposed design focus list for 5.4 release

X-comment from +make.wordpress.org/design: Comment on The proposed design focus list for 5.4 release

Paal Joachim Romdahl 9:24 am on January 21, 2020  

Editor Chat Agenda: 22nd January, 2020

Note taker: @jorgefilipecosta

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

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

  • Gutenberg 7.3.0
  • 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

Andrew Duthie 3:35 pm on January 20, 2020
Tags: ,   

JavaScript Chat Summary: January 14, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript). Thanks to @cbravobernal for compiling these notes.

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

Date package

(Slack conversation)

@davilera mentions in the pull request issues a developer might face when using the date package and proposed how to solve them. Namely, source timezone, target timezone, and possible translation of the final date. People noticed that the package is not considering timezone.

Regarding PHP side, date_i18n() is remarked to be “illogical, incompatible with Unix timestamps, and in order to be deprecated”.

Action:

  • Identifying the minimum changes required to fix the original issue that PR tried to solve
  • Open a new issue where a discussion on if and how to refactor the package
  • Look at the current PHP implementation and trying to reconcile the two

Dropdown rendering with modals

(Slack conversation)

At first, the dropdown wasn’t rendering properly. But once the positioning was fixed, two more issues arose:

  • In a dropdown with multiple fields (such as, for instance, the one you get when using DateTimePicker), tabbing from one field to the other doesn’t work, as the focus moves away from the dropdown, back to the modal. This is an accessibility issue.
  • Dropdowns should be closed when one clicks outside of them. But this only works if you click outside of both the dropdown and the modal. Clicking on the modal doesn’t close the dropdown. Dunno what kind of issue this one is.

The mechanism that are affecting this behaviour is the SlotFill system 

@itsjonq says that the mechanism that are affecting this behaviour is the SlotFill system, and currently @hazdiego is working on an (unrelated) PR to start refactoring it:

https://github.com/WordPress/gutenberg/pull/19242

After a little discussion about how hard is to work on focus, modals, dropdowns…

Action:

Open Floor: Markdown linter

(Slack conversation)

@mkaz announce that he introduced a lint-md script that lints code blocks inside markdown. This uses a new .eslintrc-md.js config in scripts package to turn down some of the noise due to documentation being snippets of code.

Right now you need to run manually, we can fine tune and adjust the config before automating further. Try it out using: npm run lint-md [your-file] or if no file specified it runs across all markdown documents. 

Removing ES5 snippets is discussed also.

Action:

  • Try out the new script lint-md especially if writing or updating any markdown and source and we can see how it goes

Open Floor: NPM publishing

(Slack conversation)

@gziolo propose to grant npm permissions to @jonsurrell and Bernie Reiter so they could help with releases. Also talk about automate CHANGELOG file updates on the release day.

Action:

  • Grant NPM accesses (owned by @aduth)
  • Keep working on improving release workflow.

#core-js, #javascript

Jonathan Bossenger 9:50 am on January 17, 2020
Tags: ,   

WP Notify weekly meeting agenda for Monday 20 January 2020

This is the agenda for the next WP Notify feature project meeting, to be held on Monday, January 20, 2020, 14:00 UTC.

In order to start shaping the final requirements document, I’d like to start focusing on each section of the document, ensuring that it contains the correct information. The idea here is that we keep iterating on each section until we consider it complete, and then we’ll move onto the next.

So the focus of this meeting, and it’s recap post, will be on the section titled “Objectives”. The general agenda of the meeting will be as follows:

  • Opening and welcome
  • Reviewing and updating the requirements document: Objectives
  • Open floor

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

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications