More strongly point people to link to Tracking Issues in the PR template

[lcnr]

Proposal

See rust-lang/rust#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 none if 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 second or 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.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler