Would it make sense to ask for this change to the website?

[anon65535354]

The current docs.rust-lang.org has two things I'd like to be changed:

1. The theme-selection applies to std but not to the main url (that above) which is always bright white. (I'm aware I could just use stylus and write own style, but that's not the point.)
2. Just as we can change the theme I'd like to have a cookie that defaults to one of stable / beta / nightly and it redirects to such url when possible.

Would these requests make sense, or is it too much of an unimportant / irrelevant / not useful change?

[jdahlstrom]

I think the doc.rust-lang.org index page is one of those pages that many people don't even realize exists. In particular, the links on Learn Rust - Rust Programming Language point directly to subpages under d.r-l.o.

However, it is the first hit on google if you look up "rust doc" (at least to me), so it would probably deserve some love. As it is, it's styled neither like the main rust-lang page nor like the rustdoc pages, which makes the part of me sad that cares about branding.

[anon65535354]

Do you agree with the second proposed change as well? And where should this be reported? On /rust ?

[kornel]

Yeah, probably in the main rust repo. That's where rustdoc tracks its issues, and it's going to need rustdoc's cookie.

Maybe you could try implementing it yourself?

It's not that hard to get started. When you clone the rust repo, run:

./x doc

And it will build the docs using your local copy of the compiler.

[anon65535354]

Sorry for the rant below, feel free to ignore it. However, I will say this once at least.

And thanks for the suggestion to try to fix it myself.

I've tried before to submit many fixes, PRs, issues, but have had a bad experience with the following repositories: rust-lang/{rust, reference, book}, /cognitive-engineering-lab/rust-book.

Not because anyone was rude, but because it takes very long to get a single comment, and maybe a month to merge a typo (sp. true with the book).

I've read all the contributing guides (for each of those repositories), ways to test and format etc, so this was frustrating for me.

It feels like given the effort it takes to get things how the repository owners like it, and submitting a fix, our time isn't valued. If no one can review, then I only submit issues, not fixes.

I know each has some reason why they wouldn't be able to review fast: not many reviewers, or book needs to be published first or whatever. However, submitting a fix that takes months to be looked at is disrespectful of the contributor's time as well. This side is normally ignored.

The communication is much better here luckily.

So what I do, from now on, is simply to raise issues, and they can decide whether it's relevant.

For this particular case, the response was mild and un-enthusiastic to say the least.

[jofas]

To offer another perspective on this, the vast majority of Rust and in general FLOSS maintainers and contributors do this for free in their spare time. I agree with your approach, i.e. raising issues to see what the maintainers think before creating PRs prematurely, just so that they go through a lengthy review process or are rejected right away. But I don't think criticising slow response times publicly is very productive and only contributes to lack of engagement, due to more people feeling like their spare time is better spent doing something else. Being patient and understanding goes a long way in every human interaction, including writing software with strangers on the internet.

[anon65535354]

I am fine blaming part of it on myself, but I don't agree with the analysis of "free" for multiple reasons:

1. I am also doing it for free. Can I have even minor guarantees?
2. For many contributors this is useful for their work (pretty obvious if one simply checks the main contributors, and I am serious here.) Of course, this is likely not a majority and many do actually do for helping or curiosity.
3. Books do make money with the fixes, couldn't that at least be reviewed in a reasonable amount of time? (In this case, not even Issues are commented in general.)

I think one shouldn't be too naive when thinking about who does things for free or not.

It's about a much simpler situation: are you okay having a PR or Issue commented several months ahead, when you now have changed topics, and instead spend an hour rebasing your branches? This is something each of us has to answer for him/herself.

My own limit for this is: great I help for free, but then I want a timely comment, otherwise I won't participate.

So the blame on me is: I don't have enough patience, or enough empathy in this case.

Of course, sharing a view like this in a Rust (or any other) forum is already being quite naive from my part. But I wanted to be sincere once, and never touch this again.

[jofas]

@anon65535354

I am fine blaming part of it on myself

Just to make sure, no blame was being issued on my part, only a different perspective.

@anon65535354

I am also doing it for free. Can I have even minor guarantees?

This is my personal perspective, but I don't think one is owed anything for their FLOSS work per se. If I extend or fix a project from someone else and inform them about my work, I see this as an invitation for collaboration, not as something that makes them indebted to me. They might take it or they might reject it.

I acknowledge though, there is nuance to this. For issues for example, if maintainers decide to use labels like good-first-issue or E-mentor, E-easy or E-help-wanted in Rust's case, there is a certain expectation that if I open a PR, it will get a review and eventually a merge. OTOH, cold PRs for issues without approval from the maintainers do not warrant any guarantees IMO.

[Redglyph]

I understand the frustration, since I've been there in other projects. But, as @jofas said, it's maintained freely by volunteers, and the lag is similar in many other open-source projects. I don't think the fact some other people benefit from it in their work is relevant here.

The demand is coming from you, so I'd advise you to do it if you think it might be an interesting experience, or just if you're willing to contribute, and knowing that you may benefit from the modification at some point.

The response here seems positive, and I don't see why it'd be rejected, but perhaps there's a zulip channel where you can ask the same question before starting any work on it? I'm not familiar enough to confirm if there's any chance to get a reply there for that particular topic. Perhaps someone else can comment on that?

[kornel]

Yes, the process is slow, and can be frustrating. PRs often sit for months or even years. Even a typo is going to take a week.

OTOH if you just complain here, it won't be any faster, and if you don't find someone else willing to go through the process, it won't result in anything other than likes in the forum (but if you just want to suggest/complain/vent that's fine too).

In my experience, rust-lang/rust isn't disrespectful of submitter's time, if you're not actively waiting for the issue to be resolved. It's slow, but reasonable given constraints. If you can make a PR and leave it, it's probably going to take significant calendar time, but it shouldn't waste too much of your own time.

But I understand your stance completely. I've had frustrating experiences contributing to rust-lang/cargo where what I thought I could submit as a 5-minute fix got dragged into a process taking 2 years, and I'm burned by it so much that I'm automatically frustrated and annoyed from even thinking about changing cargo.