# 2022-08-17 backlog bonanza check-in

General link: https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AC-tracking-issue+label%3AT-lang

Explored areas:

* [ ] design-concerns: 45 issues
* [x] needs-summary: 43 issues
* [x] impl-incomplete: 34 issues
* [x] unimplemented: 6 issues
* [x] ready-to-stabilize: 19 issues
* [ ] perma-unstable: 14 issues
* [ ] needs-to-bake: 5 issues

## Goals for this meeting:

* Identify next steps for working through our backlog
* Do we need to split categories?
* e.g., design-concerns -> "needs design meeting", or, "research project"

## How to go forward

We could publish a blog post. Especially the 'needs summary' vary quite a bit in terms of how much research is required etc.

* needs-summary and ready-to-stabilize seem like great "community" tasks -- probably don't need a dedicated attached person (e.g., mentor) to work through
* others need someone excited about *that task* vs. just general contribution.
* and need pairing with a mentor.

should we break up "Design concerns" or "needs summary" further?

* one category is: needs extensive design and research (e.g. specialization)
* others are more minor concerns, needs someone to write a doc, drive a design meeting.

What about needs summary? If reading the thread and searching for features isn't enough, it's more "design concerns" category. We should make it clear that one option is "I can't really summarize this, needs recategorization".

### needs summary

Directions for "needs summary":

> The "needs summary" label indicates that we don't know the "current state" of the issue. Often there have been a lot of github or zulip comments and someone needs to read through them and produce a summary that identifies the key points being raised.
>
> A good summary includes information like...
>
> * Links
> * Where do the design materials live?
> * Major conversations or places it's been discussed (e.g., rfc, notable zulip topics, past PRs or FCPs in this area, etc.)
> * Current status
> * What has been done?
> * What questions have been considered and settled? (e.g., via FCP)
> * What remaining questions are there on the design?
> * What remaining work is there to make impl match design?
>
> Here are some examples of summaries in the past:
>
> If you have written a summary, post it to the issue and then nominate it for the lang team by writing `@rustbot label +I-lang-nominated`

### ready to stabilize

"Ready to stabilize" -- maybe 20% are underway (guess), the rest maybe need retagging, e.g. because they need a small bit of impl work. In some cases, hit design concerns during stabilization, but haven't retagged. Probably 10 need a stabilization report and lang team nomination.

Small enough quantity and the work is relatively easy.

### implementation

Could be recategorized as "how big a job is it".

simulacrum: If there is significant remaining work to be done, and it's been 2+ years since we've worked in the area, I hesitate to say let's find a mentor. Maybe it's just...do we want this feature?

Needs some re-review. Question to ask ourselves:

* Is this design really "good to go" for implementation?
* Or should we rethink it?
* If it's not good-to-go, then we should close it.
* If not, then either design-concerns or maybe we close
* Depending on whether we started it? Maybe?

### design concerns

possible resolutions:

* "timeout" -- this has been hanging around long enough that while we still feel positively, we would prefer to restart the design process to account for current circumstances
* most applicable when relatively little impl progress has been made
* sometimes it makes sense to rip out code, but it's good to respect the work folks have already done
* RFC 66 -- niko would be happier if we closed it, started a new RFC
* "do deep research" --
* e.g., specialization
* "shallow, meeting-shaped problem"
* write a doc, outline the possibilities, have a design meeting or two to reach conclusion
* e.g., panic-in-drop?

These feel like decisions lang team is best equipped to make.

We can refine these in future backlog bonanza meetings. Refine the tags based on our conclusion:

* timeout -- we open a issue to rip it out, tag as e-easy (or use the tracking issue)
* deep research -- we leave it (maybe tag ?)
* meeting-shaped problem -- we tag with something

If we can't enumerate the concerns, should we tag it as "needs summary"? Or identify this.

## next steps

* [ ] write up directions for a good summary --nikomatsakis
* [ ] write up a template for stabilization report --nikomatsakis
* [ ] tweet-and-or-zulip or try to find 1 or 2 volunteers to pick and issue and summarize, to test drive directions
* [ ] find an owner who can write up a good summary and re-evaluate if those directions are a good idea