Start of meeting on Slack
This DevChat starts with an experiment to shift the chat to synchronize discussions and away from dropping of links.
Discussion on open proposals in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
Default Theme Task Force for 2024
Link to the post: Proposal: Default Theme Task Force for 2024
Dev Chat slack link
Comments in Dev Chat focused:
- positive feedback and highlighting that people can self-nominate their ability to help triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. those open default theme issues
- promote the call to encourage people to be active in triaging and resolving those 436 Bundled Theme tickets
Latest position from @desrosj :
- advised the idea has been accepted: t’s rallying a group of folks to get through and clean out the Bundled Theme component backlog on Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
- three self nominations and more expected to be confirmed by end of the week
- aim to start before the end of January 2024, currently 437 tickets in the Bundled Theme component
- Jonathan will be leading the team as a mentor and someone with commit privileges, and other committers are welcome to help as well)
- the week to week working arrangement will be depends on the team’s availability. Stay tuned!
- confirmed the new theme task force group will remain under core team purview. More detail on this in the comments section of the post. More contributors for the Themes team welcome to help out too. “It’s a balance though, My goal here was to allow those contributors to continue exploring what new themes look like while this team handles cleaning up some of our cruft and backlog for pre-existing ones.”
- expecting ‘as a side effect, cleaning out the backlog also will effectively “retire” these themes in some ways, and going forward, the majority of the tickets will be 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. editor support related (hopefully).’
Actions:
- more volunteers needed and will increase the speed can go through the outstanding tickets in the component
- to assist, contact @desrosj on Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. on in the comments for the post itself
Proposal to improve the editor tech workflow for major releases
Post link: Proposal
Dev Chat Slack link
Context: This proposal was started in 6.4. With 6.5 underway, thinking the learnings from 6.4 could be built upon for how to continue improving the Core merges from Gutenberg 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/ during 6.5. Core Editor and Core chats are now combined into Dev Chat as an experiment.
Discussion:
- @joemcgill raised the question of the right venue to push this forward. “In my opinion, the current status quo is error prone and unsustainable (as well as taking a lot of manual overhead from contributors).”
- @jorbin: If we want to try early syncing for 6.4.3, https://core.trac.wordpress.org/ticket/59828 just needs a second committers review and we can get all the updates into the 6.4.x nightly
- @hellofromtonya: I’m not sure either what the “right venue for pushing this forward” is. Needs a discussion with both Core and Core Editor folks to figure out the needs and how to improve these workflows. Seems earlier the better as Beta 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. 1 is fast approaching
- @jorbin suggested one way to mitigate the issue would be nominating the release team, or at least the editor tech, for the next release before the current release ships. An interim editor tech to help get the ball rolling while an official team has not been announced. @joemcgill agreed having an identified set of release leads for 6.5 to discuss how they want to handle things for this release would help. The Community Summit conversation was very helpful. A working group to continue that conversation and come back with concrete proposals would be helpful, if a release team is not the right venue. A working group had positive feedback in the dev chat discussions as these workflows are continuously improving and span more than one major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. @jorbin suggested @tellthemachines should be given right of first refusal to continue leading the effort since she kicked off the proposal.
- Ideas included: a proposal needed to address the identified set of problems, a hallway hangout similar to the ones @annezazu and others have done.
Actions:
Forthcoming releases
6.5
Slack discussion link
See this section in the agenda for updates, helpful links, and information for the 6.5 release.
Blockages/ items need discussion for progress:
- Font Library:
- Discussion:
- As a follow-up from @joemcgill‘s questions last week, @hellofromtonya has added the Core merge criteria/expectations to its Trac ticket Created for both bug reports and feature development on the bug tracker.. The critieria is the same as in 6.4, except Tonya is suggesting returning to the expectation the feature is merged before or by Beta 1.
- Query raised on the criteria aspect of “running on wp.com, and not being reliant on any specific host testing this. @hellofromtonya: The reason for wp.com is: it’s a normal workflow in Gutenberg as it gains a huge amount of sites running it. @jorbin
- @annezazu suggested some of the contributors who have worked on this feature could comment. Also noted current timeline for the feature https://core.trac.wordpress.org/ticket/59166#comment:21
- Question: Is this anything beyond what we’d normally expect of a feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.? @hellofromtonya: Same expectations except for REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. part of it , as I’m suggesting a maintainer needs to give a thumbs-up to its design.
- jorbim: I don’t want to discourage that in any way, I just wonder if we would ever set a requirement like “Is running on Altis with no major issues”
- Actions:
- Update the criteria from the discussion. Done ✅
- Gather expectations from the REST API maintainers and then update the criteria accordingly. Done ✅
How was the first experimental new DevChat?
@jorbin said: “I think one of the most productive meetings in a while”
@afragen shared there was no extra time to raise other tickets for discussion.
What to change?
Next week, reserve 10-15 minutes for open forum / floor discussion.
Props @hellofromTonya for peer review.
#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary
