How the Rust issue tracker works


#21

If we want a specific I- tag for this, I think we should give it a specific and more suggestive name. I agree that if you think of I- as “priority levels” than it makes sense to have a special case for this, just as crashing and unsoundness deserves its own level.


#22

What kind of things might we do to improve the viability of frlo? Certainly we could link it from the website docs page. We could remove the platform support matrix from the book and link to forge instead (I really don’t think this belongs in the book). We could put this documentation there and link it from CONTRIBUTING.md. If we have a concrete list I’ll either do them myself or write them up and ask for help.

We could also brainstorm content that could live there and ask for help writing it; solicit help fixing the existing pages, which are mostly out of date.


#23

A good thing to do would be to keep an eye on the issues/pull requests on https://github.com/rust-lang-nursery/rust-forge. There are two rather rather old PRs without any feedback there :slight_smile:


#24

Thanks for the heads up.


#25

I was half-jokingly thinking the other day that it should’ve been called dungeon after all because even though forge fits the theme better, a dungeon sounds a lot cooler and would make people want to get involved.


#26

This is the model I’ve been enforcing on the Servo team and espousing to the Firefox team for years, and I’m pleased to see it spreading. Anecdotally, the time-to-completion for mentored issues with write-ups is way lower than for those without.