Repository navigation
Unstable Book Updates needed #57224
Description
Activity
- bind_by_move_pattern_guards -- tracked by Tracking issue for Pattern Guards with Bind-By-Move #15287
- crate_visibility_modifier -- new issue is (Modules) Tracking issue for
crateas a visibility modifier #53120 - custom_derive -- removed from language by Unsupport
#[derive(Trait)]sugar for#[derive_Trait]legacy plugin attributes #54271
Reacted by Tyler J. LaingI think we need to rethink the unstable book altogether. Every time I have gone to it, it has been... unhelpful. Usually, I just end up reading the tracking issue anyway. Perhaps what we want instead is an automatically generated index of features... something like a table a like this:
feature tracking issue status asm#29722 implemented, but buggy Though maybe the status is better left to the tracking issue unless we can find a way to update it automatically...
Reacted by lcnrYeah, that seems to be the issue in the ones I looked at. If we think of it as source code, the Unstable book depends on those tracking issues. But because there's no checking of the tracking issues, the source code becomes outdated and defective.
Reacted by mark@mark-i-m i have also felt like the unstable book is not meeting its goals. I would be open to the idea of a single page, with the feature names and tracking issues.
Furthermore, the unstable book was made a book with the idea that it could be where documentation lands before the feature does, but given the new changes to the rfc process that @nikomatsakis and others have been talking about, if those changes go through, there will be a new place for them to live, de-ephasizing the "book" nature of the unstable book all together.
I’m curious if you think that should be done as part of broader RFC reform or as its own measure?
Specifically, I think that any successful process reforms will need to include heavy automation to scale well.
Closing this issue after brief discussion in lang backlog bonanza. It doesn't seem like this is driving any real improvement here. Today the unstable book appears auto-generated, at least for lang features, which likely means we have at least a page for each item.
If we want to drive more meaningful content, I think we likely need either automation or better process around updating these pages -- we're generally not great about documentation updates, particularly for unstable features, but it seems like that's something we're slowly trying to do better on (e.g., see lang initiative work). Connecting language unstable features to their initiatives seems like an OK thing to do.
I think the primary value in pulling this info out of tracking issues is likely better searchability, as well as encouraging more documentation-y vs. comment-y writing. That does seem valuable to me.
Mostly listing parts of the book that need work, need tracking updates, etc.
Taking a break, will add more later.