On Wednesday, February 14th, the weekly new contributor meeting was held in the #core Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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 Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/.
Even though every change to WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. must pass through Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./SVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. 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 Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality./editor aware of the WordPress coding standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. regarding whitespace usage is to use the .editorconfig file that trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. 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 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.
Older tickets often have attached patches that no longer apply to the current codebase. The older the ticket Created for both bug reports and feature development on the bug tracker., 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 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./enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. 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 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/.
- @williampatton asked for feedback on #42057, specifically opinions on introducing an additional parameter for a function in a minor release A 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., and more eyes on back compat Backward compatibility - a desire to ensure that plugins and themes do not break under new releases - is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backward incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries, such as jQuery, do have backward incompatible changes between major releases, which is often going to be a greater concern for developers. 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
