Shape the Blueprints Community Space

[adamziel]

The Blueprint community space should empowers the developers to explore, share, and remix WordPress configurations. Need a preconfigured Woo store? It’s there. Want to share a fancy development setups with tools like database explorer and WP-CLI? Go for it!

Here’s my best guess of the minimal set of features required to launch the initial version of w.org/blueprints.

User flows

• Onboarding page: I learn why Blueprints are useful and what I can do with them. It’s similar to the /blocks page.
• Browse Blueprints: I can browse and search the available Blueprints.
• View Blueprint: I can run a Blueprint, download a blueprint, and preview its JSON contents. I can also learn who submitted it, when, how did they describe it, etc.

Contributor flows

• Blueprint submission: I can submit a Blueprint to the directory. For simplicity, it could only accept a single Blueprint.json file with no additional assets.
• Documentation: I can read examples, tutorials, and references about building and debugging Blueprints. This is where the developer tools would be described (for now it’s just JSON schema for code completion in VS code or PHPStorm).
• Collaboration: I can discuss Blueprints, collaborate on them, ask for support, and report errors. This is where community forums, Trac labels, and clear error reporting guidelines come into play.

Open questions

How should Blueprint submission work?

Here’s two ideas:

• Build a submission form on w.org. It could only have a single file/textarea field that accepts valid blueprints with no additional assets. The same form would handle updating the existing Blueprint.
• Use a GitHub repository. Submissions would be Pull Requests and GitHub would also solve management, storage, serving (via raw.githubusercontent.com) and collaboration. It would need to be connected the Blueprints repo to the browsing experience on w.org.

[adamziel]

Required developer documentation: https://github.com/WordPress/blueprints/issues/64

[adamziel]

Let's move forward with the following scope:

• GitHub Repository as v1 of the community space. It's easy to build, provides contribution and support workflows, and is supported by Playground previews. I've started one here.
  • Design visitor workflows
  • Onboarding – Explain why Blueprints are useful and what I can do with them. I've started the main README file with that info.
  • Browse Blueprints – Currently it's an auto-generated GALLERY.md file with a list of all Blueprints available in the repo.
  • View Blueprint – The GALLERY.md contains a "preview" link and a "view source" link.
• Design contributor workflows
  • Explain how to build a Blueprint – This is missing. Developers should have access to examples, tutorials, and references about building and debugging Blueprints. This is where the developer tools would be described (for now it’s just JSON schema for code completion in VS code or PHPStorm). GitHub issue.
  • Blueprint submission – README explains how to submit a new PR. We'll need an PR template with some guidelines and a checklist.
  • Blueprint review – Playground Maintainers will review new PRs at the beginning, document our review guidelines, and then hand off the review process to community volunteers.
  • Asking for support – README explains how to ask for support by creating a new issue. We'll need an issue template with some guidelines.
  • Getting support – Playground Maintainers will monitor new issues at the beginning and use them to inform Playground development and documentation.
  • Prepare 10 starter Blueprints to test-drive the contribution workflows and launch with some content in place. GitHub issue.