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 Field GuideField guideThe 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. is published on Make/Core and highlights the developer-focuses changes in 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.. Ideally all new and modified hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. are noted in a bulleted list (e.g., 4.8).
Start drafting the Field Guide early in the release cycle (generally around BetaBetaA 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) and slowly embed dev notes as they get published. A week or so before Release Candidaterelease 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). 1 you will want to reserve 2-4 hours to work on copy, formatting, link updating and other tweaks to have the first real draft of the Field Guide ready. Around this time you will want to send the SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. group direct messages to Component Maintainers to give them all a couple days to provide feedback on the bullet points in the But Wait, There Is More section. At the same time you will want to obtain reviews from others on the release squad so that all feedback completes around the same time and allows publishing the Field Guide as close to RC1 as possible.
The following is a general process that the Release Coordinator and/or Documentation Lead will use to craft the Field Guide for a release:
Copy previous release Field Guide (e.g. 5.6), rename and update copy to current release version number
Update all links to point to current release version number
Remove previously embedded dev notesdev noteEach 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.
As new dev notes for the current release cycle get published, embed them in the respective section of the Field Guide
Update the Field Guide heading with the major focuses from the release
Update section listings to relate to areas receiving dev notes
Add/update section summary pulling major highlights from embedded dev notes to help developers know whether those dev notes are relevant to them or not
It’s that time again Component Name component maintainer(s)… are there any tickets in the X.Y release that you’d like called out in the Field Guide that aren’t already included in a Dev Notedev noteEach 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.? As a reference, here are the ## tickets currently in the milestone for you: https://core.trac.wordpress.org/query?component=ComponentName&milestone=X.Y&col=id&col=summary&col=milestone&col=owner&col=type&col=status&col=priority&order=priority. Note that we intend to publish the Field Guide next week, so the sooner you can respond the better… thanks!
The responses are added into the But Wait, There is More! section of the Field Guide as individual bullet items in the format of:
Component Name: TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.TicketticketCreated for both bug reports and feature development on the bug tracker. Summary (#Trac-Number).
Find at least one reviewer from the release squad, but ideally one technical review and one marketing/copy review, to ensure the Field Guide is as well-written as possible within your timeframe. From there it’s published with the version number “X-Y” and “field-guide” tags.