The first version of pull request template #10218
Conversation
We're trying to extract information out off the head of contributors. Hope this help the review process more friendly for everyone.
|
r? @Eh2406 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I do feel this template is a bit heavy and even me don't want to read it. There are some OSS PR template with checklists but I can't think of an applicable way to use it in cargo. To make it more concise, maybe keep the "tips" section is enough? |
| Explain the motivation behind this change. | ||
| A clear overview along with an in-depth explanation are helpful. | ||
|
|
||
| You can use `Fixes #<issue number>` to associate this PR to an existing issue. |
There was a problem hiding this comment.
Another command that is probably most commonly used for me is close#. Would you like to add more? That's advice, of course.
| https://doc.crates.io/contrib/ | ||
| * Run `cargo fmt --all` to format your code changes. | ||
| * Small commits and pull requests are always preferable and easy to review. | ||
| * If your idea is large and needs feedback from the community, read how: |
There was a problem hiding this comment.
To add a sentence：If your idea is large and needs feedback from the community, you are advised to release an issue for discussion first, read how:
There was a problem hiding this comment.
Sounds great! Though I am afraid that the template goes too lengthy and people eventually delete it anyway.
|
Curious what others think! @rfcbot fcp merge |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
Co-authored-by: Ruby Lazuli <[email protected]>
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
@bors: r+ |
|
📌 Commit 3d9d52f has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 10 commits in fcef61230c3b6213b6b0d233a36ba4ebd1649ec3..358e79fe56fe374649275ca7aebaafd57ade0e8d 2021-12-17 02:30:38 +0000 to 2022-01-04 18:39:45 +0000 - Make rmeta_required no longer depend on whether timing is enabled (rust-lang/cargo#10254) - The first version of pull request template (rust-lang/cargo#10218) - Stabilize the `strip` profile option, now that rustc has stable `-C strip` (rust-lang/cargo#10088) - Update docs for windows ssh-agent. (rust-lang/cargo#10248) - Fix typo: substract -> subtract (rust-lang/cargo#10244) - timings: Fix tick mark alignment (rust-lang/cargo#10239) - Remove unused lifetimes (rust-lang/cargo#10238) - Make levenshtein distance case insensitive. (rust-lang/cargo#10224) - [docs] Adds basic CI yaml for GitHub Actions (rust-lang/cargo#10212) - Add function for parsing already-read manifest (rust-lang/cargo#10209)
What this PR tries to resolve?
We're trying to extract information out off the head of contributors.
Hope this help the review process more friendly for everyone.
How to test and review this PR?
Copy this template and paste to your GitHub Web UI to see if it renders well.
Additional information
Kubernetes community has one of the best guide of "Best Practices for Faster Reviews".
It describes tips for contributors tocreate a high quality PR. We might want
to create our own one and include it in PR template in the future.
In addition, I don't know how much time it take to update the changelog. I saw
some projects let PR author write down the release note of the PR. This sounds
helpful to take some burden off from maintainers, as well as let contributors
feel more involved. Anyway, it's not in this PR but is good to discuss later.