New User Quick Start Guide

Who should use this guide? Who should use this guide?

If you are a developer who wants to contribute to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for the first time, this guide is designed to help you navigate and use Trac. This is meant as a high level overview to get you started quickly. This page should guide you through some overall knowledge you will need before contributing, the basic steps of working on a ticketticket Created for both bug reports and feature development on the bug tracker. and finally the layout of a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket. We highly encourage you to consult the core handbook and tutorials to learn how to use Trac more thoroughly.

We are going to assume you already have a WordPress.org account, have thoroughly read https://core.trac.wordpress.org/, and already have access to the make.wordpress.org Slack workspace, which is where you can ask for guidance and assistance.

Top ↑

What You Should Know Before Getting Started What You Should Know Before Getting Started

Trac Functionalities Trac Functionalities

Trac is an open sourceOpen Source Open 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., web-based project management and 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. tracking system. It is used by many parts of the WordPress project, including Core, MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and Theme Review. Trac is based on working in tickets. Contributors leverage the tool to find tickets in need of work, monitor progress on open tickets, contribute patches for WordPress core.

Top ↑

How Core ContributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. Communicate With Trac How Core Contributors Communicate With Trac

Trac is the official record of work for WordPress core. The tickets written here become part of the living historical document of open source contributions. Because of this, the tone and language used in tickets and comments should be formal and to the point.

Because this is the official record, be sure to search thoroughly to see if there is an existing ticket for the bug or feature you want to log. If something already exists, please add your notes to that existing ticket. If what you have to add is related to an existing item or for something with a finished milestone, reference that ticket using the format #{ticket_id} to automatically create a link between tickets: “This was previously discussed in #99999.” If you need to refer to a particular changeset (a set of code changes logged in Trac), you can link to it using the format [{changeset_id}]: “The original bug was fixed in [999999].” Note, finished milestone tickets should never be reopened.

Please remember contributors are volunteers and this process takes time. Patience is always appreciated.

Top ↑

Working On Open Trac Tickets Working On Open Trac Tickets

  1. Find a ticket ready for work by using https://make.wordpress.org/core/reports/
  2. Check the attachments and see of there is a current patchpatch A 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. being suggested.
  3. If no patch exists, time to replicate the scenario and add a new patch.
  4. If there is a patch, it likely needs to be reviewed and tested, the comments will reveal the current status of things. Download the patch and test in your development environment. If works as expected, please provide appropriate feedback.
  5. If you make changes to the patch, please provide a link to the Diff (https://make.wordpress.org/themes/handbook/review/working-with-trac/#comparing-ticket-updates) as well as comment.
  6. Always leave a comment on the ticket describing what you changed and why you changed it. A patch upload itself does not trigger a notification. Please use [attachment:{filename}] in a comment to link to that patch.
  7. Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sure to adjust the keywords as necessary: https://make.wordpress.org/core/handbook/contribute/trac/keywords/

If a ticket does not already exist for an issue, please open a new ticket: https://make.wordpress.org/core/handbook/tutorials/trac/opening-a-ticket/

Top ↑

Ticket Overview Ticket Overview

Trac Ticket Overview

Trac Ticket Overview

  1. Ticket ID Number – When commenting please use the format #{ticket_id} to automatically create a link between tickets.
  2. Type –
    1. Defect (bug): There’s something wrong and it needs to be fixed.
    2. Enhancements: An existing feature could use this improvement, like an additional hook or other modification.
    3. Feature requests: This is a new item not currently represented in WordPress core or another Trac ticket.
    4. Tasks (blessed): This option won’t appear when filing a new ticket. This status is only given to a ticket if a feature team has accepted it for development (hence, “blessed”).
  3. Milestone – This is set to “Awaiting Review” by default. Once accepted for development, this will be set to the specific version number slated for releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.. Only trusted core contributors can set a milestone.
  4. Severityseverity The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. – normal, major, minor, trivial, critical, or blockerblocker A bug which is so severe that it blocks a release.., Only trusted core contributors have the ability to modify the severity.
  5. Component – Which specific part of the project are we working on? For a more detailed definition of each component, please read: https://make.wordpress.org/core/components/
  6. Focuses – Optional when creating a ticket. This indicates if a ticket is relevant to an area that encompasses multiple WordPress components. Options are: ui, 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), javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/., docs, rtl, adminadmin (and super admin), template, multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, rest-api, performance, coding-standards
  7. Priority – How quickly this issue should be addressed. Options are: normal, low, high, lowest or highest omg bbq. Unless you have discussed a different status with a trusted core contributor, ‘normal’ should be used.
  8. Version (for bugs) – The earliest known version of WordPress affected by this bug. You should not change this.
  9. Keywords – These are like tags, used to track the current status of the ticket and required next steps. This will change as work progresses. For more definition of the available choices, refer to: https://make.wordpress.org/core/handbook/contribute/trac/keywords/
  10. Description – The heart of the ticket. Please be as thorough and specific as possible. If this is a bug, include steps to reproduce the issue and what you expected to happen.
  11. Attachments – Add additional info, like screenshots, new patches or diff files for patches.
  12. Change History – This is where the conversation happens! This is open by default and you should read it all the way through before you begin work to see what has been tried and what others are actively doing.

Top ↑

Resources Resources

Printable high resolution of the above infographic are available in JPG and PDF formats.

Last updated: