CSS Chat Agenda: 23nd April…

CSS Chat Agenda: 23nd April 2020

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

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

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

  • CSS audit status update
  • Color Scheming status update
  • Open floor

#agenda, #core-css

Auto-updates feature meeting summary: April 21, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday April 21, 2020. You can read the full transcript on the core-auto-updates Slack channel.

As a reminder, WP Auto-updates Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Version 0.6.0: introduce AJAX handling on auto-updates enabling/disabling

Thanks to @ronalfy who did a great job on this, auto-updates enabling and disabling action links are now using AJAX calls.

@audrasjb added wp.a11y.speak support to communicate AJAX enabling/disabling changes to screen readers.

@ronalfy opened an issue to improve AJAX responses error messages. This is currently the last issue slated to milestone 0.6.0.

@pbiron also opened an issue to evaluate the opportunity to include version info in email notifications.


Last minute edit: WP Auto-updates 0.6 was released earlier today 💥


Next step: Core merge proposal

The idea is to start to work on the core merge proposal once version 0.6 is released.

Concerning the core merge itself, @audrasjb two approaches:

  • Merging the feature in a single Trac ticket
    • Pros: Easier testing of the overall scope.
    • Cons: A single ticket could be a potential rabbit hole, with endless discussions on the overall feature, so it could be more efficient to manage small and self contained tickets.
  • Merging the feature step by step, with several tickets
    • Pros: It’s more efficient to ship the feature step by step so the steps that are potential blockers could land later, in other releases, if they deserves more discussion. This is the process we used for the development of the feature plugin so it won’t be so difficult to reproduce those steps in several Trac tickets.
    • Cons: It’s a way more difficult to test the overall feature when there are several tickets to test.

Please feel free to comment this post to share your thoughts!

As noted by @whyisjake and @sergeybiryukov, both approaches makes sense. @pbiron noted that Lazy-loading Feature was done in one commit. However, the feature doesn’t bring any UI change.

For @whyisjake, WP Auto-updates is pretty light as well and could fit with the single patch option.

For @afragen, if the merge tickets can be made in logical, non-dependent code blocks, then it would probably be good to do it this way. Otherwise as a single patch.

@whyisjake pointed out that even if the feature is a goal for 2020, it will necessarily need an approval from @matt / @chanthaboune, first.

As it’s a mandatory first step, @whyisjake proposed his help on the Core merge proposal post and started a collaborative Google Doc.

The idea is to publish this post next week, to fit with WordPress 5.5 Alpha development planning.

@pbiron added that once our work is merged into core, we should all be prepared for some things to be reverted/changed after the first “real world” beta tests.

Open floor

@ronalfy asked if there is any plan to handle translations auto-updates, like email notifications. @sergeybiryukov answered that when language packs were added to core, the idea was that they should always update automatically in the background and do not need a specific UI or notifications.

@paaljoachim added that with @ibdz, they added additional screenshots to the visual que issue. Additionnal thoughts are welcome.


Next meeting is scheduled on Tuesday April 28, 2020 at 17:00.

#5-5, #auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

Editor Chat Summary: 22nd April, 2020

This post summarizes the latest weekly Editor meeting (agenda, slack transcript). This meeting was held in the #core-editor Slack channel on Wednesday, April 15, 2020,14:00 UTCand was moderated by @paaljoachim.

WordPress 5.4.1 Upcoming Release

Note: There was a miscommunication around this release and these notes originally expected the launch to happen the same day as the meeting. This has been corrected.

@jorgefilipecosta shared a comment prior to the meeting detailing the plan for 5.4.1 RC. All 5 PR’s to include were in Gutenberg 7.9, meaning they were tested in at least one Gutenberg plugin release. This RC release is slated for Friday with the full release planned for next Wednesday per an update from @whyisjake.

Weekly Priorities

No discussion on weekly or monthly priorities

Task Coordination

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

@zebulan

@get_dave

  • Has been working on the ability to create a Navigation block from existing WP Menus. @karmatosed posted a new design route that we need feedback on if people have time to review.  

@marek

Open floor

Should we keep CONTRIBUTORS.md? Raised by @soean.

Only 140 people are listed, but we have more than 550 code contributors, so it is not up-to-date. We don’t use this file in other repos. A GitHub -> WordPress connection is now built in on wp.org.

Discussion ticket started by @mkaz:

  • We don’t use this kind of file in other WordPress repos. 
  • The file overall is a bit confusing and it doesn’t seem to be a great way to acknowledge all contributors currently. 
  • There are inconsistencies in who is added with some long term contributors missing.
  • The file itself seems to be for highlighting non code contributors to the project.
  • The contributors tracking that GitHub provides only shows contributors for specific timeframes. 
  • @soean shared this neat project https://allcontributors.org/ that might be interesting to explore.

Next Steps: @mkaz will update the file to provide a link to the code contributors listed on GitHub, followed by the list of non-code contributors. If people have other thoughts, please add to the ticket to discuss. 

Is using `render_callback` a good solution for handling conditionally loading assets? Raised by @mkaz.

This question is based on a long standing but stalled out ticket trying to address this within Gutenberg automatically. @mkaz wrote a post examining `render_callback` but this approach  requires each plugin/block to set it up. If this is determined to be a best practice to move forward on, we should likely update documentation to encourage developers to take a similar approach. 

Next Step: We didn’t have enough folks online to have a robust discussion about this so @mkaz will create a discussion ticket to carry the conversation forward. 

Problems with the Drag & Drop Experience explored in this ticket. Raised by @jules-colle.

There are general concerns around how the current experience is continuing negative perceptions of Gutenberg for end users. Right now the problems are adding up leading to both a rough experience and an overwhelming set of problems. Right now, it seems the issues would benefit from being broken down into smaller pieces.  

Next Step: Thoughts are welcome on this main ticket.

Should we give more folks access to @here abilities in slack?

At the beginning of the meeting, we realized no one had permissions to @here in slack to alert folks to the meeting. This led to a quieter meeting this time around but we likely should expand access to those who run meetings so we can ensure better meeting engagement.

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

Dev Chat Agenda for April 22, 2020

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

Announcements

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

Upcoming Releases

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

Highlighted blog posts

Components Check-in

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

But in the meantime… the usual:

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

Open Floor

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

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

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

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

Editor Chat Agenda: 22nd April, 2020

Facilitator: @paaljoachim. Notetaker: @annezazu.

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

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

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

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

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

#agenda#core-editor#editor-chat

Editor chat summary: Wednesday, 15 April 2020

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

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

Gutenberg 7.9.0

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

Priorities

The priorities are still the same though and available here

Task Coordination

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

@youknowriad

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

@zebulan

@sageshilling 

@itsjonq

@michael-arestad

@brentswisher 

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

@karmatosed

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

@andraganescu

  • Worked on various issues around the navigation menus replacement experiment

@aduth

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

@desaiuditd 

Open Floor

@check2020de

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

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

@mboynes

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

Looking if/when we can get to it:

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

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

It’s totally fine to close and reopen issues.

@joostdevalk

Pinning behavior for plugins has changed

Regression/bug in plugin pinning .

@marekhrabe

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

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

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

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

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

JavaScript Chat Summary: April 14, 2020

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

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

Internet Explorer End-to-End Testing

(Slack conversation)

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

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

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

Discussion Points:

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

News Roundup

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

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

#core-js, #javascript

Chat Summary: 16th April 2020…

Chat Summary: 16th April 2020

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

I (@notlaura) facilitated the meeting.

CSS audit updates

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

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

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

Open Floor

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

That was all for this week!

#summary #core-css

Proposal: Core Team Rep Elections

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

The Role

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

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

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

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

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

Here are the main tasks:

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

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

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

Nominating

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

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

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

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

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

Voting

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

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

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

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

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

Results

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

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

Next steps

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

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

#proposal, #team-reps