Editor chat summary: Wednesday, 3 July 2019

This post summarizes the weekly editor chat meeting on Wednesday, 3 July 2019, 14:00 WEST held in Slack.

The agenda followed can be found here.

Task coordination

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!

@nerrad

Implemented the first pass at a potential solution for the element interpolation i18n problem https://github.com/WordPress/gutenberg/pull/16374.

@youknowriad

  • Worked on some performance related PRs. Mostly tried to make the getBlock selector more performant as it’s the bottleneck in terms of typing performance.
  • Reviewed a bunch of PRs. One of the most important is the Customizer Panel to edit block-based widget areas PR by @epiqueras.
  • Plans to land the block reordering animation soon.

@aduth

Made a few small pull requests, reviews, focusing mostly on “custom” sources for blocks (reimplementing meta to start)
https://github.com/WordPress/gutenberg/pull/16402.
Referred that the issue with the publish button https://github.com/WordPress/gutenberg/pull/16303 has a significant impact and might be easy to review if someone wants to take a look.

@danr

Continues working on table block tasks. Has a couple of PRs ready for review:

Has a PR which changes the way the blocks.registerBlockType filter works. Would be happy for more testing on it: https://github.com/WordPress/gutenberg/pull/16348

@welcher

Worked on some PRs related to SlotFill with https://github.com/WordPress/gutenberg/pull/13361 being the highest priority, followed by https://github.com/WordPress/gutenberg/pull/16384, in his opinion.

@kjellr

Has been posting some work on revised, less-intrusive tips:
https://github.com/WordPress/gutenberg/issues/16315.

He is hoping to get PR https://github.com/WordPress/gutenberg/pull/14961 merged, once we can figure out the mysteriously-failing test.

Did some initial work on the Patterns API, and hopes to get that posted until the end of the day: https://github.com/WordPress/gutenberg/issues/16283

@getdave

Has been working to allow any Block to be registered to handle “Grouping” interactions. Received non-consensual feedback some people think that it is a good idea while others think the opposite.
Additional feedback is welcome:
https://github.com/WordPress/gutenberg/pull/16278.

Has been working on Block Previews component along with @joen to allow it to dynamically resize and handle scale a lot better: https://github.com/WordPress/gutenberg/pull/16113.

@nadir

Continues the work on Snap to grid RFC.

@jorgefilipecosta

Answered & debugged some issues and submitted bug fix PR’s. Reviewed some PR’s, including the blocks in the customizer and the custom parser options. Proposed a simple mechanism for themes to register styles and did updates to the image Link UI refactor PR, which was recently merged.

@chrisvanpatten

Has been doing some light PR reviews and issue replies… Is aiming to schedule a Gutendocs bug scrub session next week; if anyone has specific days/times that work and you want to join, feel free to comment! @chrisvanpatten would love to get good attendance.

Agenda: Non-code contributions

@youknowriad introduced the topic by referring that the idea is that we value code contributions (or PRs more precisely) more than other types of contributions: PR reviews, triage, discussions in issues… The consequence is a growing list of unreviewed PRs and untriaged issues.

@epiqueras proposed some ideas to explore:

  • draft documentation for what is good triage and reviewing, why it’s important, and where new contributors should start.
  • highlight some good live PRs to review for people to take a look at.
  • recognize these types of contributions so that their value is more obvious.

@karmatosed referred that design / technical feedback should be added to the previous list.

@youknowriad a small first step today was that he tried focusing more on “non-code” contributions during the Task Coordination and tried to highlight this work more.

@karmatosed noted that we could expand beyond ‘did you review PRs’ to say ‘did you leave feedback or offer insights’.

@nadir shared that:

being a new contributor, based on my experience in trying to review PR I would say it was really hard for me because sometimes you really need to understand the codebase, things that are agreed upon, the norms and what’s not.

the only PR that I could review are related to things I already solved issues on or had PR related to, but I felt that I wasted a lot of the core team time reviewing basic problems like how to document eslint disable rules and how to write code that matches the core team theme

@karmatosed made an essential point that every single moment investing in someone as awesome to try and contribute isn’t a waste

@mcsf thanked the share made by @nadir and said:

I think that’s a very real issue for anyone coming to the project. I have a suggestion for easing into reviewing other people’s work: recognise that you can still provide helpful feedback even when you’re not an “expert”. This, to me, means that you could define the scope of your review, or your abilities: “I can only speak about this component”, or “about the overall readability”,
Concluding by saying that a newcomer’s eye can reveal a lot of blind spots in PR’s.

@aduth also thanked the share made by @nadir referring that he is inclined to say that we need more documentation for the things @nadir referred. Followed with a set of questions: Is this documentation as it’s organized today very effective? Do you have any thoughts on what might be an effective way for you to become aware of norms and such?

@karmatosed continued the conversation by stating that: Docs are just docs. It’s surfacing and being in the right place counts.

@nadir added that triaging was also an excellent way for him to contribute since he worked on two components when he started (button & snack bar), filtering issues & PR by those components gave him a good ability to review and understand what is happening

@brentswisher joined the conversation and supported the idea of “draft documentation for what is good triage and reviewing”.

@youknowriad proposed a welcome bot that comments PR’s of new contributors. The discussion went on with people sharing insights regarding that idea and how a concrete bot implementation could like.

@karmatosed shared the following actions points as a discussion summary:

  • Recognize and highlight non-code contributions more during weekly meetings
  • Surface the docs better (how?).
  • Improve the docs. (can we create an issue to discuss what needs to be improved and how)
  • Add thoughts to welcome bot and project board: https://github.com/WordPress/gutenberg/projects/24#card-17518302
  • Consider what role of welcome contributor could be.

And ended with a reminder: “We are all human.”

Open Floor

The open floor started with a question by @joyously: How the editor can better support themes? She added:

The old editor has an easy interface to add “Formats” with a simple PHP filter that makes a button in the editor. When can we have that again? Why change the interface to the theme? (new API)

@youknowriad answered by saying:

I think there’s a difference in the paradigm that makes applying “random classNames” to “random HTML” not a good fit for the block editor. While in TinyMCE we’re adding content as HTML, in the block editor we’re adding content as blocks which means any markup we add should be meaningful for the block.

So the idea is that we have two use-cases here:
– Apply a style variation to the block (known block) (className + stylesheet)
– Apply an inline style variation (inline class name) in RichText. We don’t have an API for that one because it’s less common, but I think you should feel free to open an issue about this “Custom Format” (talking about the RichText Format API ).

#core-editor, #editor-chat, #summary