talldan
commented
1 year ago A "guest" contributor cannot create a branch in this repo. We must fork to a personal repo.
There's existing contributor documentation for using git, it might be a good idea to link to that or promote using the github UI for doc changes.
Is it a directive that people are not following?
The prefixes are not very well policed, and I even see experienced contributors not using them or using them incorrectly. I don't think it's really an issue, it's more a guideline to help keep things tidy. A docs prefix sounds ok.
Community contributors don't have permission to label a PR or issues.
It seems fine for the reviewer to add the label in this situation, I agree that a little bit of clarification in the docs would help 👍
Description
I just made my first PR to a Gutenberg developer doc. The instructions in the Contributions documentation for the Block Editor Handbook require a review.
Example 1 source
A "guest" contributor cannot create a branch in this repo. We must fork to a personal repo.
Branches in this project include the prefix 'try', 'add', etc. There are a few 'docs' branches, but there are many branches related to docs that are not in this sub-branch. With no other guide, and limited by (reasonable) permissions, I created a branch in my personal repo and submitted a PR to trunk from there.
We need to ensure that expectations can be met, given the protocols in place.
Example 2
Community contributors don't have permission to label a PR or issues.
Summary
It's obvious that the contributor doc defines a solution to a problem where a PR might not be found quickly by an appropriate reviewer. With no label or branch encoding, there's nothing for designated assignees to search for. Is that still actually a problem? If so, given the permission restrictions in place, what else can be done to solve that problem?
The doc was written for authorized contributors who have permission to create branches and to set labels. I don't think these docs are "wrong" in that they do apply to some people in this audience. Let's say this doc is incomplete in that it does not apply to others in the audience.
Note also that instructions for reporting issues are also a bit out of sync with this environment. For example, I don't see a way to report a doc-specific issue in this repo. A guest cannot label one of these issues. And the issue template has required fields for "steps to reproduce", and "did you disable all plugins except Gutenberg" ... when that metadata doesn't apply to documentation.
Please revise instructions to reflect what is desired or expected from "guest" contributors to make it easy for everyone to submit and process a doc issue or update for this project.
Extra Credit : If similar instructions are in contributor docs for other WordPress components, perhaps we should create a version of this issue/ticket/card for similar reviews where required.
Thanks.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
No