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 Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. 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 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. Panel to edit block 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.-based widget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. 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 Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 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 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 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. 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 User interface 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 The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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 HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.” 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
