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.
There are a number of possible resolutions to a ticketticketCreated for both bug reports and feature development on the bug tracker.. Moving a ticket towards a resolution might involve:
Pinging a specific person for feedback/information
Reviewing 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 providing feedback on it
Adding a new keyword to a ticket
Almost always, it should include a summary of the discussion.
There is no magic number for Bug Scrubs. It is entirely up to the organizers.
Bug Scrubs work best when they have a specific end goal. This may be a number of tickets or this may be a time period. Generally, 1 hour is a good amount of time and no more than 5 minutes is enough for each ticket.
Announce it by opening the Bug Scrub <bug-scrub>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.) and welcoming people
Then link to the list of tickets you will be going through. This list should either be a pre-existing report on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. or a query that you generate.
Then post the first ticket for discussion. Make sure to mention it via number or a link so that slackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. auto posts a link so someone can see this ticket was discussed.
Then take a moment to review the ticket and discuss what it needs to move forward. You may call for volunteers for specific tasks.
Tip: Sometimes cutting off discussion and moving it back to the ticket with some summary of thoughts makes the most sense. That’s a decision you need to make, though anyone should feel free to suggest it.
Finally, make sure one person is responsible for updating the ticket with whatever decision is made.
Repeat steps 2-4 for the next ticket on the list.
When done, make sure to close </bug-scrub> and thank everyone who helped.
An account on both WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ and wordpress.slack.com ( which you can get through https://make.wordpress.org/chat/ with your WordPress.org account)
A willingness to devote some time to help WordPress
You don’t need to be:
A coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.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. or someone that would be called a “core dev” (whatever that means) to lead a Bug Scrub.
A developer at all. Designers, project managers, QA engineers, and product managers can be great Bug Scrub leaders.
You can schedule 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. scrub by pinging a the Core TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. lead for the current release, by volunteering in during the Core Dev chat open floor time, or by commenting on the Core Dev chat agenda/summary posts with your interest.
Have the report or list of tickets that you want to go through in mind, and someone will make sure your scrub is scheduled in the most appropriate Slack room.
Most scrubs will happen in the #core room, though some components have their own rooms where it makes sense to hold the scrub.
If you are new to leading bug scrubs, you can be paired up with an experience scrubber to help guide you through the process!
If a ticket will not likely be completed in a timely manner for a given release, you will want to “puntpuntContributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.)” it from the milestone. The best approach is to change the milestone to Future Release and not the next major or 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. as this typically ends up with a large amount of open tickets rolling over from release to release. “Punting” them to Future Release allows component maintainers and people particularly passionate about the issue to purposefully, intentionally milestone it for a release.