Tag Archives: summary

Sarah Norris 10:44 pm on April 3, 2024
Tags: , , 6-6-release-squad, , summary   

Summary, Dev Chat, April 3, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

Announcements

WordPress 6.5 “Regina” was released yesterday! Thank you to everyone who worked on, tested, and supported this release 🎉

Forthcoming Releases

Next major releasemajor 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.: 6.6

We are officially in the WordPress 6.6 release cycle. @priethor published this WordPress 6.6 Planning Proposal & Call for Volunteers post last week. Please take note of the following callouts on that post:

  • Please leave your feedback about the schedule and release squad size in the comments by April 7th.
  • If you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments, specifying the role and the type of involvement (lead/cohort).

@colorful-tones and @fabiankaegy will be covering and merging TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./GutenbergGutenberg 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/ Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. for 6.6, and if anyone has any recommendations to streamline things for overall Triage to make lives easier, then please reach out to them.

For 6.6, we discussed considering not having a sticky post for the bugbug 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. scrub schedule and instead ensuring the schedule is linked at the top of the main release page.

We also discussed 6.5.1, and noted that @jorbin published a post: Initial Bug Scrub for 6.5.1 for tomorrow. @fabiankaegy mentioned that the editor team have created this new board in GitHub to track any editor-related issues that may be candidates for a point releaseMinor Release A 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.. Currently, there are 5 tickets with the backport to wp minor release label.

We also already have quite a few tickets targeted for the 6.5.1 milestone, so any eyes before the initial bug scrub will likely help that be more efficient.

Next Gutenberg release: 18.1

The next Gutenberg release will be 18.1, scheduled for release on April 10, and will include these issues.

Discussion

We began by discussing any potential follow-up actions and reflections following the recent 6.5 release. @fabiankaegy asked about starting a conversation about possibly evolving how we approach the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. and dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. in future releases.

@jorbin has previously opened a related proposal to updating the field guide. We discussed where the most appropriate place was to start a conversation like this, and whether it sits more with CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., Docs, or Project. As it touches on many different areas and how we do things within software release cycles, then it seems to fit more into the Core team’s scope.

@audrasjb suggested this may be good to discuss in the future #6-6-release-squad Slack channel so maybe the squad could discuss it in the open with the future Docs Leads and come up with a formal proposal for 6.6 on Make/Core.

@joemcgill also proposed arranging another release retrospective post to collect feedback about the release while it’s still fresh in people’s minds. @chanthaboune mentioned being able to do this in any way that works for folks. For 6.4, we collected the data in an anonymized format and then that data was shared on make/core, and we discussed potentially following a similar approach for 6.5.

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

We started by highlighting this PR for the WP Importer in support of the Font Library from @mmaattiiaass.

@kkmuffme mentioned that they’re looking for reviews on several PRs, listed in this message and this message.

Two additional issues that were raised in the agenda comments were:

  • https://github.com/WordPress/gutenberg/issues/15117 – “the excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5., that impacts all plugins incl. WooCommerce”
  • https://core.trac.wordpress.org/ticket/59270 – “adding border setting to columns”

This issue was highlighted: Responsive previewing and device-specific editing. Nolan asked what the best way was to make a decision on the issue, as this has been open for 4 years. @annezazu replied with:

I understand that’s an important issue — it has been for a long time! I know some designers have recently chimed in there and there’s some momentum gathering. The best thing to do at this point is to be specific and keep sharing what would be helpful. Beyond that, the main blockerblocker A bug which is so severe that it blocks a release. is finding solid design solutions and finding specific/targeted ways to implement as anything that is implemented has to be maintained.

Also, @webcommsat highlighted a forthcoming contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. which is looking for core input and people to join. More info on here on Slack.

Props to @joemcgill for reviewing.

#6-5, #6-6, #dev-chat, #summary

Sarah Norris 3:20 pm on March 28, 2024
Tags: , , , summary   

Summary, Dev Chat, March 27, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

Announcements

WordPress 6.5 was scheduled for release on March 26, 2024, however, the release has now been rescheduled for April 2, 2024. Thanks to everyone involved in the related discussions around delaying the release by one week. You can read more in this post.

Forthcoming Releases

Next major releasemajor 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.: 6.5

There was a lot of activity in the #core channel today with everyone coordinating efforts around 6.5. There is a good summary of the conversations from @desrosj on Slack here.

Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 BetaBeta 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. 3.

Next GutenbergGutenberg 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/ release: 18.1

Gutenberg 18.0 was released on March 27 and included these issues. The next Gutenberg release will be 18.1, scheduled for release on April 10.

Discussion

We discussed the upcoming 6.5 RC4 scheduled for March 28, and we seem to be in really good shape. The following contributors are lined up to help:

We revisited plans for the 6.6 release squad. @priethor has a drafted post ready to publish with further details, however we have delayed the call for volunteers whilst decisions were still being made around 6.5. Now that we are in a good place for 6.5, @priethor suggested that we consider posting the call for volunteers after the 6.5 RC4 release party. Please leave a comment with your thoughts.

@jorbin shared that we’re still looking for a Gutenberg maintainer to help out with the 6.5 maintenance releases, but otherwise, we have all the pieces we need. The current release squad members are always welcome to help (but also understand that they may need a break). @jorbin also confirmed that the date for 6.5.1 is still being decided, but will avoid upcoming holidays where possible.

Please leave a comment if you’re interested in being part of the 6.5 maintenance releases. There are more details in the handbook about what’s involved in being part of a release squad.

Highlighted posts

The full list of posts from the last week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can be read on the agenda at this link.

Open floor

During the open floor, Shariar Mahmud Prince requested help with an issue with the meta box docs, and @marybaum helped open a docs issue.

@joemcgill mentioned that the past several weeks have been intentionally focused on any discussion around WordPress 6.5, but we will soon have the bandwidth to discuss other topics and it would be great for those topics to be proposed by the attendees. Discussion topics can always be proposed in the comments of the agendas themselves, but @joemcgill and @mikachan would like to start to get a bit of a backlog of ideas to prioritize. We can do a call for topics posts, but would be happy to take any suggestions you have in the meantime.

@jorbin raised the following potential topics:

  • How can we get PHP8 support completed and out of “compatible with exceptions”
  • Aligning the coding standards for Core and Gutenberg so that both can use the same tooling

Tony Gravagno asked about improving the marketing around each WordPress release, especially about the release teams, and how people contribute to this huge effort in multiple cycles per year. @desrosj mentioned that there is a related ticket here, and @marybaum suggested that this fits well with the Marketing team’s new direction.

Props to @joemcgill for reviewing.

#6-5, #dev-chat, #summary

Sarah Norris 7:30 pm on March 21, 2024
Tags: , , summary   

Summary, Dev Chat, March 20, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

Announcements

WordPress 6.5 RC 3 was released on March 19, 2024, and Gutenberg 17.9 was released on March 13. Please continue to help test and provide feedback.

Forthcoming Releases

Next major releasemajor 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.: 6.5

We are in the final week before WordPress 6.5 is scheduled to be released, with a Dry Run scheduled for next Monday, March 25, and the release scheduled for Tuesday, March 26.

@swissspidy and @sergeybiryukov will both be around to help during the Dry Run.

Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 BetaBeta 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. 3.

Next GutenbergGutenberg 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/ release: 18.0

Gutenberg 18.0 is scheduled for release on March 27 and will include these issues.

Discussion

Given that this was the last dev chat before the 6.5 release, we concentrated on discussing any final decisions, blockers, etc.

@swissspidy suggested starting with the Font Library:

From what we’ve seen so far, it seems that adding such a fallback logic appears to be more complex than originally anticipated and that it’s not feasible to land this in time for 6.5. Adding a silent fourth RCrelease candidate One 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). solely for that would be too risky.
So for 6.5 we might want to consider:
1. Leave the current situation as-is (fonts go to `wp-content/fonts`, no fallback)
2. Point people to plugins such as Fonts to Uploads and the dev-note explaining how to change the upload location.
3. Re-evaluate fallback logic for 6.5.1 or 6.6 if needed, also considering potential folders in the future (patterns, templates, AI models, etc.)

We discussed how the fallback logic is proving to be more complicated than expected and will present a future maintenance burden and potential for bugs that aren’t worth the risk of rushing to land a fix. We mentioned alternative options, including delaying the release and removing the Font Library.

The suggestion from release leads and people familiar with the latest state of the Font Library was that it is in a good enough shape to include, and that the difficulty is in the implementation of the potential automatic fallback and not in implementing the feature itself. Therefore, the plan following the conversation was that the feature will be shipped without the fallback logic in place.

Based on this, the following actions should be taken:

  1. A post on make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to communicate the decision — @peterwilsoncc offered to start on a draft
  2. Update the docs with a pointer to the pluginPlugin A 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 — @flexseth offered to help update docs (@mikachan also happy to help here)
  3. Update https://wordpress.org/plugins/fonts-to-uploads/ to a Canonical plugin with maintenance by WP Contributors/WP.org with source moved under the WP org on GitHubGitHub GitHub 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/ so that it’s a shared responsibility
  4. Once the post outlining the decision to change to the the fallback directory behavior is posted, we should inform #forums, along with a request from them to be on the lookout for issues with the lack of a default Font Library fallback — @jorbin offered to help with this

Also related to the Font Library, @grantmkin noted that there is a wordpress-importer PR that needs review if someone has expertise and availability.

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

There were two issues raised on the agenda:

  1. Would the fix for plugin zip file uploads be included in 6.5?
    • Yes, the fix is merged into 6.5
  2. Will we have an extra RC, since there are some unresolved Font Library tasks?
    • There is currently no extra RC release planned

When discussing whether we needed another RC, the suggestion was to release an RC for any necessary Font Library changes (or any additional needed code changes) later this week, while the $_old_files change and theme bumps are handled during the Dry Run without publishing an extra RC.

@joemcgill closed the chat by suggesting that if the purpose of an RC is to allow time for more testing, to not make it silent, and encourage the release leads to finalize a plan. Coordination about an extra RC continued following the meeting in the release leads channel.

Props to @joemcgill for reviewing.

#6-5, #dev-chat, #summary

Sarah Norris 11:40 pm on March 13, 2024
Tags: , , summary   

Summary, Dev Chat, March 13, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

Announcements

WordPress 6.5 RC 2 was released yesterday, March 12, 2024 and Gutenberg 17.9 was released earlier today. Please continue to help test and provide feedback.

Forthcoming Releases

Next major releasemajor 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.: 6.5

We are in the final weeks before WordPress 6.5 is scheduled to be released, with our final scheduled Release Candidaterelease candidate One 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). (RCrelease candidate One 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). 3) scheduled for next week.

There are several important changes to our normal development process during the RC stage. For more, see this post: WordPress 6.5 Release Candidate Phase.

Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 BetaBeta 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. 3.

@marybaum confirmed the release team for RC3 on Tuesday, March 19, 2024. @audrasjb as the committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., with @hellofromtonya on backup and @davidbaumwald as mcpilot; @akshaya will host with @priethor as backup.

@swissspidy also shared that RC3 is the last scheduled RC before the stable release. The topmost priority should be solving the Font Library uploads location as per Josepha’s recent blog post. If you would like to help, there is an open architecture discussion where you can get involved, and a couple of remaining related PRs:

Primarily, we need to find a robust way to ensure that, when deleting a font, the font files are deleted from the right folder. If we don’t have a solution for the above by RC3 we could consider an additional fourth RC.

There are also some open Interactivity API bugs and editor bugs, but nothing severe. It would be helpful if these issues had owners. @joemcgill suggested scheduling another bugbug 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. scrub this week to review these issues and assign owners.

Next GutenbergGutenberg 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/ release: 18.0

Gutenberg 18.0 is scheduled for release on March 27 and will include these issues.

Discussion

The discussion today started with organizing release squads for 6.5.x and 6.6 releases.

@jorbin confirmed that we’re still looking for folks to be involved in the 6.5.x maintenance releases. Please reach out if you’re available to help with these releases – particularly if you were already involved in the 6.5 releases (but that’s not a requirement).

@priethor has a draft for a post that identifies people who have raised their hands for 6.6.

A related discussion topic is whether we should reevaluate the size of release squads prior to 6.6. This came out of the discussion following the 6.5 release squad announcement (context). There was a discussion around the pros and cons of having larger release squads, including:

  • Larger squads spread the responsibility that used to be focused on just one person to a bigger team. However;
  • It doesn’t feel like there is much need for others to help or be involved when there are so many people responsible for a release.
  • The more individuals, the greater number of relationships and opportunities for both cliques and interpersonal conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved..
  • It sometimes leaves the team not knowing who should be making key decisions about features.

There were also suggestions for better documenting the responsibilities both within the release squad and within a lead group. Also, having feature leads would be helpful, i.e. folks spearheading and owning a specific big feature in a release.

@joemcgill suggested that we could review the release squad size as part of a debrief post for 6.5, and @priethor is working on a proposal for a reduced release squad that will be published in the upcoming days.

Highlighted posts

The full list of posts from the last week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can be read on the agenda at this link.

Open floor

We did not have time for open floor this week.

Props to @joemcgill for reviewing.

#6-5, #dev-chat, #summary

Joe McGill 10:14 am on March 7, 2024
Tags: , , summary   

Summary, Dev Chat, March 6, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @mikachan.

Announcements

WordPress 6.5 RC 1 was released on March 5, 2024. Thanks to everyone involved and those who helped test.

Forthcoming Releases

Next major releasemajor 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.: 6.5

There are several important changes to our normal development process during the RCrelease candidate One 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). stage. For more, see this post: WordPress 6.5 Release Candidate Phase.

Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 BetaBeta 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. 3.

During the meeting, @marybaum confirmed the release team for RC2, scheduled for next Tuesday, March 12, 2024. @akshayar will host, @davidbaumwald will run Mission Control (MC), and @audrasjb will be the committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. (with @hellofromtonya as a backup).

Next GutenbergGutenberg 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/ release: 17.9

Gutenberg 17.9 is scheduled for release on March 13 and will include these issues.

Discussion

The discussion topic for today centered on: how can we make it easier to follow the decision process of major decisions across the project? This was originally raised by @marybaum and there is some background discussion here.

The discussion starts here in Slack. There were no clear next steps identified, but a summary of topics raised include:

  • We could consider having a way to share more regular status updates for primary features in a release in order to surface key decisions, request feedback, get more visibility of concerns raised, etc.
  • When key decisions need to be made, how can we ensure the context is easily accessible?
  • We should be careful about not adding more noise to the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team blogblog (versus network, site) during an already busy release period.
  • When key decisions are made, they should be documented in an appropriate place that is easy to reference (e.g., GitHubGitHub GitHub 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/, TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., Core Team blog, etc.)

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

Due to time, we did not have time for open floor this week.

Props to @mikachan for reviewing.

#6-5, #dev-chat, #summary

Joe McGill 9:52 am on February 29, 2024
Tags: , , summary   

Summary, Dev Chat, February 28, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Announcements

WordPress 6.5 Beta 3 was released on February 27, 2024. Thanks to everyone involved and who came to help test.

Forthcoming Releases

Major releasemajor 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.: 6.5

WordPress 6.5 Release Candidaterelease candidate One 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). 1 is scheduled for next week (see release schedule). A call for testing for BetaBeta 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. 3 was posted earlier today. See: Help test WordPress 6.5 Beta 3.

During open floor, @marybaum asked for confirmation on roles for the release party for next week:

GutenbergGutenberg 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/: 17.8.0

Gutenberg 17.8.0 released earlier today. The What’s new in Gutenberg 17.8? (28 February) post was published following the meeting.

Discussions

With this being the last Dev Chat before WP 6.5 RC1, the discussion focused on issues related to the release. Specifically, the Font Library, and organizing release squads for 6.6 (and 6.5 minors).

Font Library

This discussion begins here.

@swissspidy noted that some concerns were raised about the upload location, capabilities, and use (or not use) of attachments for storing metadata.

Background conversation starting in Slack, and following on these GitHubGitHub GitHub 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/ issues (props @jorbin):

@youknowriad identified this as the next step:

I’d love if we can get an agreement on this https://github.com/WordPress/gutenberg/issues/59417 at this point it doesn’t seem like a consensus is possible, so I’m unsure how a decision like that is made.

The next step identified in the meeting is for the release tech leads (@davidbaumwald, @swissspidy, @get_dave, and @youknowriad) to make a decision about the next steps for this feature’s inclusion in this release based on the input that has already been given on the relevant tickets.

Organizing release squads for upcoming releases

As we’re nearing the end of the 6.5 release cycle, it’s a good time to start getting squads in place for the 6.6 and 6.5.x releases.

A previous Call for Volunteers was made, which included all three major release for the year. @marybaum volunteered to follow up an help wrangle a followup effort for the 6.6 release cycle.

@jorbin agreed to help identify folks who could help with release responsibilities for 6.5 minor releases, since he’s helped lead the minor releases during the 6.4 cycle.

Highlighted posts

The full list of posts from the last week in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can be read on the agenda at this link.

Open floor

See the previous note in Future Releases section about coordinating roles for the RC1 release, that was raised during open floor.

@poena pointed out that we did not discuss one topic on the agenda: “Should we reduce the number of leads?”. @joemcgill agreed to include this discussion in a future meeting agenda.

Following the meeting, @costdev asked for feedback on #60504. Mainly: Whether this is a blockerblocker A bug which is so severe that it blocks a release. and if so, how can we unblock it for the long term?

Props to @mikachan for reviewing.

#6-5, #dev-chat, #summary

Joe McGill 12:25 am on February 22, 2024
Tags: , , summary   

Summary, Dev Chat, February 21, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Curated agenda and facilitation: props to @joemcgill

Announcements

WordPress 6.5 Beta 2 was released on February 20, 2024. Thanks to everyone involved and who came to help test.

Gutenberg 17.8 release is planned for Feb 28, 2024. Please help test.

Forthcoming Releases

Major releasemajor 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.: 6.5

@marybaum shared that there is a Hallway Hangout planned for the same day as the 6.5 BetaBeta 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. 3 release, next week. To help with a smooth release process in order to avoid a scheduling conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved., she asked for volunteers for committing and Mission Control (MC). @audrasjb, @swissspidy, @davidbaumwald all agreed to be available with @hellofromtonya saying that she’ll be available to help during RCs

@joemcgill reminded everyone that we are 2 weeks away from 6.5 RC1, and dev-notes should be published as soon as possible to be included in the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page..

  • The documentation team has this this project board that is being used to track dev-notes.
  • This report on Trac shows that there are additional tickets marked with needs-dev-note.
  • @swissspidy expressed concern that the process for dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. is not clear this release, which led to some further discussion. @joemcgill pointed out that we should be following the process included in the handbook, or making sure that it is updated to be accurate.

Discussions

Check in on the recent experimental format for Dev Chats, specifically to not share highlighted posts during the meeting and instead focus on discussion of an open proposal. (Slack link)

To summarize the main topics that were raised during that discussion:

  1. Overall, response to the new format is positive.
  2. @jorbin suggested “for Alpha time, it was fantastic. I wonder if it would make sense to move more towards a focus of “How can we help the next release” during beta/RCrelease candidate One 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). and then come back to the proposals”.
    • @joemcgill agreed to prioritize release discussion over proposals during the rest of this release cycle.
  3. @joemcgill asked for feedback on how to ensure we’re choosing the most useful topics for discussion
    • @jeffpaul: Seems there’s a backlog of things we could continue to pull from the Community Summit posts?
    • Action: propose a way for us to collect and nominate priorities for future discussions.

If you have additional ideas for topics that should be discussed in future meetings, or ideas for how to better organize/prioritize topics for discussion, please share in the comments.

Highlighted posts

The full list of posts from the last week in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can be read on the agenda at this link.

Also, from last week’s agenda, this section provides updates on the core-editor and the Developer blog, including the latest topics that need writers.

Open floor

@costdev provided an update on the PluginPlugin A 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 Dependencies feature for 6.5.

Key updates:

  1. Auto-deactivation of plugins with unmet dependencies, all bootstrapping logic, and the plugin_data option have been removed, and Plugin Dependencies now mostly runs on plugins.php and plugin-install.php.
    • This significantly reduces the footprint of Plugin Dependencies, removes the risk of the database and cache becoming out-of-sync on high traffic sites, and resolves a concern about consent-less deactivation of plugins.
  2. An accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issue has been fixed.
  3. Plugin updates on plugins.php were failing due to some JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. that I had not guarded correctly. This has been fixed.
  4. Most of the remaining work is on messaging, and is making steady progress (PRs in re-review stage).

Here’s a summary of where things stand with each ticketticket Created for both bug reports and feature development on the bug tracker., which we’ll also be posting the meeting summary on Make/Core following this evening.

Props to @azaozz for reviewing.

#6-5, #dev-chat, #summary

Joe McGill 3:48 pm on February 15, 2024
Tags: , , summary   

Summary, Dev Chat, February 14, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Curated agenda: props to @webcommsat

Facilitator dev chat: props to @joemcgill

Forthcoming Releases

Major releasemajor 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.: 6.5

@marybaum made another request this week for contributors to fulfill roles of Mission Control, Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., Security, and MarComms for the release parties.

@webcommsat asked if there was an update on scheduled bugbug 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. scrubs during the betaBeta 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. period of 6.5. In the meantime, she marked the current schedule post as sticky as requested by @oglekler.

  • Action: The triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. leads for 6.5 can update the post with scheduled dates for 6.5

Maintenance releases

There is one ticket in the 6.4.4 milestone that is ready for back-porting. However, @jorbin advised that he does not currently expect another maintenance release before 6.5.

Discussions

Proposal: Implement a PHP autoloader in WordPress Core (Slack link)

To summarize the main topics that were raised during that discussion:

  1. A decision needs to be made about how to handle early loading/overriding of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. classes. This seems to be the primary concern to address.
  2. There is some concern about the implementation requiring manual updating of the class file, though it’s acknowledged that this change that can be addressed in the future.
  3. A request was made that the previous blocking concerns raised in the original proposal ticket should be summarized and addressed in the new ticket, or the new one closed as duplicate unless there is substantive differences in what is being proposed beyond implementation details.

This will likely need to be included early in a release cycle (WordPress 6.6 at the earliest) and will likely need support of a core committer to help shepherd into the project.

Highlighted posts

The full list of posts from the last week in core can be read on the agenda at this link.

Also, from last week’s agenda, this section provides updates on the core-editor and the Developer blog, including the latest topics that need writers.

Open floor

@costdev provided an update on the PluginPlugin A 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 Dependencies feature for 6.5.

We’ve been triaging and resolving some issues since commit, many of them minor and we’ve discussed some of the larger issues and are on the path to resolving those.

After the meeting concluded, the team published the following post:
Merge Announcement: Plugin Dependencies

Props to @webcommsat for reviewing.

#6-5, #dev-chat, #summary

Abha Thakor 2:22 am on February 8, 2024
Tags: , , summary   

Summary, Dev Chat, February 7, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Curated agenda: @webcommsat

Facilitator dev chat: @joemcgill – welcoming one of 2024’s new co-team reps for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.!

Discussions

Proposal: What’s next for the Outreach program

  • Feedback deadline: February 12, 2024. Add comments to the post.
  • A Hallway Hangout is scheduled on February 20, 2024, at 15:00 UTC to further discuss it and next steps.
  • Actionable proposal. Potential for cross-team involvement in furthering it.

Forthcoming Releases

Maintenance releases

@jorbin reports there are currently no updates on a 6.4 release.

Major releasemajor 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.: 6.5

@marybaum made a request for contributors to fulfill roles of Mission Control, Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., Security, and MarComms for the release parties, especially BetaBeta 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 on Tuesday. 

List of new updates on 6.5 including ones requiring input together with their deadlines, next bugbug 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. scrubs, and more.

PluginPlugin A 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 dependencies discussion

You can also view discussions taking place in #core-upgrade-install channel on Slack. This has been highlighted as a potentially very valuable feature for 6.5 and was merged into ‘trunktrunk A 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.’ on Tuesday. Note this is the last dev chat before Beta 1.

The discussion focused on @desrosj‘s first point in the update: “When a plugin’s dependencies are unmet, the plugin is deactivated, and the user is only informed of this if they visit the plugin page, and only if they visit on the same request that the deactivation occurs on. It is my opinion that plugins should not be deactivated if dependencies are suddenly unmet. This could be very unexpected for anyone unfamiliar with the concept of dependencies in the context of software. Instead, the WSOD protection should be allowed to do its job, allowing the site owner to receive an email, and see a path forward to correcting the issue.”

@azaozz asked if it was better for a plugin to throw a fatal error and trigger “fatal errors protection” in WordPress?

@jorbin: highlighted whatever decisions are made they need to be ones that reinforce the trust users have in WordPress and in auto updates.

@desrosj: There are also some scenarios where things may reasonably continue working without the dependency, but that would break or become missing currently. This would especially be true for anything that displays content. The content would just go missing without the site owner knowing.

@azaozz: A plugin that stops working either because it was auto-disabled, or because it is missing a dependency is a bad thing that needs to be fixed.

A discussion on the use of emails to admins followed, Perhaps sending another email to the admins to alert users. View the discussion on Slack.

@jorbin: suggestion to highlight all the ways that a plugin could end up with unmet or mismet dependencies and what the expectation would be in each of them

@christopher allford : For a feature that has sat in discussion for so long I think pushing through with a minimal implementation (sans the consent-less deactivation) is a great first step. That will naturally incite discussions about iteration (such as sending dependency information in update metadata to let WordPress opt-out of updating incompatibilities).

Summary of two main concerns:

  1. How do we ensure we’ve identified and resolved any issues with this feature during beta so we ship something that does not hurt user confidence in upgrades?
  2. How can we better communicate these changes so folks can be prepared?

Wider discussion surrounded:

  • How we determine that a large feature is “ready” to ship?
  • How are can we better communicate when a feature needs further testing after being merged. For example, Is a dev-note enough or should there be some other way to communicate these changes?.

Highlighted posts

The full list of posts from the last week in core can be read on the agenda at this link.

Also, this section provides updates on the core-editor and the Developer blog, including the latest topics that need writers.

Open floor

Anyone can ask for a ticketticket Created for both bug reports and feature development on the bug tracker. or PR to be discussed during an open floor. To help us provide good feedback, please include a link to the issue you want to discuss in the dev-chat agenda notes prior to the meeting.

Props to @joemcgill for reviewing.

#6-5, #dev-chat, #summary

Brian Alexander 11:39 pm on January 31, 2024
Tags: , , , , , , summary   

Dev Chat Summary, January 31, 2024

Start of meeting on Slack

This Dev Chat continues the experiment to focus chat time on discussions related to open CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. proposals and release issues, rather than repeating links already highlighted in the curated agendas.

Please read the Dev Chat Agenda for a curated list of announcements, discussions, highlighted posts, core-editor updates, major and minor release updates, and more.

Announcements

Following announcement of yesterday’s 6.4.3 release, @jorbin noted that there was one issue of note, but that there were workarounds available at this time. @jorbin further gave props to those who helped facilitate the release.

@hellofromtonya shared that @joemcgill has accepted his nomination to serve as a 2024 Core team rep 🎉. The search continues for a co-rep, where it’s been noted that a contributor from the Core Editor team would be a great compliment, though not required. Nominations remain open until April 1, 00:00 UTC.

Discussion on open proposals in Core

Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. Publish Date

Link to post: Proposal: An update to the Field Guide

Conversation start link

Comments:

  • @jorbin was under the impression that neither the dev blogblog (versus network, site) team nor 6.4 release leads were interested in moving forward with the proposal. @webcommsat shared that 6.4 docs release leads didn’t see 6.4 as the deadline, and discussions were continuing. @joemcgill agreed that the proposal wasn’t release specific, but rather an adjustment to timing of when field guide information is released. @hellofromtonya also added that the dev blog team has opened a discussion to track the second part of the proposal.
  • @jeffpaul referred to @chanthaboune‘s comment of where best to separate field guide content based on audiences, suggesting the proposal could be adjusted accordingly. @jeffpaul added that some folks have difficulty processing field guide information to determine what is relevant and actionable, which @hellofromtonya agreed should be explored. @webcommsat agreed with the notion to target field guide content to particular audiences, but also to look at how it relates to other new content produced for the release.
  • @jeffpaul suggested the potential to target content according to the five user groups identified in Care and influence: a theory about the WordPress community.
  • @ironprogrammer asked if the field guide info would be more easily consumable if it was split into a canonical structure, such as wordpress.org/6-5/field-guide/, with subpages that match particular areas or audiences.
  • @webcommsat noted that segmentation between audiences has grown, and suggested it’s a good time to use teams’ audience-specific insights to improve the field guide format. She added that exploring how best to utilize the limited people and time for the Docs team would be an important factor in implementing improvements. @jeffpaul agreed with concerns around challenges in gathering/publishing content, but noted that the issue should be considered as separate from the proposal.
  • @jorbin shared that the original published field guide was the result of an overly long email sent to pluginPlugin A 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 developers.
  • First-time Docs Co-Lead @estelaris 🎉 asked about adding additional comments to the proposal. @jorbin noted that Make/Core comments close automatically after 180 days (~6 months). @costdev shared that adding the #keep-comments-open tagtag A 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.) would reenable them, but recommended removing the tag once an updated timeframe for feedback has been reached. @jorbin updated the Core handbook to reflect this info.
  • @joemcgill pointed out that the team should review all current channels where field guide-related content is published, to check whether only updating the field guide [in one place] would sufficiently improve the broader sharing of release updates to the community. He suggested engaging with the Docs and Marketing teams to move forward, and @estelaris noted she would begin by sharing with Docs. @webcommsat suggested looping in Training as well. @laurlittle noted that the Marketing team could brainstorm on the proposal for future releases, if not 6.5.
  • In response to @joemcgill, @webcommsat noted that there have been past lists of channels and audiences, and suspects more current info should be available. She also suggested it might be helpful to have a single post that links out to the various user groups identified earlier, and to link to that post from the About page.
  • @jorbin referred back to @jeffpaul‘s input and asserted that the dev blog and other team areas might be better places to communicate field guide information, as opposed to Make/Core. @hellofromtonya asked if, considering this perspective, the proposal was actionable by the Core team, or if the proposal should be re-worked as a cross-team collaboration. @jorbin suggested that the teams publishing the field guide info would take on the proposal.
  • @joemcgill noted that it can be difficult to know the status of a proposal, suggesting some way of flagging these posts. @marybaum suggested a visual system to convey “stalled”, “live”, etc, and @joemcgill raised the idea of a blockBlock 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. pattern. @desrosj shared that in past proposals (example) he has added status info to the top of the post, assuming the status was clear.
  • @hellofromtonya wrapped up the discussion based on the chat, concluding that the proposal be marked closed (“not accepted”), or must be picked up by another team(s).

Actions:

  • Part 1: Move Make/Core field guide publication ahead one week, aligning with last scheduled betaBeta 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., rather than RC1. Not accepted ❌
  • Part 2: Start publishing a simplified field guide to the WordPress Developer Blog. Not accepted ❌
  • Other teams to explore revising and adopting this proposal:
    • @estelaris to share the proposal with Docs.
    • @laurlittle to raise the proposal to Marketing for possible brainstorm.
    • @webcommsat to loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. in Training to gauge their interest in furthering the proposal.
    • To highlight in dev blog.

Open Floor

Props @hellofromtonya for peer review.

#6-4, #6-5, #core, #core-editor, #dev-chat, #meeting, #summary