More strongly point people to link to Tracking Issues in the PR template
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- github
- Domain
- documentation
Research direction
Review the proposed PR template in pull request 158737 and locate the current “Relevant Tracking Issue” section. Update it to make the request explicit and ask contributors to write none when no tracking issue exists; done means the template clearly requires either a link or none.
Written by the indexing model from the issue text.
Description
Proposal
See https://github.com/rust-lang/rust/pull/158737 for the proposed PR template:
Relevant Tracking Issue:
---
<!-- homu-ignore:start -->
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, please explicitly write `none` instead.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
<!-- homu-ignore:end -->
I've recently had a few more discussions on how to improve the visibility and legibility of ongoing work. This is one of the more straightforward results of them. If you have thoughts here or would be up to more generally talk about your experience, especially in the context of type system work, please reach out to me! I would love to talk with you about this.
Tracking Issues play a large role in the way people navigate the project. They are often out of date and we have a very spotty track record of cross-linking relevant work. That makes it difficult to learn about the status of that work item and makes it difficult to figure out the implementation history of a feature as a lot of the work isn't linked anywhere. It's generally just kind of annoying :<
Expecting people to just do better™️ doesn't work unfortunately. We've already mentioned tracking issues in the PR template before, but it's been quite easy to ignore. I personally completely forgot we even talk about tracking issues in the PR template right now.
The change I want to do initially is quite small:
- change the PR template to make the "Relevant Tracking Issue" more explicit
- ask people to set it to
noneif there is no relevant issue instead of doing nothing
I believe that having to either link to a tracking issue or alternatively, explicitly state that there is no such issue, should be very little effort compared to actually writing the PR itself and think that this effort should be worth it. If this works out the way I hope I would then change bors/rustbot to initially warn, and later potentially even block on providing this metadata in the PR description.
Mentors or Reviewers
n/a
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member who is knowledgeable in the area can second by writing
@rustbot secondor kickoff a team FCP with@rfcbot fcp $RESOLUTION.- Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
- Once an MCP is seconded, the Final Comment Period begins.
- Final Comment Period lasts for 10 days after all outstanding concerns are solved.
- Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
- If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
- Dominant language
- HTML
- Stars
- 433
- Forks
- 73
- Avg merge
- 1m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-lang/compiler-team
-
final-comment-period major-change T-compiler to-announce
Difficulty 5/5 Over a week Newbie friendliness 35/100
rust-lang/compiler-team#1039 · 2 comments ·
-
major-change T-compiler to-announce
Difficulty 5/5 Over a week Newbie friendliness 25/100
rust-lang/compiler-team#1038 · 3 comments ·
-
final-comment-period major-change T-compiler to-announce
Difficulty 5/5 Over a week Newbie friendliness 28/100
rust-lang/compiler-team#1037 · 8 comments · 10 reactions ·
-
major-change T-compiler to-announce
Difficulty 5/5 Over a week Newbie friendliness 38/100
rust-lang/compiler-team#1034 · 1 comment ·
-
major-change T-compiler to-announce
Difficulty 4/5 3-5 days Newbie friendliness 45/100
rust-lang/compiler-team#1033 · 4 comments ·
All issues in rust-lang/compiler-team
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Ecosystem: ClawMetry — the Qwen Code reader is now free and open source (follow-up to #9294 / #9338) Opencategory/integration priority/P3 scope/documentation status/ready-for-human type/feature-request
Difficulty 1/5 Under an hour Newbie friendliness 84/100