Community Summit Discussion Notes: Aligning processes and contributions between WordPress Core and Gutenberg

From the schedule session:

WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and 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/ currently have different release schedules and velocities, and are managed in two different locations (TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/./SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/. and GitHubGitHub 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/). This complicates merging Gutenberg code into Core. For example, it is unclear where modificatons should occur, resulting in version control issues. This discussion hopes to bring clarity to these issues and explore possible processes and solutions.

Perspectives needed: Current and interested Core and Gutenberg contributors, project managers, and team members following the release process.

Facilitator: Jonathan Desrosiers (@desrosj)

Notetaker 1: Daniel Bachhuber (@danielbachhuber)

Notetaker 2: Rebekah Markowitz

Notetaker 3: Sarah Norris (@mikachan)

What are some issues we’ve observed?

• Generally speaking:
  • Giving credit
  • We want to unify the teams to be more cohesive 
  • Improving the syncing process from 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 to the core.
    • Currently very time consuming
    • Lots of back and forth
  • Because merges happen so infrequently, we miss out on testing opportunities, incompatibilities, etc.
  • Sometimes the core fix can only be committed when it’s first fixed in Gutenberg. If the backport only happens before the first 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., this is a long wait.
  • Editor component – it feels like it’s being treated in a way that it gives people way less autonomy than any other component. This has less autonomy for leads, and processes for Gutenberg end up not being followed because of that.
    • Some releases don’t seem to have the proper reviews before being released/merged.
    • “Keep autonomy in mind”
  • Might need to create rules around “XYZ” needs to be done before “ABC”. Having to dependent items on the same day is too much.
  • Everyone is probably biased to one side or other of the
  • Double-review process (PHPPHP 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. reviewed once in the Gutenberg repo, and a second time when it’s backported to core)
    • We need to ask why this is happening?
    • This can cause a lot of confusion and double work
    • Are there processes to help the core side trust the Gutenberg side
    • Everyone is assuming that it’s not happening, or people are assuming it is happening or not happening.
  • Minor releases are difficult because of Gutenberg package releases. This makes security releases difficult to prepare.
  • Lack of clear ownership for parts of Gutenberg. They all get thrown into the Editor component in Trac.
  • What code is library code that is developed in the Gutenberg repo. It’s not clear to anybody who wants to change something which is the primary file that needs to be updated, and where does that file need to be copied to
    • It’s a lot of manual effort to make sure things are achieved in a cohesive way.
• Things that done well:
  • The Gutenberg release process seems to be really dialed in. If we could learn from this release process and apply to backporting.
  • Porting the javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. packages
• All of us are here because we’ve been witness to some problems, had to perform cleanup on some of the problems, etc.
  • These are really challenging problems and that’s why they exist. We need to remember that everyone is a person and keep that in mind while framing comments
• Everyone is frustrated about the issue and wants something to change, which isn’t that common in communities.
• One important aspect to tease apart is that this isn’t a monolithic problem.
  • Some PHP code syncs over cleanly. Other parts (e.g. WP_Theme_JSON) are forked, and it’s not obvious where you need to make the change.
• Gutenberg could be considered one component but it actually spans across multiple components (REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., 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), etc.)
  • No way to communicate who is reading what issues and if certain people have seen them.
    • A good CI could solve some of those issues
    • Build things in core that they could be backported earlier
    • So it can be compatible with the new release but also backwards compatible.
    • A lot of trust was lost in the way PHP was backported
• Sometimes backporting doesn’t work and it needs to be “snowflaked” to make it work.
• There’s been some discussions about what to bring things into core.
  • Been a mentality that “Everything in Gutenberg is well tested so if it’s been sitting there with no issues, then it should be ok”
  • There’s been a lack of pressure about what to bring into core. There needs to be a decision made as to whether we backport things or we move on and this is the way it will be.
• There’s a lot of time spent when something is done natively in Gutenberg and then backported into core. 
• Long term: Should we merge the codebases and have different release schedules
• Tracking where a feature should be within an update… it’s difficult. There doesn’t seem to be a long term roadmap
  • The processes for creating a feature in gutenberg is more loose than it is in core
  • Rushing endpoints on REST API is causing a backlog because there aren’t a lot of contributor areas in REST API
• Why is this all being done by hand? Why aren’t we doing a building on a nightly basis or some kind of schedule.
• Core committer on the gutenberg side to sign off on PHP code
• Gutenberg started off on a bad relationship with core. Lack of trust by the core team for the Gutenberg team to produce core-ready code.
  • It feels like gutenberg has all this freedom, while core has a lot of constraints… this can cause a bit of a resentment 
• Better aligning on policies/processes could go a long way in helping to unify the teams
• One challenge is that Gutenberg the plugin runs experiments. Sometimes it’s difficult to know which code in Gutenberg is responsible for an experiment vs. that which should be ready for production.

Why or why not would these ideas work?

• What if Gutenberg had no PHP code?
  • Gutenberg’s commitment to support multiple WordPress versions
  • Blocks with PHP work really well. Increase in functionality within gutenberg in a self contained way so they don’t interfere with core
  • Decreases the ease of testability.
  • Unnaturally separates the whole feature for development.
  • It can kill experiments
  • No one would feel comfortable with not properly tested releases with compatibility between core/gutenberg
  • There is a risk of creating an artificial barrier
• What if we have a mono repo?
  • It would work, but only if we change the processes. More frequent development releases throughout the cycle.
  • Would be ideal from a technical and political relationship
  • Maybe it’s time to retire gutenberg as a separate project? Could be some initial friction, but could result in better process and smoother releases
  • There was a reason for gutenberg to be separate… elements can be used in other platforms and areas on the web. We could lose some opportunities
  • At what point does the feature plug-in become part of core and less stand alone? The next two releases it will be integrated much more into core. Will it just be there for experiments or will it be more integrated into core?
  • Could there be two avenues: One of the public and one for more beta versions?
  • Moving git histories could be problematic and you could lose a lot of relevant info
  • Certain parts could be WP agnostic and other pieces could be more universal
  • Merging repos would likely lead to more visibility across the board
  • Having Gutenberg stay independent of CMS allows the team to push boundaries further
• What if GB testing/releases were built from Core mono repo?
  • Still have Gutenberg the plugin, but built from the monorepo.
  • 300k active Gutenberg the plugin releases.
  • Gutenberg updates don’t regularly take your site. However, testing core can crash your site.
  • Seems like a technical solution. “What are the outcomes we’re trying to achieve?”
  • The more that’s in something, the more complex it is, the more likely it is to break.
• What if every package release was merged into trunk?
  • The node package syncing script is in pretty good shape.
  • Not uncommon for other components to have some initial commits, and then additional cleanup commits (docs, for example).
  • This is maybe the easiest problem to solve, however. It will take some time to fully execute.
  • From an accessibility standpoint, this approach would make it a lot easier to see what’s ending up in core.

What are some strengths and weaknesses of each?

• Gutenberg strengths:
  • Velocity (fast iteration)
  • Review culture (built into flow)
  • Clear vision
  • Not Trac
  • Contributor onboarding
  • Perfect isn’t the enemy of good
  • Written in JavaScript
  • Feels like a safe development environment (move faster, safety net).
  • Able to grant commit access much quicker.
  • Ease of contribution for different levels.
  • Freedom, encouraged to experiment and try new things.
  • Bigger testing base
  • Design and responsibilities built-in
  • Good for previewing features to other teams and users
  • Feels very rewarding to have a feature released in two weeks, instead of months.
  • Issue templates
  • More streamlined and automation
• Core strengths:
  • Encourages more test coverage
  • Project much better w/ planning a release
  • Established foundation
  • Celebrating contributors
  • Attention to detail
  • Age of the project
  • Historical knowledge and learnings
  • Lot of people who have seen a lot of things that have gone wrong
  • Architecture is well-organized
  • There’s nothing better than jumping to a function definition with good documentation, annotations for changes, etc. Build-tech friendly.
  • Responsibly shipping new releases to millions of sites
  • Commitment to backwards compatibility
  • Trac allows assignment to anyone
  • GitHub mirror
  • Trac is problem-first (requires creating a ticket before adding a patch)
  • Pace of change is understandable
  • How easy it is to extend
  • More ownership of different areas / who to contact
  • Props culture
  • Weekly updates
  • Breaking things down into smaller pieces
• Gutenberg weaknesses:
  • Always ships minor releases
  • Clutter when looking through issues and PRs
  • Disconnect between issues and PRs. Discussion happens in both places.
  • Line between experimental and stable is unclear.
  • Dependency tree not visually clear.
  • Lack of tests, especially PHP code
  • Lack of inline documentation, and documentation doesn’t end up on Dev Hub
  • Hard searching for functions.
  • Unclear/confusing team structure.
  • Separate handbook from core.
  • Needs a build toolchain.
  • Hard to follow if you’re not a sponsored contributor.
  • Difficult to figure out where an issue should be reported.
• Core weaknesses:
  • Backwards compatibility.
  • Trac
  • Lack of JS tests, and test coverage generally.
  • Convoluted decision making process, particularly for key decisions.
  • Build process in the repo.
  • It’s not easy to quickly test a patch if you’re an everyday contributor.
  • No velocity.
  • Pragmatic sense has been lost.
  • Contributor onboarding.
  • Lack of an official structure for experimentation.
  • Media Library documentation.
  • Work in GitHub but then have to port to SubversionSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/..
• Challenges or factors we would need to mitigate in a solution
  • Velocity of releases
  • Policies
  • Back compat vs. experimentation
  • Component code ownership
  • Labels and components don’t align.
  • Different ticket reporting systems.
  • Different onboarding
  • How are the decision makers? And for what?
  • Clear vs. unclear roadmap.
  • Commit access
  • Engineering effort to make changes
  • Workflows for PHP developers to contribute to JavaScript and vice versa
  • How we actually operationalize the process

#summit, #summit-2023