-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: add stability dashboard #15586
Conversation
For reviewing, you can see the rendered documentation at http://aturon.github.io/stability-dashboard/std/index.html |
ImplItem(_) => true, | ||
_ => item.visibility == Some(Public) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have suspected that the previous passes of rustdoc would have stripped non-public items. Did you find that to not be the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was not the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have some examples of things that perhaps should have been filtered, but weren't?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hah, sorry for the lack of detail, I was in a bit of a hurry last night.
It's not a bug in rustdoc; it's due to two things:
- The stability summary is build prior to a crate folding step that drops some of the items. I did this because rustdoc deletes trait impls, tracking them in a side table instead (so that they show up on the trait and type, not on the module defining them). But for stability summarization, we care about the module where it's defined.
- rustdoc normally filters out only some of the private items at the top level -- basically, modules. In other cases, it deals with privacy as part of rendering, e.g. showing that a
struct
has some additional private fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm interesting! That's not quite what I would have expected. It's probably fine for now though, so I'm not too worried.
The specific numbers/percentages may not be too useful on the stability dashboard as they're tough to correlate among one another at a glance. Perhaps the entire row could represent 100% and then left-to-right there would be proportionally sized bands for each stability level? That may help the at-a-glance impression of whether a module is stable or not. |
This commit adds a crate-level dashboard summarizing the stability levels of all items for all submodules of the crate. The information is also written as a json file, intended for consumption by pages like http://huonw.github.io/isrustfastyet/ Closes rust-lang#13541
This commit adds correct stability tracking for struct fields and corrects some places where rustdoc was not pulling the stability data.
@alexcrichton Fantastic suggestion; I've updated accordingly. |
\o/ |
Using colours only for these indicators is not good for accessibility; ignoring screen readers for the moment, colourblindness is going to be an issue here. |
Why are the bars for std::mem, std::os, and std::ptr shorter than all the others? I also agree with ChrisMorgan regarding color selection. Accessibility is important. |
@bstrie The "shorter" bars are really modules with unmarked items (currently, intrinsics), which are confusingly colored white. I will fix this. @chris-morgan Agreed about accessibility. If you have a pointer to a simple way to provide an accessible alternative here, I'd be glad to incorporate it. |
@huonw I would love to integrate this with http://huonw.github.io/isrustfastyet/ -- I set it up to produce some simple json that should be easy to incorporate. A graph of top-level counts for libstd over time would be really cool! Let me know how I can help make this happen :-) |
In general, if you want to pick color ranges safe for the colorblind, http://colorbrewer2.org/ is a great service. It's for built for maps, but if you pick "colorblind" and "sequential" or "diverging", the result is usable for other things. It avoids using pure colors and picks schemes that still make sense even if you cannot see one of the base colors. Even the "reddish" themes still make sense by falling back to other tones. IANAD, I only took a PhD course in data design, so YMMV. |
Came here via Twitter - not involved in the project, but know a few things about accessibility with screen readers. This should have a hidden 'skip to content' link. It's super helpful when using a screen reader to be able to skip the navigation. Check out github itself for an example (cmd + f5 to enable voice over on os x) |
I would also suggest using Chrome's Dev Tool Accessibility extension. Results of running audit on: http://aturon.github.io/stability-dashboard/std/index.html
|
Color Oracle is a nice tool to get an approximation of what a design looks like to a person with various forms of color vision deficiency. The green (stable) and red (experimental) would be difficult to distinguish for anyone with deuteranopia. Using other colors or different brightnesses may help. Alternatively (or additionally), using distinct pattern fills (vertical bars, horizontal bars, etc.) and/or text labels would help. |
This PR adds a crate-level dashboard summarizing the stability levels of all items for all submodules of the crate. The information is also written as a json file, intended for consumption by pages like http://huonw.github.io/isrustfastyet/ Along the way, fixes a few bugs in stability tracking and places where rustdoc was not pulling the existing stability data. Closes #13541
The easiest way will be getting the buildslaves to upload this information to S3 similar to how they upload benchmark results (or, at least, used to). Once this is done, it would be a relatively simple addition to the IRFY collector to suck that information down too, and then it's just a question of adding visualisations. |
@aturon I just saw that in contrast to the rest of rustdoc, this new dashboard does not work on smaller screens (as the table uses absolute pixel values). Just wanted to let you know, a responsive table layout might be something that could further improve this. |
shrink_to_fit body source map
This PR adds a crate-level dashboard summarizing the stability levels of all items for all submodules of the crate.
The information is also written as a json file, intended for consumption by pages like http://huonw.github.io/isrustfastyet/
Along the way, fixes a few bugs in stability tracking and places where rustdoc was not pulling the existing stability data.
Closes #13541