In this post I’ll write a bit about how the 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/. went this year, what we did and things we learned, as well as a recap of some interesting meetings with key people from various teams in the WordPress community.
Contributor day
The contributor day started with team leads explaining what they will work on. Early on we set on to review one theme using 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/. as a common communication channel, since we were divided between three tables, so it was a bit complicated to keep everyone up to date.
Here I cannot overstate the help from Carolina (@poena) and Ana (@acalfieri) that were answering and helping the new contributors. First part of the day was spent helping new contributors out and answering the questions. The second part of the day we let them start reviewing the themes from the trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/., so that they can get into the review process.
The summary of the themes reviewed are:
12 themes reviewed
10 themes are still in review phase
2 themes were approved for final review
We got some constructive feedback on the review process:
- It was not fully clear how to start reviewing
- Every reviewer has his/her own style of reviewing – more consistency is needed
- A checklist of sorts should be added to trac so that the review is more streamlined
- Requirements are not clear enough
- There were some inconsistencies in the requirements from the theme members
- The review process should be clear and outlined in clear steps
- Welcome block 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. confused a lot of people so they didn’t read the requirements for a long period of time or they just closed the page
- Upsell examples should be added so that authors know what is allowed
- Trac is difficult to use especially for the first time reviewers
- A tool to check if a text is not translation ready would be helpful
The feedback is great, and we (the theme review team) encourage you to leave a comment if you think some things can be improved as well. We will look at these and others suggestion and make changes accordingly. Some can be implemented easily, some will require some thinking about before implementing, but they give a good point on what to do in the future.
Aside from the theme review, we got one PR for the Theme Sniffer Theme Sniffer is a plugin utilizing custom sniffs for PHP_CodeSniffer that statically analyzes your theme and ensures that it adheres to WordPress coding conventions, as well as checking your code against PHP version compatibility.
The plugin is available from GitHub.
Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory. plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party which was merged (https://github.com/WPTRT/theme-sniffer/pull/168). It was a PR regarding fixing the development process for people with Windows machines. This is a valuable fix because it allows other people on other platforms than Unix based ones to work on the plugin as well.
All in all, as usual, the experience was a positive one, and the feedback is great. We hope that the reviewers from the contributor day will join in and review some more themes and we will work on making the theme review process a better and faster one.
Meeting with the meta 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 plugins team
During the contributor day representatives of theme review, meta, community and plugin team met to discuss briefly what are the pain points that we currently have in our repository. The plugins team representative mentioned that they would like to have a check similar to what we have on the themes team (theme check, sniffer and coding standards), to automate some tasks for easier review process. It was also mentioned that the Theme Sniffer could be used during the upload process, but we still need to fix some of the open issues we have and close some of the opened PR before we start experimenting with that. Community team representative offered to help if we need to reword some of the error messages we find, to make them more understandable to authors and the reviewers.
The meta team representatives suggested that we should define what the purpose is and how the coding standards can help both plugin and theme reviews so that they see how can they help.
Meeting with Matt Mullenweg and Matías Ventura
The representatives of the themes review team also met with Matt and Matías during the scheduled office hours. We asked about what was going to be the future of themes and the theme review.
Matt expressed that our theme knowledge and expertise is very valuable since we are probably the people who sees the largest number of themes.
As previous years, Matt says that he would like the theme review to be more like the plugin review, and one suggestion was to separate the actual code/and security requirements, and that this code can be reviewed similarly because it is just 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. http://php.net/manual/en/intro-whatis.php. code.
We touched the subject of block templates, and Matías would like to discuss ideas with the team. The suggested approach is that block templates will be more like groups of blocks that the user can select instead of just trying to add one block at the time. So it will be less like a classic page or post template and more like nested blocks.
When it was brought up that very few themes add styles for blocks (also including custom styles), Matt asked why block styles is not required.
We discussed that it is difficult for the review team to find volunteer team reps/leads, but no advice or conclusions came out of it.
We expressed that it is difficult for us who are present at the 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. to make decisions for the team since the leads were not able to be there.
We also touched on the subject of the themes added to the directory. Matt would like us to focus more on design and on unique themes. He wants to see more different, innovative themes.
We briefly discussed how it would be possible for us, who review code and not design, to review design, but no real tips or conclusions came out of it.
We got the impression that his vision for the theme repository is to be more like an art gallery, showing original and beautiful themes, and not so many repetitive, business-like themes. He repeated this idea in his talk in the main conference room when asked about the future of themes in a 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/ world.
We briefly discussed the issue of the featured tab, and we agreed that something should be done with it (the removal of this tab was also discussed).
Matt brought up that the demo looks a lot better than it used to, but we agreed that it should be updated to also showcase blocks.
In the end we touched on the subject of GPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples.. Matt mentioned that it’s important to check that themes are GPL compatible, and that authors should not limit the number of installed themes. We did not go into details on how this should be checked, but GPL and the four freedoms that WordPress stands on is something that is important and should be followed.
We brought up the missing icons license and source information in Twenty Nineteen and that it causes problems when theme authors uses Twenty Nineteen as an example. Matt was not aware that this was still not resolved.
Regarding advertising in themes he understood the problematic of it, but he gave no indication that he wished that the TRT should prevent all upsell, but that themes shouldn’t require plugins.
Meeting with coding standards, tide, plugins and theme review team
The last meeting we had was regarding how we can automate more checks, help the reviewers and also help the theme authors better their themes based on the automated checks provided by the Tide project.
After discussing what can be done it was agreed that the following actions will need to happen
- Theme Review sniffs A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. on 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/ will be moved from WPTRT to the official WordPress Github repository, and will also include the plugins and tide sniffs as a part of a bigger quality assurance (QA) sniffs repository.
- Theme demo needs to be improved – for a start, we should make a demo with a decent looking static page, a blog page, and regular demo pages that will be shown on the theme preview page. This can also help theme authors create a screenshot image that is easily reproducible with the demo.
- A theme main page (like a single plugin page) needs to look more like plugins – for this a valid readme is needed.
We also discussed the possibility for theme authors to receive a combined QA report that would consist of sniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. results and a lighthouse result that is based on the demo file. This would give the authors some hints at what they can improve. This could be sent to authors via email.
After the three major actions are done, the next thing that should happen is to add more demo files for specific use cases – one with WooCommerce shop, one as a blog etc. These could then be selected in a preview from a dropdown (it the theme supports it).
There was also a proposal to add a recommended plugins field for the readme, that would be shown on the theme page, and based on this field, a demo dropdown would be shown – e.g. if a theme supports WooCommerce, a shop demo would be shown in the dropdown, but if a theme doesn’t support it, it wouldn’t be shown.
It was generally agreed that we need to reduce the complexity of entry for new reviewers to do a review, and that we need to make the issues we have with the theme directory, small in scope so that meta team can fix them more easily and quickly.
If you have any comments and further suggestion feel free to leave a comment below.
#contributor-day, #recap, #wceu
