The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
The weekly WordPress developers meeting takes place in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. channel of the Make WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. on Wednesdays at 20:00 UTC.
Dev Chat, October 27, 2022 meeting summary – thanks @webcommsat. Can you volunteer to help draft future dev chat summaries? Speak to @marybaum or @webcommsat if you can volunteer next week. There is help available.
@bph shared GutenbergGutenbergThe 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/ 14.5 RC1 has also landed! The pull request (PR), pending a release post.
@ndiego is the release leadRelease LeadThe community member ultimately responsible for the Release. for Gutenberg 14.5.
Performance chat summary, November 1, 2022 – has some ticketticketCreated for both bug reports and feature development on the bug tracker. updates including WebP, AVIF images, Object Cache. Also some calls for reviews.
@jeffpaul said he was most interested in what people are seeing in the forums, TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, etc. on concerns in 6.1 that might be earmarked for a 6.1.1 release.
@audrasjb: Aside from the WPML issue, I think it’s pretty quiet for a major releasemajor releaseA 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..
@jeffpaul asked what people were hearing or seeing in relation to 6.1.
Jeff highlighted that @annezazu has posted a couple items in #6-1-release-leads: Slack message: 1 & 2. – @annezazu: wanted to bring in feedback from what I’m hearing on WordPress.comWordPress.comAn online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ and VIP — There are some fatal errors related to WPML and some infinite loops reported in Trac Ticket #56926. Initially she proposed to flag this in the #hosting-community channel.
– @annezazu (post in the 6.1-release-leads on November 1): On a UXUXUser experience related note — seeing these main issues in GitHub:
@audrasjb raised that there seems to be an issue with ManageWP backups on 6.1. He did not feel it needed to be addressed on the WordPress core side, and would be a fix to be done by the service owner, as with the WPML issue.
@clorith raised Gutenberg issue #44166, reported pre-release. Highlighted that although it does not break usability, it does change visuals of sites in unexpected and some times not-so-nice-looking ways. BlockBlockBlock 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. inserter missing is a big one though.
@jeffpaul said there were items that got set aside in the run-up to the 6.1 launch that hopefully were documented and added to the 6.1.1 milestone in Trac as well.
@clorith: The “+” button missing on some scenarios item Anne listed.
Under Open Floor in the agenda, @NekoJonez advised there are reports of MailPoet crashing on 6.1, but had not recreated it on two websites using it. It is raised on the master post on the forums.
@jeffpaul suggested a scrub to identify what realistically could be targeted in 6.1.1. He recommended that anything that contributors would like to be included is set as a 6.1.1 milestone in Trac or labelled accordingly in GitHub. This way the tickets can be considered in a 6.1.1 scrub.
In discussion with @desrosj, this minor releaseMinor ReleaseA 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. could be in the week of November 14, 2022. This date they believe would be most ideal to get things done before the US Thanksgiving holidays and before some contributors might less available with the holidays and end of year vacation schedules. He highlighted that there were definitely some items that we would want to try and get into this sort of a “fast-follow release” and would be best not to delay until January. [A post dev chat update is at the end of this section in the notes]
@marybaum asked about putting a release squad together.
@jeffpaul: “I think we might be able to find a way on the who but part of that will be determining what we’re trying to get into 6.1.1 so we know what’s needed for help. Thus getting things identified and into Trac/GitHub appropriately will help.
@jeffpaul said he could probably lead a scrub on Friday, but would ideally need more contributors involved in the review. But before then, he called for everyone’s help to “share what you’re hearing and ensuring things are in Trac/GitHub so the scrub has a chance to collect what’s ideal in 6.1.1 so we can continue to push quickly if we’re going to realistically get something out the week of the 14th (which that timeline is a bit dependent on what it is we’re targeting in 6.1.1).”
@desrosj: due to the quick turnaround, he felt it probably makes the most sense to use 6.1 squad members with appropriate skill sets and backgrounds based on what needs to be included. He said there was just not enough time to onboard a new squad for this one.
5. Component Maintainers and Tickets updates/ requests for help
a) Components
@sergeybiryukov: Build/Test Tools, Date/Time, General, I18Ni18nInternationalization, 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., Permalinks: No major news this week.
@marybaum: Help/About and Quick/Bulk Edit: also no major news
@audrasjb: nothing new on Menus, Widgets, Upgrades.
No other updates from maintainers.
b) Tickets
None were raised.
6. Open Floor
@pbiron: raised the issue highlighted during Open Floor last week (thanks @webcommsat for including it in the summary last week). Read the discussion in full in the Make WordPress Slack. The discussion focused on changes to the pluginPluginA 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 that are not released into the wild in the form of a Gutenberg release for any testing/confirmation before being ported over for inclusion in Core (especially for a major release during RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).).
@jeffpaul replied that it was something at the top of his mind coming out of 6.1 and that he would like to to have a collaborative conversation with the 6.1 RCs, editor leads, and core leads to talk through the various pain points for core and Gutenberg processes, and how we might find ways to make that ‘work better’ for whoever steps in to help lead 6.2. Given that this group is likely focusing on 6.1.1 in the near term and that people will want some time off after that, it might be for January, unless someone from that group wants to try and schedule time before 2023?
@davidbaumwald: asked if this could be automated? Like PR commit exists in a release/tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)? He highlighted that it is “a bit tricky” as there some changes that happen when porting GB code to core(namespacing functions, file paths, etc.)
@pbiron highlighted discussion in the threads of the original message on Slack about the mechanics. He raised that what is concerning to some is that things from Gutenberg were merged into core for 6.1 before they were even merged into the Gutenberg trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., let alone a Gutenberg release.
@hellofromtonya: BackportbackportA port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. merge expectations / criteria: likely needs consensus on what can and cannot be backported to Core, such as first must be formally released in Gutenberg.
@davidb: as there’s so much to watch over, suggested core could have some sort of bot that checks a pull request (PR) to ensure it was in a previous Gutenberg release/tag.
@jeffpaul recognized that there are likely things that core needs to consider adjusting/changing to better accommodate Gutenberg. He described it as a two-way relationship. He said he did not not want to try and introduce something that impairs the Gutenberg team’s ability to continue their always-impressive velocity and release cadence.
@pbiron called for an early “real” discussion to take place.
@marybaum suggested a post on the Core blog to start the discussion.
@jeffpaul: said he would like to co-ordinate async conversation with key people from 6.1 to try and collaborate on a make/core post with thoughts that can evolve into more legitimate proposals/tweaks leading into 6.2.
@pbiron: post-major-release ‘recap/lessons learned’ make/core posts have been fairly standard recently, and recommended that this discussion should certainly be part of putting that together for 6.1.
@jeffpaul agreed and added that he would like a bit more interactivity to that than a form or comment sprawl on a post to collect input that’s summarized in a make/core post. “We need to impact change here as it was not a smooth process and if not for some experienced contributors / committers / code owners we may have been much worse off in 6.1 (so again, thanks to everyone who did contribute and try to help along the way!)”
@marybaum suggested a special extra Dev Chat Session to discuss this. @clorith agreed as it is about core processes. Discussion about setting up an special channel for the discussion, and some felt there were already too many channels.
@davidbaumwald suggested starting with asynchronous feedback and logistics handling first. Then move to some sort of sync meetings, if necessary. He thought the retro is probably the first piece to the puzzle.
@hellofromtonya reminded for this discussion to be fruitful, contributors from #core-editor need to actively participate too.
@marybaum suggested a long post on the Make/Core blog along the lines that @desrosj had introduced the problem on Slack (link at the top of this discussion summary)
@hellofromtonya: in relation to @jeffpaul‘s suggestion, Tonya felt starting with the 6.1 release squad’s Core and Editor leads is a good starting place to get the ball rolling.
Tonya added: “One more thought: participation in release retrospective forms is / has been low. Active multi-channel discussions could help. ‘Channel’ does not mean slack channels.
“The goal is continuous improvement. These retrospectives after a release need more participation to collect more feedback to help make things better. Leveraging the power of open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL..”
@davidbaumwald: Yeah, or questions/feedback offered with no response.
@marybaum highlighted that if contributors who send feedback, get no response, they may be loathed to offer more feedback in the future.
