How the Rust issue tracker works

[nikomatsakis]

I-needs-decision - No other category applies because somebody needs to decidewhether it’s a bug, how to move forward, etc.

I sometimes use I-needs-decision to indicate not that no other I-tag applies, but that the right way forward is unclear. i.e., for some given unsound behavior, we might all agree it’s a bug, but not on how to fix it. In those cases, there may be another I- tag that applies. Hence, like I-nominated, I think that I-needs-decision is a kind of orthogonal tag.

E-mentor - Indicates that somebody is available to mentor. The mentor should indicatein a comment they can mentor. Should be paired with other “E-” tags. Not pairedwith E-help-wanted.

I’m curious about E-help-wanted vs E-mentor. I don’t understand why they would be exclusive?

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.

[steveklabnik]

Perhaps CONTRIBUTING.md should add a link to this.

Linking means it doesn’t work offline; it’s much better if it’s in-tree.

[troplin]

Hm… shouldn’t I-needs-decision and needs-crater be E- tags?

[brson]

https://forge.rust-lang.org/ is where stuff like this goes now.

This is the right place today.

@steveklabnik I don’t know how much I’d trust anything on FRLO. It has its own page for platform support which is quite outdated compared to the table in the rust book on getting started.

My intent is for that info to live on the forge and not in the book. Obviously needs work though.

I sometimes use I-needs-decision to indicate not that no other I-tag applies

Oops. I didn’t mean to imply I-needs-decision means no other tag applies, just that as a consequence of needing a decision no other tag applies, though I see that’s not quite true. I’ve updated it to reflect what you said.

I’m curious about E-help-wanted vs E-mentor. I don’t understand why they would be exclusive?

To me E-mentor implies that help is wanted.

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.

I’ve updated the text to this effect.

Hm… shouldn’t I-needs-decision and needs-crater be E- tags?

Possibly, yes. Though I might suggest that all the ‘exception’ cases here might just ought be their own tags: needs-decision, nominated, mentor, help-wanted.

[brson]

To me E-mentor implies that help is wanted.

For searching purposes it would be easier for all mentor bugs to be tagged help-wanted so people can just search help-wanted. But that doesn’t seem to be the convention today (and it’s not what I do).

[arielb1]

The compiler team was using the I- tags differently:

• I-ICE - the compiler ICEs.
• I-crash - the compiler crashes without an ICE.
• I-unsound - the compiler does not error out on illegal programs that cause unsoundness.
• I-wrong - the compiler generates wrong code for legal programs.
• I-compiletime - the compiler is slow.
• I-slow - the compiler generates slow code.
• I-enhancement - the compiler lacks a feature.

We do not have tags for:

• the compiler accepts dubious code, but that does not cause unsoundness.
• the compiler errors out on legal code.
• the compiler issues a bad diagnostic (tho we use A-diagnostics for that).

[brson]

It looks to me like all of those interpretations are consonant with mine except for I-wrong.

[kennytm]

Linking means it doesn’t work offline; it’s much better if it’s in-tree.

I’m not talking about the issue tags, what I mean is FRLO is currently almost invisible since it can’t easily be found. Hard to discover ⇒ Less incentive to maintain ⇒ Easily outdated ⇒ etc. Adding FRLO to the Helpful Links and Information section shouldn’t be harmful.

[aturon]

FRLO is currently almost invisible since it can’t easily be found

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.

[nikomatsakis]

To me E-mentor implies that help is wanted.

Sure, but I think in terms of GH queries, and I can easily imagine someone searching for all “E-help-wanted” issues – in that case, I would want them to also find E-mentor issues. I am not totally convinced that E-mentor even needs to exist, tbh, I think it might be better served with just leaving a comment that should be enough to get people started and then linking to that comment prominently from the head of the issue (a bot could help here, by allowing people to easily write a “mentor” comment that gets auto-linked).

[nikomatsakis]

Possibly, yes. Though I might suggest that all the ‘exception’ cases here might just ought be their own tags: needs-decision, nominated, mentor, help-wanted.

I prefer this.

[nikomatsakis]

I-wrong - the compiler generates wrong code for legal programs.

This seems to me to be a bit surprising. Certainly the “plain English meaning” of “wrong” is more expansive. I guess I would expect that A-codegen and I-wrong simultaneously probably imply wrong codegen, but that (e.g.) A-diagnostics and I-wrong might imply “the error message contains incorrect information” or A-const-fn and I-wrong might imply some wrong behavior specific to const fns.

[arielb1]

It’s about the consequence: “I-wrong” means “your code compiles but does the wrong thing” (as opposed to “your code incorrectly fails to compile” or “your code correctly fails to compile but the diagnostic is bogus”).

People (e.g. my employer) are terrified of these bugs and not without good reason.

[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]

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]

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 https://github.com/rust-lang-nursery/rust-forge. There are two rather rather old PRs without any feedback there

[brson]

Thanks for the heads up.

[glaebhoerl]

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]

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.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.