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.
WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe is today!
The CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team is putting together a squad for future minor releases. A release squad for 6.8.2 should be announced soon. Follow #6-8-release-leads for updates.
As a follow-up to this post, he asked the following to be discussed:
After a couple of weeks, I’m almost done on reviewing the Workflow Keywords sequence. I only need some extra info in the committing part as is the part I’m less knowledgeable, so I would need some committers to help me out on the review
[I] need committers to help with the revision of the Workflow Keywords (specially the committercommitterA 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. and 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. part where I have more doubts). First I’m willing to publish an article explaining the new ideas with the first revision of the revised diagram and it could serve as an attention call for anyone willing to make an opinion or add anything else before the final proposal.
Some discussion happened in the Core Slack channel about this post/proposal.
To sum-up, some committers pointed out that:
@jorbin: This post seems to make the assumption that just because there is a patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. and the patch has no flaws, that it should be committed, but if something should be committed isn’t just a question of if there is a patch ready, it’s also things such as: Does this fit within the current priorities? Is this going to cause issues with future backwards compatibility? Are there alternative solutions that haven’t been considered that should be? How risky is this to commit? What other teams would be affected by this change? Have they been given a chance to chime in?
@desrosj: The crux of the post seems to suggest we can’t create a report for tickets that need a code review with the current keywords. Wouldn’t a report that shows tickets with has-testing and has-patch but does not have commit accomplish the same thing?
@sirlouen pointed out that the post is not completely assuming that every patch perfectly reviewed must be committed, but every patch perfectly reviewed should be considered by committers with more priority than patches from scratch.
The discussion then switched to patches that are reviewed and tested, and waiting for a committer review and commit:
@jorbin: Bringing those tickets up during 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. scrubs can be a great way to get attention on them, [but] just because it fits [someone’s] definition of 100% baked doesn’t mean that a committer is going to agree.
@audrasjb: The best way to help these tickets is to ask to move them into the current milestone.
@jorbin: There are about 75 bug gardeners who can modify milestones in addition to all of the committers. In addition, there is nothing that would prevent at the end of the bug scrub a post along the lines of: “After this scrub, we think that the following tickets should be included in 6.8.2 and the following ones in 6.9”. Once someone has demonstrated enough good judgement, they will likely be given bug gardener status so that they can do it themselves.
@justlevine wanted to bring attention to ticketticketCreated for both bug reports and feature development on the bug tracker.#61175: “Beyond the usual i could use a bit of help from people better skilled at WP CI/CD (PHPStan passes locally, but isn’t discovering certain symbols when run on CI)”. See the related GitHub PR.
