WordPress / WordPress/wordpress-playground

Vision and Philosophy

Open
#472 2 comments 13 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

[Type] Repo / Project Management
Dominant language
JavaScript
Stars
2k
Forks
462
Avg merge
18h 44m
Merged PRs (30d)
33

Description

WordPress Playground Vision and Philosophy


 Mindmap of everything Playground can enable 

Vision

Bring WordPress to Everyone

Playground exists to bring WordPress to everyone—regardless of their skill level, platform, device, and internet speed.

WordPress should be instantly accessible to users, learners, extenders, and contributors with a single click. No pre-requisites, no installation wizards, no tricky errors.

For WordPress as we know it today, it means:

  • Learning via with a guided, interactive WordPress that's embedded right in the tutorial
  • Finding a beautiful WordPress site in a gallery and starting it with a click
  • Writing your first plugin in a code editor directly on wordpress.org
  • Installing a local WordPress with a single click – assuming you even need to install it
  • Sharing your WordPress plugins, themes, and dev sites with a simple link and no hosting
  • Contributing to any documentation should be as easy as clicking "Edit page in Playground"
  • Reading your RSS feeds in WordPress

However, that's just the beginning. Playground can enable so much more.

With Data Liberation, WordPress will become your central content hub for everything from personal notes, to ebooks, to social posts—all stored locally and synced across your devices. With Playground's portability, it will always be a single click away, whether you're using a web browser, a native mobile app, or your favorite code editor running on a remote server. The goal is not to build such applications, but to build a solid platform that empowers the community to build them.

Key features include synchronizing data, WASI build, and mobile apps devtools.

Project philosophy

Focused Framework over Alluring Add-ons

Playground focuses on the minimum work required to fulfill its vision. Therefore, new features are evaluated based on the following question: Does it bring the project closer to its vision in the long run?

Every new feature, no matter how great, makes the codebase a little bit more difficult to approach and adds a little extra time to weekly maintenance. Saying yes to an appealing feature is tempting, but it means saying no to something else. Saying no is difficult, but it makes space for what's indispensable.

Therefore, Playground makes the difficult decision and chooses to focus on its vision – even when that means saying no.

Diligent Design over Quick Quirkiness

Let the long-term success of the project lead the solutions. Some changes can be done quickly, other require more time. Move as fast as the problem allows, but no faster. Move as slow as the problem requires, but not slower.

  • Playground changes affect diverse browser, server, and desktop applications. This project therefore applies more caution when considering the impact a given pull request might have on the various downstream applications using the library.
  • Framework features tend to be difficult to remove. This project therefore delays introducing new features until it's clear there's no existing way to accomplish some goal.
  • Feedback is the single best way to make better software and better decisions. Therefore, even if you have doubts about whether a feature belongs, please share your requests so that your needs can help shape the project.

Developers are under all sorts of time pressures so let's be kind to our future selves. An hour of diligence today saves ten hours of maintenance tomorrow.

Modular Minimalism over Coupled Complexity

WordPress Playground follows the Unix philosophy:

  • Each unit of code should perform one task well. To perform a new task, build afresh rather than adding more features.
  • Expect the output of every function to become the input to another, as yet unknown, function. Only return what's necessary and avoid extraneous information.
  • Field-test new code early and only make it a public API if it stands. Don't hesitate to throw away the clumsy parts and rebuild them.
  • Favor small, focused tools over large libraries, even if it means building them from scratch. Only integrate those libraries that are absolutely necessary.

As Antoine de Saint-Exupéry said, "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." Let's aim for this kind of perfection.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the Vision and Project philosophy sections together with the linked Playground mindmap. Determine whether this issue needs editorial agreement or a concrete documentation destination; it is done when the project has an accepted, maintainable vision and philosophy document.

Written by the indexing model from the issue text.

Assessment

Tech stack
wordpress
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.