Adding an official format to be used for documentation pull requests #2150
Conversation
|
Looks good to me! As you used "must" for the checklist inclusion, you might add a tip where you indicate that this checklist is not needed for simple typo fixes. |
| ~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Following the example, create a pull request will be between your ``improving_foo_and_bar`` | ||
| branch and the ``symfony-docs`` ``master`` branch. |
There was a problem hiding this comment.
It doesn't look correct to me that you use a branch name improving and suggest to base it on the master branch. Bug/Typo fixes or improvements should be based on the oldest branch
|
Great job! 👍 What about adding a todo list? |
…- this follows closely with the new format introduced for the symfony core repository
Adding an official format to be used for documentation pull requests
|
Thanks guys! I've made changes per both of your comments. @wouterj I was also thinking about checklists, but I don't exactly know how we would use them, so I don't want to force it. But if we have some legitimate steps that are taken throughout a PR's lifecycle, and we realize having checklists would be useful, then we should update this. Cheers! |
Hi guys!
This introduces a new PR format for the documentation, similar to what was
just introduced for the core repo and as recommended by @wouterj in our ongoing
conversation at https://groups.google.com/forum/#!msg/symfony-devs/-6HAQgAB2LY/uBSx8uYJQdQJ.
There are 2 parts of the PR process that this doesn't cover:
Code Accuracy Review This is something that the community can help
with, and which increases our speed and accuracy. Having a 👍 or
comments from people on a ticket is a huge help. It's something that happens
already, but it's not part of any formal process.
English Review Also something the community can help with. Even if
you don't understand the code, if your English is good, proofreading for
English accuracy is great. I also proofread things, but I don't catch everything :).
While formalizing things, I want to keep the barrier to entry low. If someone
finds a small typo and creates a PR to the wrong branch and without this
format, I think that's still great!
If you have any feedback specifically about this PR and what we can add to
help document the process, please let me know!
Thanks!