How the Rust issue tracker works

[nikomatsakis]

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.

[brson]

@aturon

Agreed -- I feel like it's failed to really get off the ground for this reason, which is a shame, because it has a lot of potential. We should try to increase awareness for sure.

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.

[matklad]

@brson

What kind of things might we do to improve the viability of frlo?

A good thing to do would be to keep an eye on the issues/pull requests on GitHub - rust-lang/rust-forge: Information useful to people contributing to Rust. There are two rather rather old PRs without any feedback there

[brson]

Thanks for the heads up.

[glaebhoerl]

@brson

What kind of things might we do to improve the viability of frlo?

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.

[jdm]

@nikomatsakis

On a related note, my philosophy on E-mentor lately has been that, if you sign up to E-mentor, you should not only leave a comment indicating your willingness to mentor, you should take the time to write up a comment with enough detail to get somebody started (at least) on fixing the bug, and also leave a few details on how you can be contacted (e.g., your IRC nick), since I think new people to the project won't necessarily know that information. Granted, I've only done this on a few issues, but it seems to be correlated with a much higher rate of people actually following up, so I do think it's something we ought to do.

In general, I think we ought to make adding a write-up part of the expectation for mentoring.

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.