On Thursday, June 15th, WordCamp 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. Europe 2017 in Paris had the very first Contributor 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/. where WP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ was officially represented as a separate team that people could contribute to.
On the official WordCampe Europe 2017 website, you can find the organization information that was sent to the attendees.
To get a sense of the event, you can visit the Contributor Day album by Olivier Gobet on Flicker.
Team Attendance
Over the course of the day, there were a dozen contributors joining the team to work on WP-CLI. Considering that the command line is not a mainstream topic in the WordPress world and that the team has only recently been officially added, we can consider this a success in itself.
After a small introductory round, it was clear that all of the contributors had prior experience with WP-CLI, either making regular use of it or even having already done development against it. This meant that we could skip the basic introduction and immediately dive into a more technical analysis of how the tool and its packages are architected.
We then split the team into two groups, depending on what the individual contributors preferred to work on: one group focussing on commands, and the other group focussing on the framework itself. The main difference between these two is the skill set needed: for the commands, the development closely mimics regular WordPress development, whereas for the framework, WordPress has not been loaded yet and the development is closer to pure PHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. console development.
Things That Worked Well
Once we’ve split up the teams, we went through the Good First Issues page, and everyone was quickly able to find something to work on. This was a definite success, as I’ve often attended Contributor Days where some people were lost during the entire day, not really knowing where to focus their efforts on.
The fact that the code is managed through git and GitHub 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/ was well received by the contributors, as it made issue discovery easier and allowed for faster feedback cycles.
What made everything run smoothly as well was the fact that the contributors to join this team were mostly of above average technical proficiency. This meant that technical issues that were encountered were quickly taken care of, with people helping each other out, and there has even been an impromptu introductory session to test-driven development (TDD) by one of the contributors as well.
Things That Need To Be Improved
We are still facing some issues with the contributor onboarding process, mostly around documentation and testing.
One problem we faced was the fact that it is not obvious for most contributors that they need to create a test database first before being able to run the functional tests. Documentation could be clearer on this step, and we might even provide a hint in the console when the tests are being run without access to a database.
Another source of confusion was that there are different conventions (workflows, file names, …) of how to proceed depending on whether you want to work on a command, or the framework itself. This should all be streamlined so that every single wp-cli
package will have the exact same requirements and support the same workflows.
Au Revoir
Big thanks to the organizing team of WordCamp Europe in Paris for the additional efforts they went through in order to find a space for our brand-new team! Although we hadn’t been included in the original planning (when they didn’t yet know about the WP-CLI team), we had a flawless experience and felt welcome as an integral part of the WordPress project.