Getting Started at a Contributor Day

This guide is intended to help you get started at a 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/.. It includes a schematic outline of what the group does and how to quickly get started. If you need any help, talk to the contributor day organizer, or ask your question in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. channel in Slack.

This is a work in progress so don’t be afraid to amend the document or leave comments, particularly if you’re at a contributor day and find that we’ve missed something.

Regular Meeting Time: Wednesdays at 21:00 UTC
New Contributor Meetings: 2nd and 4th Wednesdays at 19:00 UTC
Where: #core channel on Slack

The responsibilities of the core group are:

• To maintain the code and develop it for the future
• Develop new features for WordPress
• Maintain and improve design and UXUX User experience
• Design, develop, and maintain default themes
• Maintain the utilities used to develop core
• Maintain the bundled packages of default plugins
• Maintain the bundled libraries available in core
• Maintaining 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. tracker

As a member of the core group, some common tasks that you’ll carry out are:

• Testing patches and fixing bugs
• Handling stability and security issues
• Code new features
• Work on the user interface
• User testing for new features
• Writing unit tests to keep WordPress stable
• Bug gardening
• Review patches for Coding Standards
• Review patches for 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) and privacy concerns

Prior knowledge that you’ll find helpful for working on core is:

• Grasp of whatever coding language you want to help out with, e.g. CSSCSS Cascading Style Sheets., PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, 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/. or ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.
• Familiarity with WordPress is beneficial but you don’t need a deep understanding of core to get started

• A version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. system: either SVN or Git
• a local development environment
• for unit testing, PHPUnit
• Grunt for compiling assets, building release packages, and JavaScript and PHP testing
• QUnit for Javascript testing
• WPCS rules for PHP_CodeSniffer

• Sections of the Core Contributor Handbook relevant to what you’re working on
• If you’re writing code, the WordPress Coding Standards

The first step is to get set up with a local environment:

1. Install SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.: Installing a VCS
2. Install a local server: Mac | Windows | Windows (alternative)
3. Check out the WordPress codebase using SVN

After that:

• If you find an issue with WordPress you can Open a ticket on Trac
• Fix a bug
• Create and apply a patch

There are other ways that you can help out:

• Bug gardening
• If a 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. or 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). is available try out some Alpha or Beta testing
• Writing unit tests
• If you want to help out with a UIUI User interface-centric feature, check out the features as plugins information
• If you want to focus on a specific Component, check out the WordPress Core Components listing.

Some easy tasks for a first time contributor to get started at a contributor day are:

• Check the good first bug tag for easy wins
• Update the Inline Docs
• Work on the user interface, check out the UI focus
• Provide Developer feedback
• Provide Design feedback
• Provide Copy feedback
• Provide Privacy feedback
• Refresh an existing patch that doesn’t apply or needs an update.
• Try your hand at bug gardening (Helen has a good post to help you get started)

• A local dev environment running WordPress (we suggest VVV)
• Latest npm version. 

If you are unsure if you are on the latest npm version, run the following command:

 npm install npm@latest -g 

•  Docker – https://docs.docker.com/install/

A handy guide to setting up your local environment can be found in Contributing.md in the 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/ 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/ repository. There you will find commands to help get your local environment up and running.

Largely, the setup process can be finished end to end by running the following command from the Gutenberg directory (Powershell works well if you are on Windows.):

./bin/setup-local-env.sh

The script will go step by step through the process of validating prerequisites are met. If there is something missing, the script will report what needs to be done to complete the setup. Re running the script a few times after making the suggested changes will complete setup.

Once you have the development version of Gutenberg running on your local environment you will need to run the following from within the Gutenberg directory:

npm run dev

This will monitor/update changes you make.

In order to avoid huge downloads at WordCampWordCamp WordCamps 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. Contributor Days it is recommended that the environment is configured before the event.

If you are looking for some unassigned first issues to get familiar with contribution to Gutenberg, look here.

1. Fork the Gutenberg repository to your own account.
2. Clone your fork locally to your ‘plugins’ directory using `git clone`
3. Create a new branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". in your fork with the the issue number somewhere in the branch name (example: `fix-adminadmin (and super admin)-align-center-12306` would be a good branch name for issue: “Latest Posts 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. “align center” has no effect in admin #12306”)
4. Make an initial commit 
5. Publish your branch using: 

git push -u origin <branch name>

Now you are ready to make your changes locally to fix the issue. When finished, commit your changes and push them to your branch.

If you are ready to submit your changes for review to merge into Gutenberg, simply create a pull request via github.com by navigating to your branch. Create pull request and fill out the information requested in the form.

Last updated: September 17, 2024