New Contributors Meeting Recap – February 14th

On Wednesday, February 14th, the weekly new contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @abdullahramzan @aduth @chetan200891 @clorith @desrosj @dougvanslembrouck @jorbin @joyously @lakenh @notnownikki @thrijith @welcher @williampatton @xkon

Discussion Highlights

Contributing with Git

Even though every change to WordPress core must pass through Trac/SVN eventually, SVN is not the only option for creating patches.

See these articles for more intofmation on creating patches with Git:

Coding standards

An easy way to make your IDE/editor aware of the WordPress coding standards regarding whitespace usage is to use the .editorconfig file that trunk contains. This file uses a common standard, and there are plugins available for almost all popular environments that automatically parse the file and adjust the whitespace settings for the project.

Extensions can be found on the website of the project. Some IDEs like PHPStorm already come with built-in tools for the WordPress coding standards.

Refreshing a patch

Older tickets often have attached patches that no longer apply to the current codebase. The older the ticket, the lower the likelihood that the associated patch will apply cleanly. If you find a ticket with a patch that does not apply, add the needs-refresh keyword to indicate this.

Over time, code shifts around and sometimes these patches only need a bit of reorganization to apply. Other times, you may find code that has been refactored and needs an alternative solution for the proposed bug/enhancement. Once this has been done, create a new patch with the clean code and submit it to the ticket.

While refreshing a patch, it’s also a good idea to make sure the patch is what you would consider the best approach and to verify that it follows the style guide.

See Contribute with Code handbook article for more information.

Ticket ownership

Ticket owner is generally responsible for moving the ticket forward. From the handbook:

When working on a ticket, the Owner field is typically left blank, even if you have contributed a patch. Committers utilize the field to offer traction for a ticket, to identify they are investigating, committing, or otherwise following a ticket, or to tentatively accept the bug or enhancement for core inclusion. It is also common during the feature development phase for developers to accept tasks in the area of responsibility for which they have volunteered, as well as related bug reports. Trusted contributors may assign tickets to others based on an inside knowledge of who should be responsible for reviewing it.

For good-first-bugs, the person who submitted the patch is assigned as an owner so that the ticket shows as “claimed” in the queue.

It’s OK to drop ownership if the ticket is no longer relevant for you, just reassign it to an empty field.

See The Bug Tracker (Trac) handbook article for more information.

Tickets brought up

  • @notnownikki has been working with @iseulde and @azaozz on #43187, which comes from an issue in Gutenberg.
  • @williampatton asked for feedback on #42057, specifically opinions on introducing an additional parameter for a function in a minor release, and more eyes on back compat to make sure nothing is broken by the change.

Thanks to everyone who attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @flixos90, @sergeybiryukov, @stevenkword, @welcher) with questions on Slack. Or, feel free to reach out to any core developer or component maintainer with questions specific to certain core areas.

#core, #new-contributors, #summary