mention S-tracking-needs-summary under "what should i work on"

[lolbinarycat]

summarizing long discussions is very helpful, doesn't demand reviewer attention, and doesn't (usually) require knowledge of rustc internals, and doesn't even require writing any code.

all of this makes it a good way for beginners to meaningfully contribute to the rust project.

[fmease]

summarizing long discussions is very helpful

From the label's description: Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.

So it's less about summarizing what's been jotted down or discussed in the GH thread and more about gathering information from various possibly obscure sources like rust-lang/*¹ GH issues (not just the tracking issue), PRs, Zulip topics, HackMD docs and likely also past initiators and contributors (necessitating interviews).

Idk how easy it'd be for beginners to take on such tasks. Altho it might be easier than I think, not sure.

I'd say the hard part would be to figure out the major blockers and unaddressed concerns of a given feature which past contributors have never written down in the tracking issue for various reasons (e.g. if they used to actively develop a feature, got stuck² and then became inactive or disinterested).

This is just my own conclusion based on personal observations and experiences.

Footnotes

1. Apart from rust-lang/rust this may include other r-l repos, esp. the ones corresponding to specific teams, working groups and project groups. ↩

2. This isn't unlikely in the event of non-trivial blockers like architectural limitations or in situations where it's unclear what the scale of a given problem actually is, e.g. if it affects/concerns multiple systems/areas and the various interactions are less than obvious. ↩

[lolbinarycat]

fair, but how easy is the rest of that list, actually?

contributing to clippy can be expecially rough due to the relative lack of issue triage