Skip to content
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

Merged
merged 2 commits into from
Jul 11, 2014
Merged

Conversation

aturon
Copy link
Member

@aturon aturon commented Jul 10, 2014

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

@aturon
Copy link
Member Author

aturon commented Jul 10, 2014

For reviewing, you can see the rendered documentation at http://aturon.github.io/stability-dashboard/std/index.html

ImplItem(_) => true,
_ => item.visibility == Some(Public)
}
}
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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:

  1. 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.
  2. 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.

Copy link
Member

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.

@alexcrichton
Copy link
Member

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.

aturon added 2 commits July 10, 2014 20:51
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.
@aturon
Copy link
Member Author

aturon commented Jul 11, 2014

@alexcrichton Fantastic suggestion; I've updated accordingly.

@brson
Copy link
Contributor

brson commented Jul 11, 2014

\o/

@chris-morgan
Copy link
Member

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.

@bstrie
Copy link
Contributor

bstrie commented Jul 11, 2014

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.

@aturon
Copy link
Member Author

aturon commented Jul 11, 2014

@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.

@aturon
Copy link
Member Author

aturon commented Jul 11, 2014

@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 :-)

@skade
Copy link
Contributor

skade commented Jul 11, 2014

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.

@jdjkelly
Copy link

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)

@GEverding
Copy link

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

[Warning] Text elements should have a reasonable contrast ratio (29)

Reason: https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#-ax_color_01--text-elements-should-have-a-reasonable-contrast-ratio

@jacius
Copy link

jacius commented Jul 11, 2014

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.

bors added a commit that referenced this pull request Jul 11, 2014
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
@bors bors closed this Jul 11, 2014
@bors bors merged commit 0487e63 into rust-lang:master Jul 11, 2014
@huonw
Copy link
Member

huonw commented Jul 12, 2014

@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 :-)

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.

@killercup
Copy link
Member

@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.

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create stability dashboard