Francesca Marano 8:09 pm on November 15, 2019
Tags: 5.3 ( 80 ), retrospective ( 9 )

5.3 Retrospective – Call for feedback

5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

What should WordPress start doing as a part of the development process?
What should WordPress stop doing as a part of the development process?
What should WordPress continue doing as a part of the development process?

Please share your thoughts in the comments below! Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

Edited to Add: if you rather not give your feedback in a public space, please reach out to the following people on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. They are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form:

#5-3, #retrospective

pingram 9:14 pm on November 15, 2019

Consent has been the #1 topic for me this year and my concerns keep growing. I am a huge fan of asking for opt-in and not forcing users to opt-out of something they never agreed to or expected based on previous expectations such as the WordPress philosophy and the four freedoms.

Example in case, the media upload auto downsizing feature already bit me w/ a few LMS sites that updated and needed certificates updated last minute (300dpi images used w/ GD Library output to pdf) where students were not receiving properly formatted certificates upon completion of courses and were severely distorted because no one knew that WP.org had decided to push a new feature that has all the intentions of not allowing end users to upload huge images impacting the performance and user experience of their sites…all the while affecting these already in production web site’s actual user experiences in a totally destructive way.

Yes, we learned we can disable this new “non-web-savvy protection feature” with a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. but this is not aimed at your average users expertise level.

So you created a new feature to help the non-web-savvy folks from hurting themselves but if they want to opt out, they better be web-savvy, all the while hurting existing users that need this to work the original way it has for years or at least an easy way to turn on/off. This logic is lost on me.

That said, I prefer providing feedback face to face because text leaves so much to assumption, I hope this comes across as constructive criticism of recent changes and discussion where new features affect existing already working features without any up front consent or at least a notice prior to upgrade that spells out exactly what to expect from the changes, how to enable them if desired, not the other way around. I want to tick a box after I upgrade to enable new stuff vs having it forced enabled and the only way to override is digging through the developer docs.

Personally I prefer a modular upgrade system where post upgrade, everything considered as a new or enhanced “feature” and not a 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. or security patchpatch 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. should be an option that we enable only when/if it’s desired. I believe this would lead to less post-upgrade issues and also lead to site owners knowing their sites more intimately being forced to get involved with their adminadmin (and super admin) settings to enable and use new features.
- Andrew Ozz 3:34 pm on November 18, 2019
  
  Example in case, the media upload auto downsizing feature already bit me w/ a few LMS sites…
  
  Sorry to hear this but I thought you were aware of the new feature, how it works and how to disable it few weeks ago?
  
  For this particular case “(300dpi images used w/ GD Library output to pdf)” it seems the pluginPlugin 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 handling the “output to pdf” part would need to be updated to use the function wp_get_original_image_path() mentioned in the “developer notes” post, here: https://make.wordpress.org/core/2019/10/11/updates-to-image-processing-in-wordpress-5-3/.
  - pingram 7:40 pm on November 18, 2019
    
    Yes we discussed this prior to the 5.3 release and I even placed the new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. on a few of the sites I manage and I also recently responded (late) to your question about what scenarios might apply which also include this incident as an example ( same link you provided above).
    
    This particular client came to me after they performed the update themselves not realizing the issue was related to the new feature. In fact, it also took me a moment to realize what was going on and that is when I found myself searching for the filter I had used before and I wound up back at that very thread in which I saw your question and added a response.
    
    And in this case, instead of using the filter to disable the feature entirely I did exactly as you suggested and wrote a patchpatch 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. to retrieve the original image since they manage their own site and are a good case example for this new feature.
  - Pierre LeBaux 11:51 am on November 20, 2019
    
    Sorry to hear this but I thought you were aware of the new feature, how it works and how to disable it few weeks ago?
    
    Lot of us frequenting make.wordpress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ were aware. But how about the millions of users with websites with auto-update on? A fairly critical aspect of media upload was changed.
    
    From my experience users do not pay attention to the release page overview in their dashboards after the update. Even if they did, making it opt-in for existing users is just good practice.
    
    When we are making changes this big in our pluginPlugin 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, we keep old users on old settings, offer opt-in. If we think the change is required going forward, new WP sites are opt-out. I do not see any reason why it could have not been handled this way with WP 5.3.
    
    Others in this topic looked at other aspects of this problem and provided sound examples of why it is, in fact, a problem.
    - Oscar Gonzalez 4:46 pm on November 20, 2019
      
      I had no idea this was a thing until right now. I can’t wait to explain this to some of my client artists that upload high-res large images daily.
- Francesca Marano 8:34 pm on November 22, 2019
  
  Thank you for your comment. If you were to recap it in a “What should WordPress start/stop/continue doing as a part of the development process?” format what would you say?
  Thank you!
pingram 9:18 pm on November 15, 2019

Oh and thanks for asking for this feedback, I am glad you are open to hearing our concerns along with our praises. I should also add, the new Twenty Twenty theme is a masterpiece, great job and thank you!
runningonempty8734 11:44 pm on November 15, 2019

The “handling of BIG images” is a horrifying implementation that goes against everything the internet is about and all current consent and privacy laws. I’ve spent four hours trying to figure out what was wrong with my newly uploaded images. I have three high-res sites with the widest images being 3600px. One landing page has a fullscreen image that is 3600 x 2025px at 135kb. I know how to optimize my images and I do them individually by hand. I don’t need to be locked down.

This size limitation is implemented without my consent and without me even knowing about it. I highly doubt it’s legal. And to make matters worse you offer no way to easily disable it.

We are moving toward higher and higher resolution, not the other way around. Do you realize that you are destroying websites and ruining people’s businesses with this? Image handling in WordPress has always been mediocre but with this new addition it becomes a disaster. There are already plugins that handle images superbly. Why don’t you spend your time and effort on enhancing support for high-res images and support what is already in place by third-party developers instead of going against the flow and evolution? High-res is here to stay, don’t go back to 1998.

I think you should pull this update before the damage worldwide is getting out of control and issue an apology to all your users.

Yes, I’m angry and I have the right to be!
- Andrew Ozz 3:39 pm on November 18, 2019
  
  Could you provide a link to your website? It would be good to see how you use these 3600px x 2025px images (and what the srcset and sizes attributes are for them, etc.) so this use case can be taken into account when developing new features.
- Niall Patrick Flynn 3:41 pm on December 17, 2019
  
  I second all of this, the functions and plugins do disable this aren’t working.
  - Niall Patrick Flynn 3:42 pm on December 17, 2019
    
    to disable pardon
Darko G. 11:37 am on November 16, 2019

There should be option in the Settings > Media to enable/disable the image resizing feature and by default it should be disabled. It’s really annoying that i had to disable it on few sites already through the filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. so far and likely many more are coming.
- crowedge 2:30 pm on November 16, 2019
  
  +1 Please add this functionality to the Settings > Media section.
  - Jonathan Desrosiers 1:26 pm on November 17, 2019
    
    For easy disabling, you can use this pluginPlugin 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: https://wordpress.org/plugins/disable-big-image-threshold/
Ihor Vorotnov 12:39 pm on November 16, 2019
Is there a way to disable this new high contrast theme and revert back to the original one? I do support 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) adminadmin (and super admin) theme with higher contrast etc but:
- why it’s turned on by default?
- why it can’t be turned off?
I’m fine with less contrast, I don’t like this new one. Do I have any choice?
- Jb Audras 9:10 pm on November 20, 2019
  
  Hi, thank you for your message!
  
  No, you don’t have choice to opt-out from the default Adminadmin (and super admin) interface. But I know there is some plugins to get a different interface (and there is even a pluginPlugin 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 to restore the previous version. Not sure about how it will be maintained in long term, but using a plugin is always an existing option for you if you are not interested to use the default admin styles, which are more close to be conform to WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/./WAI/W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. guidelines 🙂
Daniele Scasciafratte 3:43 pm on November 16, 2019
Start
- How new features are accepted to be implemented? Right now is not clear, if it is enough to have a patchpatch 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. that includes everything (docs+tests). This will simplify the contribution and be more transparent about decisions.
- Not release a major version if there are bugs confirmed with a patch available, as example https://core.trac.wordpress.org/ticket/48324
- Address more seriously all the tickets that involves errors printed in the page like: `Undefined property:…` as example https://core.trac.wordpress.org/ticket/30991 or https://core.trac.wordpress.org/ticket/44979 . PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher warnings are very bad for all the business around WordPress because we cannot asks to the user for a manual patch.
Stop
- Ignoring new patches by contributors for years. Right now is easy to get demotivated on contributing with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to WordPress because is difficult to get feedback on code patches, and without code patches the project will not move on and grow.
- Stop to release a project by time period instead of feature ready. If I have a company that has a business around a project I cannot upgrade to something that has issues. For 5.3 we got 5 RC that are a clear symptom of something that wasn’t tested enough or feature ready.
I hope that WordPress get more attention in getting more 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. fixed instead of new features that maybe will implement more bugs. There are tons of tickets very old but still real like https://core.trac.wordpress.org/ticket/21402 that talks about remove php 4 code compatibility.
Please give more love to what there is on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. instead of new stuff.
Anton Vanyukov 4:17 am on November 18, 2019

Would be great if features that change coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality, and possibly affect plugins/themes, are announced in advance or additional time is given to pluginPlugin 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/theme authors to adjust to changes. The big image handling did not give enough time for image optimization plugins to thoroughly test the changes. It took almost a month to RC the 5.3 release, it would only be fair to give the same amount of time for plugin/theme developers to implement and test out changes with plugins and themes.
- Ipstenu (Mika Epstein) 5:09 pm on November 18, 2019
  
  FWIW PluginPlugin 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 Developers were emailed about that change (and the others) on October 18th, which was as soon as the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. went out. We don’t email before then because it results in incomplete information. If you ant us to contact you sooner, then we need the field guide as a requirement for RC1.
  - Anton Vanyukov 9:48 pm on November 18, 2019
    
    Yep, I’m aware. Thanks. That does give a good “heads up” on upcoming features, but it’s still a bit too early for pluginPlugin 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 developers to start testing out updates. It is, however, a good time to start planning a plugin/theme release, but that usually adds at least 3-4 week on top, considering there are no changes to a feature during RC phase.
    - Ipstenu (Mika Epstein) 8:06 pm on November 20, 2019
      
      There shouldn’t be any feature changes as of RC. (I know)
      
      but it’s still a bit too early for pluginPlugin 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 developers to start testing out updates.
      
      You mean that the 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 too soon?
      - Anton Vanyukov 9:49 pm on November 20, 2019
        
        You mean that the 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 too soon?
        
        It’s hard to explain )) What I mean is that there was not enough time to adjust for pluginPlugin 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 developers. I’ve addressed several issues with the big image feature. And they were not fixed with the release. Basically, the 5.3 release introduced a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. and a serious one, in my opinion.
        
        It’s similar with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher support. Why does WordPress still support PHP 5.6? Because there’s a large number of sites that are still on 5.6 and you don’t want to break them. A similar approach should be with functionality. If you know that millions of sites use image optimization plugins, you have to respect that as well – don’t rush in a feature. Listen to developers, to their feedback. I 100% agree with the comment from John Blackbourn below (second point in the Stop paragraph)
        
        Ipstenu (Mika Epstein) 10:43 pm on November 20, 2019
        
        What I mean is that there was not enough time to adjust for pluginPlugin 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 developers.
        
        Did you then mean to say “but it’s still a bit too LATE for plugin developers to start testing out updates.”?
        
        I’m trying to figure out how the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. (or RC? I’m not sure which you mean) being out EARLY is harmful? It doesn’t get released until things are baked, which usually ends with us emailing y’all later than we want to.
        
        The big image changes were in RC1, which was 3+ weeks. I can understand needing more time for larger changes, certainly 🙂 I’m confused when you say it was �?too early’ to test with RC1. Which I think is what you said? (There are too many �?it’s’ in context, which is why English is a stupid language.)
        
        Anton Vanyukov 12:07 am on November 21, 2019
        
        Sorry… I’ll try to rephrase.
        
        The latest adjustment to the big image functionality was added on November 9th (according to GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/), considering that it was a Saturday and WordPress 5.3 was released on Tuesday, that would leave only 2 working days to run all QA tests for plugins.
        
        And considering that this is a big change to how images are handled, plus taking into account that there is a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. with ImageMagick – 2 days is not enough time to test out all the changes for pluginPlugin 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 authors. It leads to rushed plugin releases, to incompatibility issues and errors in general.
Andrew Ozz 3:21 pm on November 18, 2019

Would be great if features that change coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality, and possibly affect plugins/themes, are announced in advance or additional time is given to pluginPlugin 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/theme authors to adjust to changes.

Yes, this is the purpose of all the “dev. notes” being published few weeks before the release. See https://make.wordpress.org/core/tag/dev-notes/.
- Ipstenu (Mika Epstein) 5:12 pm on November 18, 2019
  
  Not all dev-notes make it in to the final build, though, which is (I thought) the purpose of the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.. To clearly annotate what is in the new release. We don’t email the PluginPlugin 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 Devs until that guide is out, and I’ve been pushing for it to be a requirement of RC1 for ages �? In a perfect world, it would be written by 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., and cleaned and pushed with RC1.
K. Adam White 5:07 pm on November 20, 2019

Continue:
The clarity of the release schedule and designated roles made it very easy to plan development time towards getting 5.3 out the door. I think @francina�?s leadership was superb, meetings were run predictably and well and it felt easy to get involved.

Start:
Dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include:

a description of the change;
the decision that led to this change
a description of how developers are supposed to work with that change.

Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. went pretty well, but despite knowing the schedule we failed to update our component’s handbook documentation in conjunction with 5.3. I’d love to see a more formal “docs-updating” stage in the late phase of a release cycle to ensure that when the release goes out the door, the docs reflect the current reality; and to hold us to keeping our documentation updated beyond ensuring the code comments and @since annotations are accurate.

I think this is especially important for 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/, as we have pluginPlugin 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 release-level changelogs but I did not see or cannot find a formal “what’s changed since 5.2” wrap-up page explaining how to migrate Gutenberg code to work with 5.3. Doing a better job with this is going to become more important over time given the higher velocity of the plugin _vs_ coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

Stop:
I do think that the named roles of the release cycle don’t exactly reflect reality, and could be adjusted; I don’t recall seeing the Release LeadRelease Lead The community member ultimately responsible for the Release. in most of the meetings, so perhaps that role would be better named Product Owner or something like that?
- Riad Benguella 5:35 pm on November 20, 2019
  
  Thanks for the feedback KAdam.
  
  So let me try to clarify to see if I understand properly. We actually did two posts for 5.3 to answer this question “How to migrate 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/ code to work with 5.3”
  
  https://make.wordpress.org/core/2019/09/27/block-editor-theme-related-updates-in-wordpress-5-3/
  https://make.wordpress.org/core/2019/09/24/new-block-apis-in-wordpress-5-3/
  
  Are you saying we should put these somewhere else?
Riad Benguella 7:23 pm on November 20, 2019

Start:

We should start doing major releases more often. In 5.3 we had 12 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/ releases gap between 5.2 and 5.3. This is way too much for several reasons.

– It’s way too much changes for a single release, making it more scary, harder to test and stabilize and the changelog is harder to summarize for third-party developpers.
– We had a lot pluginPlugin 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 authors asking about the new APIs and how to use them before hand.
– A lot of people started recommending installing the Gutenberg plugin for their clients because the experience is always better with the plugin. This is risky as Gutenberg is 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. plugin.
John Blackbourn 8:25 pm on November 20, 2019
Continue:

I like the direction that coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and project release organisation is going, with more structured planning and meetings, and even something that looks a bit like a vision. Let’s continue this, and do more of it.

Start:

This gets discussed on and off regularly – I think WordPress needs to move back to a scheduled, predictable release cycle. The 5.0 cycle caused great damage to the project’s reputation as a stable and reliable one even when introducing large change. We can get that reputation back by re-introducing planned releases, three or four a year, with an eye to increasing the release frequency at some point.

Stop:
- Work on the About page needs to start earlier in the cycle. This is somewhat of a perennial problem and not specific to 5.3. The About page is not in fact a special snowflake and should not contribute to string changes and major patches being made days before release. This is not acceptable for any other feature, it should not be acceptable for the About page. I’m sure the contributors to the About page would agree just as much as anyone else.
- I think the days are numbered for pushing through a feature with minimal discussion with the wider members of that component. The big image handling in 5.3 is a useful feature but it was developed and implemented in a relative silo, and it shows. Given more eyes and more revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., it could have been a great feature that took into consideration wider concerns relating to big media handling. Let’s stop siloed development of features.
- Jake Spurlock 9:15 pm on November 20, 2019
  
  I think WordPress needs to move back to a scheduled, predictable release cycle.
  
  Totally agree, and we can use 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/’s release timing as the main motivator for the releases too.
- Daniele Scasciafratte 10:17 am on November 25, 2019
  
  I agree too, as I written in my comment.
  I think that WordPress is becoming too much startup style with a lot of agile but we are talking by a software used by a lot of people in different ways. Not a SaaS.
Joe McGill 9:00 pm on November 20, 2019

Continue:

Proposing a schedule, scope, and focus leads at the start of a release cycle, as was done by @chanthaboune in https://make.wordpress.org/core/2019/08/07/wordpress-5-3-planning-roundup/ is really helpful in creating focus for a release. We should continue doing this, and get better at doing this more effectively.

Having a dedicated person (@francina) facilitating the meetings and milestones of the release was hugely helpful in keeping things coordinated. Bravo, and let’s keep doing this.

Start:

Ensure each major feature/focus in the scope of the release has someone reporting status weekly, including the need for testing, help with development, etc. We used to be much better at this but over the past few years we’ve relied more on reporting organic meeting notes from teams, rather than explicitly checking in on every feature/focus during the release—which limits visibility on some projects.

Planning ahead for the next release during the current cycle. We could have a roadmap in place that allows people to plan their time in advance of the start of a cycle, rather than needing to adjust their time commitments in order to respond to priorities announced at the beginning of a cycle.

Stop:

Setting release objectives that require the involvement of teams/individuals without first discussing those priorities with those people. I’ve seen this happen on many occasions, so it’s not a direct criticism of any person, but it does create strain on delivery. For example, the a11yAccessibility 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) improvements in 5.3 were great to see and I’m glad they were prioritized, but much of that work required the involvement of a limited number of members of the Media team, which conflicted with the ability to give attention to the other Media related priorities (e.g., large image handling).
Tammie Lister 9:16 pm on November 20, 2019
Thanks for taking the time to ask this, I deeply appreciate the opportunity to do retrospectives each release.

Start
- Design lead would be a great start to have each release. We need this just like other teams do for tech and 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). This person can be a connector, facilitator and help ensure the design is represented not just as a part of a component (it was only with the editor in 5.3). Like other release roles, the person doing this should change each release, an opportunity for leadership should be spread around.
- I think our process for nominating those for releases could also adjust to being more inclusive, I worry that right now we aren’t giving space.
- Mentoring each release: It would be great to see in as many roles as possible someone to mentor each release. A great way to learn the role and then next one (or future ones) step in.
- Testing groups and encouragement. I don’t think testing is seen as enough of a pivotal role.
Stop
- Last-minute pushing. Whilst the end of year release is great it’s not the only release of WordPress to ever happen. Being ok punting and having more testing will help everyone not burn out rushing to last minute.
- Only listing �?coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developer’ as a role, let’s review how we do the credits list and recognise as many people as we can, show the diversity of people and roles that make WordPress.
Continue
- Across team communication. I say this as continue because there are lessons to learn and things to improve but just starting to do this should be recognised. We are all in each release together.
- Build on the foundation laid for the about page. It can be done better each time, we just have to do that together and united.
Thank you, everyone, that did anything for this release. From testing to copy, from design to code, support to showing it at your meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for �?WordPress’ on meetup.com will help you find options in your area... it all mattered and you all made this release happen.
pingram 12:02 am on November 21, 2019

You’ve just updated to the latest release and we want to tell you all about the new goods, but why must this live post-install only?

If I ask any of my clients how they find out about new WordPress features they will all say “after I upgrade it tells me”, they would never click the simple link provided (which should target _blank IMO).

It would be a huge advantage even for me as a developer to click “see what’s new” and a modal dialog be presented w/ a running list of changes, each with links for further granular reading, just like we do with themes and plugins. I’m curious why it doesn’t use the same model as the other update mechanisms, I’m sure it’s been brought up before, no?
covertnine 8:13 pm on November 22, 2019

I think the one piece of feedback I have after working with the new Twenty Twenty theme (as well as our own themes) for a few months with our blocks pluginPlugin 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, is that I wish there was an easier way to disable the inline styling that 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/ adds to the backend.

Normalizing the backend editing experience with the frontend was probably one of the most time consuming aspects of working with the new editor.

There’s no filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to just disable the inline styling from Gutenberg. The only thing presented to me was to enqueue an empty stylesheet–that never seemed to actually work.

I also think some of the body class functions should be added to the WordPress backend editor as well. For example, we have several page templates in our theme that have sidebars–if a user selects one of those page templates to have a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., the editor doesn’t reflect any way to adjust the containers or CSSCSS Cascading Style Sheets. to account for that template change because no backend body class is added in the adminadmin (and super admin)–only on the frontend.

What happens if we need to adjust the width of the container, or move the container to make room for the sidebar?

Differentiating between page templates, post types, and other pages/posts that require different layout widths and alignments for the outer container with simple classes would help with backend/frontend being the same without a ton of extra CSS or flat out just not having it at all so a user is surprised with a frontend layout that’s only 960px wide when it should be full width, or half width with a sidebar. There’s no way to visually communicate these template changes or post type changes if those indeed have different frontend displays as most of our stuff does.

This body class functionality exists on the frontend, so why not extend that to the admin?

One other thing I wish the development process would include going forward is taking some elements of the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. into the Gutenberg editing screens like the mobile/tablet/desktop buttons so we can click on those and preview the layouts on those screens. This would also change that editor-styles-wrapper container width depending on what responsive button was clicked

We actually tried coding all of the above ourselves, but figured it would be something that would be coming sooner rather than later since the code for adding custom classes and changing widths to site previews exists in other places.

Overall, I know my team and I are very happy with gutenberg, and can’t imagine going back to classic editor and 50 custom fields for our clients. We have had way fewer inquiries for support with our new Gutenberg sites, and that’s allowed us to spend more time developing our open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. plugin.
Andrea Fercia 1:51 pm on November 25, 2019
Start:
- Announce the release schedule way earlier. This release cycle started on May. The Make post announcing the official release schedule was published on August 21, with the 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. period starting on September 23. That’s just one month of development time from the official announcement. Some contributors need more notice to be able to plan their time in advance. Project management should strive to publish the official schedule at the very start of a cycle to make that possible.
- Component maintainers: at the start of the release cycle, project management should pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” all the maintainers and ask them what their availability is for the cycle. The available time maintainers can dedicate to their component in the following months should then be made public and shared with all the other teams, as it greatly impacts progress that can be made on the milestoned issues. Each team needs to know at the beginning of the cycle that team “x” can dedicate “y” hours per week to their component in order to be able to set reasonable goals. This should happen before each team makes any plans for the release cycle and starts milestoning tickets. It is perfectly understandable not all component maintainers can have full (or any) time availability for a specific release cycle, but other teams need to know who is available and who can be pinged for a timely feedback.
- CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. teams work: find ways to encourage and motivate all the teams to start development way earlier in the release cycle. The WordPress 5.3 cycle started in May. During this release cycle I haven’t seen great activity on May, June, July or even August. Some broader issues require cross-team collaboration and if one team isn’t that active there’s the risk the activity of other teams gets blocked as well, slowing down any progress. In other words: when a team asks for some specific feedback and then receives a reply from other teams a few days before Beta or even after Beta, that’s not that helpful. It’s already too late in the cycle. Not arguing and not willing to mention specific cases but the whole process could be greatly improved. While collaboration across teams is necessary and adds great value to the project as a whole, it should also work in a way that the activity of one team isn’t blocked by other teams. Improving this process would also allow to avoid “last-minute pushing” of some features that could have been introduced way earlier in the release cycle.
- Improve the weekly developer chat agenda publishing process: I’d like to remind the agenda should be published (at least) 24 hours before the chat. This isn’t just a bureaucratic thing: publishing the agenda well in advance gives people the chance to decide if there are topics they are interested in attending and more importantly can help new contributors to start attending. See https://make.wordpress.org/core/weekly-developer-chats/
- I’d agree with Tammie: process for nominating the release focus leads for releases could also adjust to being more inclusive
Continue:
- Release focus leads. The latest releases proved that having dedicated focus leads benefits everyone and makes the process better.
Stop:
- Stop running the release focus leads meetings in private channels. WordPress is an open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project and should always strive for the highest openness and transparency. Personally, I don’t see good reasons why the focus leads meetings should happen on privately. Public focus leads meetings would greatly help everyone to understand and learn why and how decisions related to the release development process are made. As I see it, public meetings would have a positive effect on the whole community and no downsides.
- Stop updating external libraries close to Beta time: external libraries should be updated at the very early start of release cycles .
- Stop introducing new technologies without a prior discussion to be made during the developer chat, e.g.: CSSCSS Cascading Style Sheets. variables.
- I’d agree with John that work on the About page needs to start way earlier.

Comments are closed.

WordPress.org

Welcome!

Communication

5.3 Retrospective – Call for feedback

WordPress.org

Welcome!

Communication

Share this: