-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reshaping Contributing docs #67785
base: trunk
Are you sure you want to change the base?
Reshaping Contributing docs #67785
Conversation
Adding new docs on how to contribute to WPDS, including specific guidance for documentation and components
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @juanbuis! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
This is my first PR at WordPress, so apologies if I'm doing anything wrong — I'm open to any feedback! :) |
Hi @juanbuis 👋 I'm answering the "Needs Copy Review" ping. Can you point me to the copy you'd like reviewed? |
Thank you! Would love a read-through of all new pages that have been added with this PR: storybook/stories/contributing/contributing-components.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @juanbuis, this is looking great—I added what looks like a lot of comments but they're basically the same 2 to 3 concerns repeated across instances to make sure we address it all.
Thank you for your work! 🙏
- How much effort will be required to create and maintain it? | ||
- Is there a clear purpose for it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These questions are great. I think they might have even more impact if instead of a deterrent, they could be part of a quality assurance checklist that or something of sorts?
- Does it overlap functionally or visually with any existing components? Can we use existing components to implement an alternative solution? | ||
- How much effort will be required to create and maintain it? | ||
- Is there a clear purpose for it? | ||
- Can we introduce this change without causing breaking changes? Will we be able to keep this change and iterate on it in the future without causing future breaking changes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a breaking change? And maybe link to what makes a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find WordPress guidance on what makes a breaking change — do you think I could link out to general guidance?
Alternatively, we could rewrite to something like:
“Can we make this change without causing a breaking change (something that forces users to update their setup or workflows to keep things working) and will it allow future updates without similar issues?”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Au <[email protected]>
Co-authored-by: Au <[email protected]>
Co-authored-by: Au <[email protected]>
Just to recap my conversation with @juanbuis—my understanding is that this text has already been reviewed by Michael Pick. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for preparing this, Juan!
I have two high-level concerns:
- It is unclear what exactly the WordPress Design System is, and how "contributing to the design system" differs from "contributing to the components package", for example. In fact I don't think we can make a clear delineation between the two since it's very intertwined right now, and there is not much practical difference in the contribution process.
- I'm afraid that having a completely separate set of docs for "design system contributions" in addition to the central contributing docs, despite the processes being almost identical, will lead to unnecessary duplication/fragmentation. That increases maintenance cost for us, while adding cognitive load to our audience since they may have to read through both documents.
So to balance those two out, I'm wondering if we could:
- Make this more like a single landing page, where we explain what the WordPress Design System is, tell people about the Slack channel, and then link to all the relevant contribution guides that already exist centrally.
- Any gaps in the existing contributing guides should ideally be improved/added on those documents themselves. (I'm sure you noticed a bunch of gaps while preparing these!)
- Does it overlap functionally or visually with any existing components? Can we use existing components to implement an alternative solution? | ||
- How much effort will be required to create and maintain it? | ||
- Is there a clear purpose for it? | ||
- Can we introduce this change without causing breaking changes? Will we be able to keep this change and iterate on it in the future without causing future breaking changes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Include inspiration from other products (optional) | ||
- Tag the [@WordPress/gutenberg-components](https://github.com/orgs/WordPress/teams/gutenberg-components) and [@WordPress/gutenberg-design](https://github.com/orgs/WordPress/teams/gutenberg-design) GitHub groups | ||
|
||
Add the “Design System” label to correctly categorize your work. Also, consider adding other labels depending on your needs, like Needs Design, Needs Copy Review, Needs Dev, or Needs Accessibility Feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could leave this out, since I don't think new contributors have privileges to add arbitrary labels anyway. More experienced contributors with privileges will label them accordingly, so new contributors mostly shouldn't have to worry about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean, but wouldn't it be helpful for a new contributor to get used to labeling their issues correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They literally cannot because they do not have the rights. I believe it works the same on almost all open source projects on GitHub. They gain rights when they join the Triage team or meet the criteria to join the Gutenberg team.
|
||
<Meta title="Contributing/Components" /> | ||
|
||
# Contribute to components |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better if we reviewed changes as a diff on the original file, since it's unclear which parts have been changed here from the original.
### **Small copy changes** | ||
|
||
If you see a spelling, punctuation, or grammatical error anywhere in the documentation, you can help fix it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These trivial edits definitely don't need an issue opened beforehand — it can go direct to a PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opening an issue is easier than creating a PR for people who aren't comfortable with Git — especially in the current workflow that requires forking and cloning the entire repo. I think having this option allows more people to contribute, but I'll rewrite everything to make it clear that if you're comfortable creating a PR, that you can just do that :)
Ideally there'd be an "edit page" button that allows someone to directly create a PR with any copy edits, but I don't think that's possible with the current setup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be pretty easy to make copy edits without forking/cloning locally. Edits can go straight to PR in the browser (for example using this link).
|
||
After opening your issue, reviewers will start a discussion in the comments to see if it's an appropriate change. When it’s approved, the community will take care of making the change — unless you want to create a PR yourself. | ||
|
||
### **Adding new pages** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm kind of doubting that a new contributor would be able to (or even want to) author a page from scratch on a foundational aspect of the design system, which requires a deep understanding of the whole.
I wonder if we should focus on improving flows for the more likely entry points for new contributors, which will be to edit existing pages. For example I could add some kind of footer on the doc pages, that links out to a GitHub view to edit the doc.
Co-authored-by: Lena Morita <[email protected]>
Co-authored-by: Lena Morita <[email protected]>
|
||
Creating a new page takes more work and will need feedback from the community. That’s why you’ll need to open an issue on GitHub to track the progress of your new page. | ||
|
||
#### **Step 1: Open a GitHub issue** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was surprised to see this document going into such depth. Before going into writing those up in such detail, I'd suggest:
- Referring to any pre-existing documentation in https://github.com/WordPress/gutenberg/tree/trunk/docs (in this case, https://github.com/WordPress/gutenberg/tree/trunk/docs/contributors#repository-management and https://github.com/WordPress/gutenberg/blob/trunk/docs/contributors/repository-management.md#issues are good examples)
- Linking to the respective documentation from here, keeping this mostly an index with context and links
- Contributing to the existing
/docs
to improve them if a detail is missing - Creating new
/docs
if an aspect of contributing is not documented at all
After all, if a document tries to address all questions and solve all problems, it usually addresses none. And there's no need to rediscover the wheel; we are standing on the shoulders of giants when reusing the existing docs that are the product of years of iteration from many contributors.
Adding new docs on how to contribute to WPDS, including an overview, how to get started with contributing, and specific guidance for documentation and components.
Related issue: #66016
What?
Why?
Make it easier for anyone to get started contributing to the design system.
How?
Rewritten pages with clearer structure, an overview page, a new page that explains contributing to documentation, various step-by-step guides, a "how to get started" guide, plus a new "Contributing" section that holds it all.
Testing Instructions
Please check for inaccuracies, missing content, language.
Also I'd love for someone to check if i edited storybook/preview.js correctly