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

Riad Benguella 11:49 am on February 13, 2020
Tags: , , ,   

An updated Button component in WordPress 5.4

The Button component is a central piece of any Design System. As the WordPress design system implemented by the @wordpress/components package matures, its set of components get updated to gain in consistency and coherence. In WordPress 5.4, the Button component has been enhanced with several changes and additions.

Button sizes

To align with the overall design direction of the project, the button default height has been increased and is equal to 36px. This means the previous isLarge prop variation is unnecessary and should not longer be used.

The Button still support the isSmall variation. 

import { Button } from '@wordpress/components';

const regularButton = <Button>My Button</Button>;
const smallButton = <Button isSmall>My Button</Button>;

Also, for consistency between the design of all the button variations, the buttons now have an explicit height in their CSS style. If you were relying on the fact that the height of buttons is dynamic and should adapt to its content, make sure to override the style of your button and add the following CSS rule.

height: auto;

Icon support

In previous versions, the components package used to offer a Button component to be used for regular buttons and an IconButton to be used for buttons with icons.

In WordPress 5.4, you can pass an extra icon prop to the regular Button component to display buttons with icons, you can also mix text and icons.

import { Button } from '@wordpress/components';

const myIcon = (
  <svg xmlns="http://www.w3.org/2000/svg" viewport="0 0 20 20">
    <path r="M5 4l10 6-10 6V4z" />
  </svg>
);

const SimpleIconButton = <Button icon={ myIcon } label="Button label" />;

const IconAndTextButton = (
  <Button icon={ myIcon }>
    Button Text
  </Button>
);

Note that the IconButton is still available but is officially deprecated.

Classname changes

In previous versions, the icon buttons used to rely internally on the components-icon-button. Now that the Button and IconButton components are merged into a single component, this class name has been removed and is replaced with .components-button.has-icon.

Note that it is recommended that you don’t rely on any internal className used by the different components. if you want to target a specific component, prefer providing your own className prop and use it instead.

Going further

If you want to try and play with the Button component or all the other wordpress/components, check out the components Storybook.

#5-4, #block-editor, #components, #dev-notes

Jb Audras 11:30 pm on February 12, 2020
Tags: , , ,   

Dev Chat summary – February 12, 2020 (5.4 week 5)

@davidbaumwald facilitated the chat on this agenda.
@audrasjb and @marybaum took care of publishing the meeting notes.

Full meeting transcript on Slack

This devchat marked week 5 of the 5.4 release cycle.

Announcements

WordPress 5.4 Beta 1 was released on Tuesday 11 as expected 🎉

WordPress 5.4 Beta 1

Highlighted posts

Upcoming releases – 5.4

As mentioned, WordPress 5.4 Beta 1 was released on February 11th, 2020.

Please help by testing the Beta and reporting any bugs on WordPress Trac (or Gutenberg GitHub repository).

The Docs squad has published the first two dev notes:

The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field Guide before Release Candidate.

@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature plugin and then merge into Core for 5.5.

Work on this feature plugin will start in the coming weeks.

Components check-in

@valentinbora is the new Administration Component maintainer.

In 2014, Administration was proposed to be moved from a component to a focus so it wouldn’t end up as a dumping ground for tickets. That decision led to its removal from the Components page, but not anywhere else.

Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triage all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.

@whyisjake is now a Security Component maintainer.

Open floor

@whyisjake told the group that he’s going to help Two-Factor Authentication, currently developed on GitHub, move toward becoming a feature plugin for WordPress Core.

A first step: a proposal on Make/Core. @desrosj and @clorith are also interested in the project, which has been a discussion topic in the core-passwords Slack channel and in this GitHub pull request.

@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.

@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.

#5-4, #auto-update, #security, #two-factor

David Baumwald 6:58 pm on February 12, 2020
Tags: , , ,   

Dev Chat Agenda for February 12, 2020 (5.4 Week 5)

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

Announcements

  • This week marks week 5 of the 5.4 release cycle 🙌

Highlighted Blog Posts

Upcoming Releases – 5.4

  • Beta 1 Released

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

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

Jb Audras 6:22 pm on February 12, 2020
Tags: , ,   

Changes related to Calendar Widget markup in WordPress 5.4

The HTML 5 specification permits the <tfoot> to precede the <tbody> element. That changed in HTML 5.1 and now <tfoot> must follow <tbody>.

Historically, the Calendar Core Widget used the <tfoot> element to display the calendar’s navigation links. But since the HTML 5.1 spec has changed, WordPress 5.4 moves the navigation links to a <nav> HTML element that comes right after the <table> element.

Moving navigation links outside of the <table> element offers better accessibility, with clearer distinction between elements. And a <nav> element is the semantically correct element for any navigation system, in any context.

Here’s a sample of the Calendar Widget’s former HTML markup:

<div id="calendar_wrap" class="calendar_wrap">
	<table id="wp-calendar">
		<caption>February 2020</caption>
		<thead>
			<tr>
				<!-- Day Names -->
			</tr>
		</thead>
		<tfoot>
			<tr>
				<td colspan="3" id="prev"><a href="https://example.com/2020/01/">« Jan</a></td>
				<td class="pad"> </td>
				<td colspan="3" id="next" class="pad"> </td>
			</tr>
		</tfoot>
		<tbody>
			<!-- Calendar Grid -->
		</tbody>
	</table>
</div>

And here’s a sample of the Calendar Widget’s new HTML markup:

<div id="calendar_wrap" class="calendar_wrap">
	<table id="wp-calendar">
		<caption>February 2020</caption>
		<thead>
			<tr>
				<!-- Day Names -->
			</tr>
		</thead>
		<tbody>
			<!-- Calendar Grid -->
		</tbody>
	</table>
	<nav aria-label="Previous and next months">
		<span id="prev"><a href="https://example.com/2020/01/">« Jan</a></span>
		<span class="pad"> </span>
		<span id="next" class="pad"> </span>
	</nav>
</div>

If you’re a site owner, and especially if you’re a Theme author, you are invited to test this change thoroughly. You may need to make some CSS adjustments.

For example, here are the visual differences for Twenty Twenty, the current Bundled Theme.

Before this change:

After this change:

For full details, see the related ticket on Trac: #39763

#5-4, #dev-notes, #widgets

Eileen Violini 6:04 pm on February 12, 2020  

Editor chat summary: 12 February 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 12, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. Moderated by @youknowriad.

WordPress 5.4 

Update from @jorgefilipecosta: Beta 1 was released 11 February, 2020 and it highlights a big number of Block Editor Features. From now on, all PR’s tagged with backport to wp core, will be included on the next WordPress release. We don’t have an automatic process for this, as a bug fix may be to a feature not part of WordPress 5.4. PR authors should try to be aware if the bug fix they are submitting is present in WordPress 5.4. If that’s the case the tag should be added, or when In doubt or if the user has no permissions to manage labels, please ping me in the PR so I can have a look. In some special cases or if we find the potential risk of the fix is high we may decide otherwise, but this would be an exception.

Gutenberg 7.5

Update from @youknowriad: Gutenberg 7.5 had a shorter lifecycle than regular Gutenberg releases. A one week release. This was needed to adapt as closely as possible to the WordPress release dates (beta 1). That doesn’t mean it had fewer features though. The changelog is really exciting and includes:

  • Social links blocks marked stable
  • Support for tiktok embeds
  • Inline text color support
  • Support adding featured images to Latest Posts block
  • and a lot more

The release will happen late on 12 February, 2020.

Weekly Priorities

WordPress 5.4 is still a big priority for us. I believe we’ll be working on bug fixes and any critical issues raised during the release cycle. Other than that, the priorities are listed on the monthly roadmap post.

Task Coordination

@mkaz  I have open questions around an approach for making Social Links extendable: PR 19888

@karmatosed Focusing on global styles, now about to do a few things:

  • Update sidebar designs for v1.
  • Explore beyond v1.
  • Spent some time auditing the block styles used and as a result about to create an issue to add some to v1 styling (specifically line height).
  • Working on some component focused iterations.
  • Continuing to work on triage as needed and whilst been a little in deep with 5.4 surfacing to keep that going.

Continuous props to @jorgefilipecosta @itsjonq and @nosolosw for being fearless global styles squad peeps.

@youknowriad

  • Working on the icons package, trying to complete the refactor but still some work ahead
  • Opened a PR to add more tips to the block inserter
  • Trying to help with G2
  • Focusing a bit on writing dev notes on the next days

@jorgefilipecosta  During the last week, I performed an audit to experimental APIs, triaged issues, reviewed PR’s and patches, submitted multiple bug fixes, updated packages in core, added/removed blocks from the core, checked the PR’s needing dev notes and proposed a structure for the notes, and continued involved with part of the global styles conversations and provided some feedback. For the next week, I will focus on writing some dev notes, submit some bug fixes, review PR’s, triage issues and PR’s to make sure we backport the PR’s to core and I will extend the edit-site module to support a sidebar extensibility mechanism like edit-post does.

@nosolosw  My main focus this week has been in consolidating the server-side data mechanism for global styles v1. It’s going to land in the next days under the FSE experimental flag PR 20047. Next, I’m starting work on making something useful with that data: theme integration & block styles, connect it to the UI controls PR that @itsjonq  put together, etc.

@itsjonq As others have mentioned, I’ve been focused on Global Styles. Coordinating with various folks, planning, thinking through things, and implementing the initial integration with FSE via the “Edit Site” page

@retrofox  Navigation Block

  • Merged the new design for sub menus (very significant)
  • Improve color handling: custom and colors by ID. light/dark styles as default.
  • Improve propagation data <Navigation /> and <NavigationLink />
  • Consolidate styles between front-end and editor-canvas
  • Fixing many visual issues
  • just in case and as usual, developing dashboard: https://github.com/WordPress/gutenberg/projects/31 (edited) 

@aduth I’ve been helping push for some final tasks for WordPress 5.4 / Gutenberg 7.5, notably: Fixing up some link editor workflow regressions, removing columns auto-adjusting behavior. There’s a bit more follow-up work to that. Also looking at some issues with polyfills needed for WordPress 5.4, and generally trying to focus on a few known bugs that were let slip.

@andraganescu

  • continued with the author block
  • did reviews and some small PRs
  • learning more on FSE
  • will pick up something from the Iterations on “Latest Posts” Block – version 2 Issues 20046  which I invite you all to check 

@mapk 

  • Digging into G2 more.
  • Working on Templates and Template Parts UX.
  • Taking a gander at Block Patterns UX as well.

@jeryj Added an `onFocus` handler for the LinkControl that will fetch the current input search suggestions (if there is an input value). This lets the suggestions list be fetched when people are editing an existing link.

  • Helping @getdave with smaller tasks on the massive Create new Page from within the Nav Block PR 19775
  • Various Navigation Block UX improvements in the last couple weeks

Open Floor

Resizeable Editor

@isabel_brison wants to highlight the resizable editor PR 19082 that was just merged. CSS transformations don’t work in two cases at the moment: for theme editor styles because they are loaded as inline styles and for CSS in JS styles. @youknowriad responded for the theme editor styles it’s important to support the resizing but said he believes the issue could be solved since we control that inline style; it’s included by the block editor itself and it already has some transforms support, so a way to rewrite it can definitely be found.

@jorgefilipecosta added  For theme editor styles because they are loaded as inline styles, I think as long as themes add the marks required the mechanism may work well. The API’s used to transform the media queries should also work for inline styles. Our code may need to be aware that the marks we used may be wrapped inside a class in editor styles.

@itsjonq added CSS-in-JS styles I took a look at the implementation. Since it’s working with document.styleSheets, we can perhaps adjust the logic to include CSS-in-JS generated StyleSheet instances to be included for enhancement. However, it’ll only affect styles upon trigger. Any dynamic styles added in between trigger phases won’t be enhanced (this applies to any dynamically generated styles though, not exclusive to CSS-in-JS).

@youknowriad replied the CSS in JS problem is good to raise but it still remains to be seen whether that’s a problem or not. I don’t expect block styles to use CSS in JS anytime soon and @jorgefilipecosta agreed saying he’s  not seeing how blocks would use css in js for the markup they produce. @itsjonq mentioned the CSS-in-JS implements may (and probably should) be limited to just wordpress/components, so in that case, it may be okay.

Easier PR Testing Methods

@paaljoachim asked for an easier way to test PRs before they get merged. @aduth has a site at http://gutenberg.run and developed on GitHub. He also reminds the team about answering in the Gutenberg forums @youknowriad agrees pointing out a lot of developers and users struggle and those on Core team probably have  the best answers for them. So if you need to take a break from PRs and issues, do take a look at the forums from time to time. More coordinated efforts will be organized on the forums especially after WP stable releases.

Global Styles and Full Site Editing (FSE)

@itsjonq highlighted work on Global Styles. The team started off by building the initial foundations for the system (huge props to @jorgefilipecosta + @nosolosw), which involve things at the PHP layer. Since Global Styles is still under development, it has been built so that it cannot be activated (unless you follow a series of steps). That way, it ensures regular Gutenberg as well as FSE does NOT get affected. The team is progressing to the stage where they are implementing things in the UI, specifically the Gutenberg Edit site editor. Still very early days! But it’s coming along.

Backported Bug Fixes

@aduth regarding the earlier comment from @jorgefilipecosta We don’t have an automatic process for that as a bug fix may be to a feature not part of WordPress 5.4 — are we expecting that the only bug fixes which will be backported must have been introduced as part of WordPress 5.4? Or just merely that it is “present in” (i.e. could we still include bug fixes for things already present in 5.3?) @youknowriad responded it applies to all bug fixes and to all features already in Core (not just the ones introduced and @aduth replied he’d like to try get Isssue 18416 fixed.

Integrating Hooks in Blocks

@markhowellsmead  asked if there are there any plans to integrate hooks to server-side rendered blocks (e.g. latest posts), so that their output can be modified by a Theme? @youknowriad said there are already hooks available render_block to alter the server-side rendering of any block. If you’re asking about specific hooks for specific blocks, that’s probably unlikely to happen unless there’s a generic use-case we can extract from it.

Trac Tickets and Release

@jorgefilipecosta  reminds everyone with in progress trac tickets to verify if they are assigned to 5.4 milestone and, in that case, try to bring them to the finish line, if needed pinging people for reviews. When we are releasing a beta/RC tickets with 5.4 milestones that are not bugs or blessed tasks are a blocker for the release so if possible verify if you have any tickets on this list some time before the WordPress releases, if there are tickets on this list, please try to remove them by changing the milestone, type (if it could be considered a bug fix), or committing/ asking a committer to review it and commit it.

Ella van Durpe 5:55 pm on February 12, 2020
Tags: , ,   

What’s new in Gutenberg? (12 February)

This is the last release that is going to be fully included in WordPress 5.4, containing one week of updates from 45 contributors. The release cycle was temporarily shortened to align features with WordPress 5.4 Beta 1.

The Social Links block has been in the works since a few releases, but now it’s a stable (no longer experimental) block.

Adding a Social Links block.
Adding a Social Links block.

Rich text can now be coloured!

Adding inline colour to text.
Adding inline colour to text.

It is now also possible to display featured images in the latest post block.

Latest post with featured images.
Latest post with featured images.

7.5 🇹🇭

Features

  • Mark the Social Links block as a stable block 20134 19887 20074 20150 20101
  • Support adding featured images to Latest Posts block 17151
  • Add support for TikTok video Embeds 19345
  • Add inline text color support 16014
  • Add text color support to Columns block 20016

Enhancements

  • Add type and angle picking to the custom gradient component 19582
  • Add transform for button to buttons block 20063
  • Navigation block:
    • Implement new design for sub-menus 19681
    • Set inherit color to anchor elements 20038
    • Fix getting Navigation parent block 20032 20057
    • Set width in order to show caret 20075
    • Improve colors handling 20022
    • Rename background color CSS class 20018
  • Block Library: Avoid column width auto-adjustment when sibling width changes 19515 20169
  • A11y:
    • Incorporate settings in the edit state of the LinkControl component 20052
    • Announce all Notice components messages 15745
    • Button block: Remove title attribute 19735
    • Navigation block: Remove title attribute 19990
  • Image block: Keep existing caption if the stored one is empty 19641
  • Enhance the custom gradient picker UI 20099

New APIs

  • Allow third-party keyboard shortcuts registration in the keyboard shortcuts modal 19965
  • Stabilize the AnglePickerControl component 20118
  • Add .wp-env.json config file support to wordpress/env 20002
  • Blocks: Promote block variations to stable API 20068
  • Mark the gradients theme API as stable 20107

Experimental

  • Add ability to disable the block popover through __experimentalUIParts.hasPopover option 19922
  • Add the __experimentalEditorSkeleton component to the block-editor package 20050 20132

Bug Fixes

  • A11y: Show open button when the sidebar is closed and tabbing out of the content 19726
  • IE11 Compatibility: Add DOMRect polyfill 20110
  • Block Editor: Fix warning when rendering InnerBlocks 20082
  • Featured image appears cropped 20128
  • Fix predefined text colors used in the Group block on the frontend 20119
  • Use array form for contrast checkers. 20143
  • i18n: make experimentalUseColors labels translatable 20112
  • Multi select: remove inserter between selected blocks 20096
  • Remove alignment options from nested Button blocks 19824
  • URL: Conform to URL Living Standard definition of valid URL 19871
  • Select the correct media in the media modal when replacing existing media 20100
  • Avoid resizing the editor canvas when opening the publish panel 19843
  • Fix Media & Text block styling when media is set to show on the right 20125
  • Fix excerpt rendering in the Latest posts block 19669

Documentation

  • Docs: Contributor Guide update subpages 19939
  • Prettier: Update format-js to use default config, and update editor docs usage 20036
  • Target docs to manifest.json 15639
  • Update main project README 19743
  • Update the Getting Started Docs to use wp-env 20044
  • Typos and tweaks: 20055 20077 20025 20060 19470

Various

  • Block Editor: Update BEM syntax to CSS modifer guidelines 19738
  • Block Library: Standardize PHP function names used 20085 20039
  • Project Management Automation:
    • Log skipped tasks and retain wrapped task names. 20034
    • Support adding milestones for fork PRs. 20058
    • Avoid gracefully handling error 20009
    • Avoid milestone task for forks 20049
    • Call core setFailed with error message 20012
    • Check error object for parsed errors 20014
    • Guard against non-matching commits in addMilestone. 20147
    • Tolerate duplicate milestone 20011
    • Pull Request Automation: Avoid automation tasks for forked repository 20021
  • wordpress/env:
    • Fix GitHub source pattern 20131
    • Fix syntax error where spread operator could fail 20113
  • Move existing icons to the wordpress/icons package 20091 20072 19959 20094 20087
  • Ensure the default Prettier config is used with lint-js when needed 20071
  • Data: Log first-pass useSelect errors 20122
  • Compat: Social Links: Remove legacy renderers from packages 20098
  • Core Data: Mark the getEntityRecordNoResolver selector as experimental. 20053
  • Core Data: Remove unused __experimentalUseEntitySaving hook. 20148
  • Hide the navigation block behind feature flag 20133
  • Fix Intermitent e2e test failures 20065
  • Move the e2e tests to the right folders 20135
  • Switch social link icons to import svg parts from primitives 19877

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.5.0 6.491s 34.695ms
Gutenberg 7.4.0 6.413s 36.81ms
WordPress 5.3 6.331s 75.19ms

#core-editor, #editor, #gutenberg

Jb Audras 9:51 am on February 12, 2020
Tags: ,   

Formal deprecation of some unused Customizer classes in WordPress 5.4

WordPress 4.9 deprecated the WP_Customize_New_Menu_Control and WP_Customize_New_Menu_Section PHP classes and wp.customize.Menus.NewMenuControl JavaScript class. The Core Team initially planned to remove them entirely in WordPress 5.0.

Deprecated items

Given how much time has elapsed since then, WordPress 5.4 leaves in place WP_Customize_New_Menu_Control and WP_Customize_New_Menu_Section to prevent potential backwards compatibility issues. 5.4 also formally deprecates them using _deprecated_file() and _deprecated_function() calls.

As a reminder:

_deprecated_file() is used to mark a file as deprecated and inform when it has been used. There is a deprecated_file_included hook that can be used to get the backtrace up to what file and function called the deprecated function. The behavior is to trigger an error if WP_DEBUG is true.

_deprecated_function() is used to mark a function as deprecated and inform when it has been used. There is a deprecated_function_run hook that can be used to get the backtrace up to what file and function called the deprecated function. The behavior is to trigger an error if WP_DEBUG is true.

Removed item

WordPress 5.4 removes the wp.customize.Menus.NewMenuControl JS class completely. This JS class can’t be used anymore starting with WP 5.4.

For reference, see the related Trac ticket: #42364

#5-4, #dev-notes

Eileen Violini 1:12 pm on February 11, 2020
Tags: , , ,   

Editor Chat Agenda: 12th February 2020

Note taker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for Wednesday, February 12, 2020, 09:00 AM EST. This meeting is held in the #core-editor WordPress Slack channel.

Highlighted Blog Posts

Discussion Topics

  • WordPress 5.4 Upcoming Release
  • Exclusion of the Navigation Block from the 5.4 Release
  • Gutenberg 7.5.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

#editor

tellthemachines 5:34 am on February 11, 2020
Tags: ,   

CSS Chat Agenda: 13th February 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, 13th February, 9pm UTC.

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

Agenda:

  • Welcome
  • Setting standards for use of new(-ish) CSS features: grid and variables
  • Looking at tools to improve our workflow: CSS-in-JS
  • Open Floor

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-css

Jonathan Bossenger 6:29 am on February 10, 2020
Tags: ,   

WP Notify weekly meeting agenda for Monday 10 February 2020

This is the agenda for the next WP Notify feature project meeting, to be held today, Monday, February 10, 2020, 14:00 UTC.

Agenda

  • Opening and welcome
  • Reviewing and updating the requirements document: Use Cases
  • Reviewing and updating the requirements document: Current Status
  • Open floor

We will continue by focusing on one or two sections of the requirements document. First we will review “Use Cases”, then we will move onto “Current Status”.

Due to a small misunderstanding on my part with the Slack notifications system during last week’s meeting, we’ll also allow a few minutes for any specific feedback to the Objectives section, before considering that item closed.

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