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.

CSSCSS Cascading Style Sheets. 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 JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. 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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ includes custom properties. @sabernhardt mentioned the admin color schemes repo from @ryelle and a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. started for Dark Mode. I suggested a boldly titled ticketticket Created for both bug reports and feature development on the bug tracker. “Replace wp-adminadmin (and super 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

# 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!

CSSCSS Cascading Style Sheets. audit updates

We reviewed the process for the audit and discussed the high-level ticketticket Created for both bug reports and feature development on the bug tracker. “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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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 categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., other, or all of the above.

@joyously suggested incorporated the automated audit results alongside the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 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 adminadmin (and super admin) color schemes with custom properties which seems like a great candidate for introducting them to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. No ticket for that … yet! @michael-arestad mentioned the benefits of keeping in sync with the NPM components used in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. After the meeting, we discussed the intricacies of using the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. components in wp-admin, and if you’re interested, check out the meeting transcript here!

That was all for this week!

#summary #core-css

CSS Chat Summary: 2nd April 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1585861240051700

I (@isabel_brison) facilitated the meeting. 

CSSCSS Cascading Style Sheets. audit updates

  • @notlaura tested Parker, a stylesheet analysis tool, with results documented here.
  • @joyously suggested CSS Stats as another potential tool.
  • The a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team had a look at the audit tickets at their weekly meeting and had a few recommendations.
  • Based on a11y team feedback, we agreed to add notes to the audit on any CSS properties we find that are unhelpful for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).

Open Floor

@joyously requested we add a channel topic to #core-css, with the time of our weekly meeting, which we did.

@joyously asked if the audit would include editor CSS, or only wp-adminadmin (and super admin) pages. The current audit includes only wp-admin pages, but there was agreement on auditing both the editor and the default themes CSS at a later stage.

That was all for this week!

Next week @notlaura will be taking over the running of this meeting, due to daylight savings changes.

#summary

Dev Chat summary – April 1, 2020

@davidbaumwald led the chat on this agenda.

Full meeting translate on Slack.

This is the first devchat after the releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. of WordPress 5.4.

Announcements

WordPress 5.4 “Adderley” was released yesterday, March 31, 2020 as scheduled.

@audrasjb shared the stats for contributors to the release. There was a total of 552 contributors from 48 countries, 32% of them being new contributors. For more accurate release contributors statistics, please fill in your WordPress profile (if you want).

Highlighted Blogblog (versus network, site) Posts

@davidbaumwald shared the posts of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Privacy team about the WP Consent API feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. proposal and the Guidelines for Internet Explorer 11 support in WordPress.

Upcoming Releases

@davidbaumwald reminded that 5.5 has been in Alpha phase for a while now.

Components Check-in

@audrasjb announced the release of version 0.4 of Auto-updates pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party which contains all features initially planned fot the project; as well as Themes updates and email notifications. Design, copy and accessibility reviews and feedback are welcome from plugin authors and WordPress developers.

Open Floor

@howdy_mcgee called for a feedback on these old TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets: #29418, #39447, #46768, #37245, #38074, #37255 and #24142.

@azaozz shared the link of WordPress 5.4 master list in support forums. Please, go through this before posting a topic in the forums.

@ipstenu and @azaozz called for attention on respectively these two tickets #49753 and #4975, related to 5.4.

@howdy_mcgee pointed to #24780 and said he has made a document to track the supression operators in Core codebase.

@jeffpaul asked we should start taking a look at the 5.5 early tickets to review patches and look to get some of those in sooner. Here’s for reference the Trac query for 5.5 tickets.

@jeffpaul also suggested to schedule an early-specific bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub in the next couple of weeks to help move those tickets along. A few people voluntereed to lead these scrubs.

@bph reminded that the WPBlockTalk is happening on April 2, and everyone is welcome to register here.

#5-4, #5-5, #dev-chat, #summary

CSS Chat Summary: 26th March 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1585256425000800

I (@isabel_brison) facilitated the meeting. 

CSSCSS Cascading Style Sheets. audit updates

  • I looked into our possibilities for visual regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. testing and found that jest-image-snapshot integrates very well with our existing e2e testing tools. I’m preparing a prototype branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". that I will share on the ticketticket Created for both bug reports and feature development on the bug tracker. soon.

Open Floor

@sabernhardt requested feedback on a patch for adding print styles to wp-admin. Discussion ensued, and we agreed that:

  • Currently, when printing out wp-adminadmin (and super admin), the only thing that doesn’t show is the admin bar. This is not optimal, and print styles should remove all interface features not relevant to page content.
  • The print styles should apply to all wp-admin pages that have content and/or lists.
  • Work on the initial ticket should attempt to hide all common interface elements for print
  • If much further work is needed on individual pages, we should create sub-tickets for easier tracking/review.

And that was all for this week!

#core-css, #summary

CSS Chat Summary: 19th March 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1584651672176800

I (@isabel_brison) facilitated the meeting. 

CSSCSS Cascading Style Sheets. audit updates

  • I tested some automated tools we might use for the audit and updated 49638 with my findings;
  • @notlaura attended the design meeting and asked what designers would find useful with this audit (summary here).

Todoes

  • Create a doc for the audit outline.
  • Ask the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) folks what they would find useful as an audit outcome.

We also discussed and agreed on reviewing, as part of the audit, where we are using px units and others that might have a detrimental effect on responsive behaviour. 

Coding standards

I asked about the history of stylelint-config-wordpress, which is used in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ but predates it by a few years. 

@netweb later replied with some informative context that I will add here:

  • The Stylelint config was created with CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in mind, based on existing styles and in alignment with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. standards.
  • It was then updated when added to Gutenberg, especially the Sass-specific rules.
  • It wasn’t added to Core because it was picking up lots of errors that would need to be fixed, so needed a committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. to own the work.

The discussion then shifted to use of Grunt and Sass in Core. Sass is mainly used for theming in wp-adminadmin (and super admin), and the design team are looking at replacing its use with CSS custom properties. 

(@netweb later added that because Sass is widely used in Gutenberg this may be up for discussion, but likely Core will be dropping Grunt and moving to native npm scripts and @wordpress/scripts.)

This led to a discussion on IE support and graceful degradation. I suggested defining a set of rules for what is essential functionality that we need to support in IE, so we can be more confident in using shiny new tech for non-essential functionality. @michael-arestad suggested creating a ticketticket Created for both bug reports and feature development on the bug tracker. for that.

@michael-arestad expects that the biggest challenge post-audit will be implementing a predetermined selector format in a way that doesn’t break plugins with custom admin sections that depend on wp-admin styles. 

#core-css, #summary

CSS Chat Summary: 12th March 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1584046820150600

I (@isabel_brison) facilitated the meeting. 

Following on from last week’s discussion about meeting times and daylight savings changes, no one expressed a preference so we decided to keep meeting at the same time relative to UTC.

CSSCSS Cascading Style Sheets. audit status update

Progress this week was essentially creating tickets:

I also reviewed a ticketticket Created for both bug reports and feature development on the bug tracker. for removing some !importants from the common.css file: https://core.trac.wordpress.org/ticket/47569

@notlaura suggested checking in with design at the weekly meeting regarding any particular pain points they might be having with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSS.

There was nothing for open floor, so we finished early 🙂

#core-css, #summary

CSS Chat Summary: 5th March 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1583442173087500

I (@isabel_brison) facilitated the meeting. 

We started by discussing if we should change the meeting time to accommodate daylight savings changes coming soon. No decision has been made yet; if you have an interest in this meeting and changing/not changing the hour would enable you (or not) to attend, please leave a comment below!

Open Floor

@notlaura started by asking how best to kick off a CSSCSS Cascading Style Sheets. audit as discussed last week. Based on last week’s discussion, I had already created a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. to start thinks off: https://core.trac.wordpress.org/ticket/49582 and asked everyone to add to it if I missed anything.

@notlaura asked about workflows for regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. testing. There is no automated visual testing in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. yet, and we discussed setting up visual snapshot testing before making any changes to existing CSS. 

We agreed that adding snapshot testing will not blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. the audit, as the outcome of the audit will be a set of recommendations, but we should have tests in place before we start acting on those recommendations.

We also discussed how to divide up the audit into sub-tasks, and agreed to create smaller tickets to tackle each part as needed. 

@notlaura also suggested leveraging static analysis tools for the audit, suggesting this collection of resources: https://github.com/mre/awesome-static-analysis#css

@sabernhardt suggested running the audit on a public version of WP (5.4 when it’s ready, or one of the RCs if we start earlier), and shared a report on pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party testing for 5.3: https://make.wordpress.org/core/2019/10/15/report-wp-5-3-admin-css-changes-tested-against-top-20-plugins/ .

At which point we hit the hour, and wrapped up. 

#core-css, #summary

CSS Chat Summary: 27th February…

CSSCSS Cascading Style Sheets. Chat Summary: 27th February 2020

Full meeting transcript on Slack.

I (@notlaura) facilitated the meeting. The agenda was:

  • Idea for a CSS audit
  • Open Floor

CSS Audit

I began the first agenda item, “Idea for a CSS audit” with some general information about CSS audits, and this could be a useful way to inform an approach for reducing specificty and using newer CSS features in WordPress. I also mentioned that, for WordPress specifically, an audit might include understanding the experience of CSS contributors since CSS can be a powerful way to bring in new folks.

I posted a few resources to information on CSS audits:

Initial thoughts were positive. @bemdesign said that reducing specificity would makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). things easier for the future, and @marybaum identified it would be valuable to know how much of the codebase is in use, and how much of it is something we could modernize.

The following comments indicated the scope of an audit would also be something to take into account: is this only adminadmin (and super admin) CSS, or does it include themes and plugins?

@marybaum mentioned CSS in the default themes is an opportunity to model practices for other themes.

@afercia reminded us that large parts of admin CSS are also used by plugins, so we don’t want to refactor for the sake of introducing new features because it could break many plugins.

I added that the intent of a CSS audit would be to inform and update ongoing CSS standards, not solely introduction of new CSS features, and @peterwilsoncc emphasized the distinction between recommendation and accepted recommendation, and that the outcome of an audit would be more like a wish list and documentation of ideals.

I then asked about current conversations around design systems and coherence in the code-base, and linked to the Color Foundations in the Design Handbook.

@afercia mentioned that there is an additional color palette used in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, and that the co-existence of the two palettes is an ongoing issue.

@peterwilsoncc emphasized that this type of project would involve all teams, editor, design, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), at the very least.

These historical tickets came to light related to the audit conversation:

Open Floor

@xris asked about the importance of comments in CSS, and that most of the Core CSS seems to uncommented or that it does not follow commenting guidelines. They mentioned that the well-commented files – such as this one – are much easier to read.

The conversation then turned to the role of comments in general, and @afercia mentioned some history of the WordPress CSS comments: all CSS used to be a single, large file, and was commented when it was split into multiple files. Some of these legacy comments remain and are out of context.

I linked to the Comments section in the CSS Standards section of the handbook, and identified another high-level outcome of an audit could be to see where these standards are and are not followed throughout the code-base.

@afercia mentioned that we should publish this recurring meeting on the official / @peterwilsoncc followed up a few days later that this has been completed!

And that concludes the meeting summary!

#core-css, #summary

Dev Chat Summary – February 19th, 2020 (5.4 week 6)

@francina facilitated the chat on this agenda

@cenay took care of publishing the summary notes. Special thanks to @valentinbora, @amykamala and @audrasjb for the peer review on these summary notes. 

Full Meeting transcript on Slack

This devchat marked week 6 of the 5.4 release cycle.

Announcements

WordPress 5.4 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2 was released yesterday, February 18, as scheduled.

  • 5.4 Beta 3 is scheduled to be released on February 25, 2020. (Note to committers and maintainers, the cut off time to get bugs fixed and into WP 5.4 is February 25th, 20 UTC)
  • 5.4 is intended to be released March 31st, 2020.

Agenda

  • Status report on the About page – content and design
  • Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide. 
  • Highlighted Posts: XML Sitemaps Kickoff Meeting Announcement 
  • Component Check-ins

5.4 Beta 3 to be released on February 25th

As mentioned, WordPress 5.4 Beta 2 was released on February 18th, 2020. 

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

@audrasjb suggested it would be great to schedule one or two bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs before the next beta so we can puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.)/help the 134 remaining tickets in the milestone. @francina “seconded” with a call out for anyone who has spare time to help organize a bug scrub (See this post for how to run one). Open tickets for 5.4 can be found here (in order of priority). The Bug Scrub schedule for 5.4 lists scheduled scrubs for anyone to join in. 

Status Report on the About Page – Content and Design

@karmatosed stated everything is lining up to start the About page earlier this releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.. There will also be a push to document this. @melchoyce and @elmastudio are leading the design charge on this with @marktimemedia riding along to observe. @marybaum added they’ve got chunks of the copy written and she promised to share it with major-release-squad.  

Dev Notes Status 

..and how to proceed to get them all published in time for RC1 and the Field Guide.

@audrasjb reports since the last dev chat, four new dev notes were published:

@audrasjb also reports to date, they have a dev note published for about 50% of closed tickets with the `needs-dev-note` keyword in the milestone and 4 drafted dev notes ready to publish. He is very confident they’ll have all dev notes published by the end of the month (during last week before RC1)

@jorgefilipecosta reports he is tracking the progress of the block editor related dev notes and requests that any feedback before the dev notes are published would be great as the content there was not yet reviewed and is just what the original people involved in a PR think the dev note should contain.

@johnbillion asks that if anyone sees changes going into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that they think need a dev note, to leave a comment on the ticketticket Created for both bug reports and feature development on the bug tracker.. @audrasjb adds “if you think there are some important tickets that don’t have the `needs-dev-note` keyword, please get in touch with me”. @azaozz asks that you ensure the dev notes are really for developers and are concise and to the point and preferably with a code example of changed usage. @jorbin reminds us to remember the guidelines for posts and the need to have a peer review. 

@francina thinks having a separate page with guidelines on submitting dev notes would be helpful. @earnjam mentioned @desrosj would have a draft written up on the subject.

Highlighted Posts

@francina announced the highlighted post. There were no comments. 

Component Check-ins

  • News from Components
  • Components up for adoption (i.e. looking for maintainers): Filesystem APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and Rewrite Rules
  • Components that need help
  • Cross component collaboration

News From Components

Administration

@valentinbora reports 1 week after he took up Administration, 40+ tickets have been triaged with 2-3 moved to other components. Per the previous meeting’s discussion regarding the very existence of the Administration component, @valentinbora thinks it’s here to stay.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/

@jeffpaul raised the issue of Gutenberg development overlapping existing Core components and how to best communicate with their respective maintainers/teams. @francina proposed a continued discussion about the cooperation between Components and Gutenberg out of the meeting.  

Widgets & Menus

@audrasjb noted 3 bug fixes with `commit` keyword and concerns about managing the transition and backward compatibility with tickets referring to current widgets/menus and new tickets referring to full sitesite (versus network, blog) editing (FSE). 

@noisysocks recommends that maintainers of the widgets, customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. and editor components get involved and look at the relevant labels in the Gutenberg repository. 

Open Floor – Announcement

@pbiron announced that a new version of the WordPress Beta Tester pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party was released earlier today with a new feature. On the settings screen (`Tools > Beta Testing`), once you’ve already updated to either `Point releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. nightlies` or `Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. nightlies`, you’ll see a new option for `Beta/RC`. Once you’ve set that as your current stream, you’ll only be updated when the next beta or RC (or official) is released rather than the nightlies. 

One advantage of this new feature is that you’ll be able to update to beta or RC packages right in the Dashboard (Dashboard > Update) as soon as the packages are built during the release parties if you’re not comfortable using wp-cliWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/.  Hopefully, this will increase the pool of testers during the release parties.

As the meeting was over time, the remaining two topics from today’s agenda were not started. 

Action Items

These items were discovered within the content as stated action items.

  • @francina to add the bug scrubs to the meetings page (like she did for 5.3)
  • @francina to add “creating a separate page with dev note guidelines, adding comments to a ticket” to her desiderata. Check with @desrosj who might have a draft of a page with details about how to write a good dev note.
  • @audrasjb and @welcher should look at Widgets/Menus issues/PR on Gutenberg
  • @noisysocks to add a ‘call for volunteers’ to the next core editor chat to implement proactive communications from Gutenberg to those component maintainers to help find ways to work together.
  • @jeffpaul suggests we call out notice to the new WordPress Beta Tester plugin in the Beta 3 blogblog (versus network, site) post (and future posts as well) so folks looking to help test have a starting place. 
  • @clorith wants to chat about how to move more things into a ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. world and how to do it outside of Gutenberg.
  • @noisysocks to “put something up” on Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility)./Core to continue the conversation about cooperation between Components and Gutenberg (i.e. Cross Teams Collaboration).

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, Wednesday, February 26, 2020 at 21:00 UTC

#5-4, #summary