Rusty Web Improvement Bureau

OK, I’ve assigned #7 to @alilleybrinker. I’ve also assigned #8 to myself. I’ll aim to get it done next week.

On it; you can assign the GH issue to me. I'm assuming that it's in-scope to talk at a high level about how to write forward-compatible code (e.g. "don't poke at struct layout", "don't use glob imports", plus a link to more details), but out-of-scope to talk about specific [breaking-change]s since 1.0. Let me know if I should be adjusting the focus.

As a thing to link to, it might be worth having a book chapter with more in-depth coverage in the future, but for now I'll link to the RFCs.

Thanks, @geofft!

Some quick thoughts.

The objective is to make users feel confident that their code is not going to break by future releases of Rust; to convey that building a reliable software ecosystem is of primary importance to the project; we have effective processes in place to prevent regressions.

Some points to convey:

  • Rust is committed to maintaining a rock-solid system, while still evolving it carefully.
  • Rust has a policy that governs precisely what types of changes to the language are allowed.
  • Rust has a policy that governs Rust’s interpretation of semver, determining what changes may be made to the standard library between releases.
  • Rust uses advanced testing strategies to ensure the rules are followed. Not sure how much to press this here. We can still do a lot more than we are with tooling.
  • Users have recourse when they discover invalid breakage. What is it? File a bug? Ask for it to be taged I-stable-regression?

We might also summarize the basic rules from both RFCs in a simple way.

To your specific question, I’m not sure it needs to be as detailed as "don’t poke at struct layout", as long as that information is in the linked RFC’s. I do think it’s worth specifying the basics of what is and isn’t defined, just enough to give you the general sense of the policy, and including struct layout in that is sensible.

Those are my thoughts for now. I bet @nikomatsakis, @aturon or @steveklabnik might have opinions.

I'm happy to give a shoot at this.

I'd also like to help with #2 but reading it, I feel I am missing to much information to do it. Maybe if someone helped me with that... But let's start with #3 first.

Any ETAs on these?

@sirDonQui Great! You’ve got #3!

As far as ETA’s, I have no deadlines, but want to keep steady momentum, and I’d like to have all these resolved this year.

Here’s an implementation of RWIB 8, the overhauled download page. I’d appreciate review from other rwibbers.

2 Likes

I’m happy to help with Mission 2, Contributing. I’ve put up a rough prototype at https://github.com/efindlay/Rust_community_page.

Sorry, I mean Mission 2, Community.

@efindlay You got it! Great start.

First draft for the community pages is at https://github.com/efindlay/rust-www.Wordsmithing still required. Three sections require continuous updating, “Past Conferences, Talks and Workshops”, “User Groups” and “Upcoming Conferences, Talks and Workshops”. I’ve tried to make these as simple as possible to optimize the value added to labor ratio. I thought about automating “Upcoming Events” but while most groups are using Meetup, Japan and China are not, so the added complexity would outweigh usefulness, I think. People, in any case, are probably only interested in their own local group, rather than a calendar for all groups. I haven’t touched the Rust front page on my fork, so need to view from [localhost]/community.html. Any feedback would be greatly appreciated, particularly for the dev section as I’m not really familiar about how this would be used.

You probably wanted to link to https://github.com/efindlay/rust-www.

It was noted on IRC that our policies about which platforms are supported (tier 1) are not spelled out anywhere. In general, project policy is scattered, and there is need for accessing it all in one place. Perhaps on the community page?

1 Like

@sirDonQui @Manishearth is also interested in working on our contributor onboarding experience. Hopefully you two can collab.

@efindlay Wow! I’ve reviewed your current work and it’s great. Below are my very rough notes - sorry they are so brief. I think after your next revision you should go ahead and do the PR and let’s start integrating it.

Notes

Good intro.

“We have a great community and we want to keep it that way”. We can be even stronger than this, really crow about it. ex: “Rust is more than just a revolutionary programming language; it is a tight-knit community with a legendary dedication to kindness and inclusiveness (link-to-evidence)”.

“Our code of conduct can be found here.” Instead of calling out links, prefer contextual links: “These tenets are captured in our code of conduct (link), the prime policy document of The Rust Project, which should be observed in all official communications channels, including blah blah blah.” May be too wordy, but something like.

Structure

News sources first is good. Move ‘how to get help’ second. Not sure about the rest.

News

Let’s put TWiR first, with a description of its role, indicate that it’s the best source for curated news about the project. Blog second is good. Let’s also add /r/rust. Even though it’s role is contrroversial, it’s important. Indicate it’s an unofficial source in the description.

Move ‘upcoming conferences…’ to ‘user groups, conferences’ section.

User Groups…

Seems good.

How to get help

This only lists #rust. I wonder if we should be more comprehensive, though some channels like #rust-internals may be more suited for the contributing page.

‘Join a Mail list’ links to reddit. This is weird. I’d suggest leaving this off and linking reddit from news.

Add a link to the moderation team email, explaining how to resolve harrassment, conflicts etc.

People / Rust development

Perhaps this could be reconceptualized as a guide to the project governance structure. The project is lead by the teams, who are responsible for something or other, leading the RFC process by which the language evolves. Legal link can probably also be integrated here with explanation.

Leave contributing, issue tracking to the contributing page.

Other notes

No calendar link or embedded calendar.

Style might be improved but we can tweak later, and we’ll learn more about style as other pages are completed.

User groups page

Awesome.

It says contact the rust community team, but one could also simply open a PR against rust-www, and I think this should be stated to encourage contribution.

Past conference talks and workshops

Good idea, but not enough content to justify yet.

Legal page

Seems ok. Headers need anchors for external links.

There may be room for a more general ‘policy’ page, but I haven’t put much thought into it.

I’ve merged the updated download page. 1 down.

1 Like

I hope I’m not diverging the topic, but a nice future mission would be making and maintaining “Are we there yet?” pages, linked somewhere from the official rust site. The “Are we web yet?” page is abandoned it seems, and the “Are we IDE yet?” is a draft. I find them to be an informative and concise review of the ecosystem, if only they were kept up-to-date. They are a nice form of ecosystem FAQ.

In the community section, I would like to put in something like:

"How to contribute

According to CodeTriage, the Rust language has most contributors than any programming language. If you want to join in the fun but aren’t sure about the process, please read ’Introduction to Contributing in Rust’ and contact our Contributor First Contact at contributions@rust-lang.org."

but that would mean such person would need to exist …

Forward to the rust-community mailing list on google. We're the switchboard.

I'll be writing a short page to that effect as one part of Mentoring newcomers to the Rust ecosystem - announcements - The Rust Programming Language Forum

@efindlay @Manishearth adding a contributing page to the website is mission 3.