The RFC issue tracker

[aturon]

The RFCs repo has a long-standing issue tracker, which has upwards of 600 open issues, including some extremely old proposals that were moved over from the main repo.

There was some hope that the issue tracker could be used to centralize discussion on particular topics, but I think that the opposite has happened: it has become somewhat of a dumping ground.

At the same time, this forum (internals) has become quite effective for pre-RFC discussion. The fact that replies bump a thread back to the top also makes it much easier to track what the community is actively discussing. I also think that this forum has significantly greater visibility than the average RFC issue.

I’d like to propose that we shut down the RFC issue tracker and centralize all pre-RFC discussion on this forum, to get more of our eyeballs in the same place.

What do you think? Does anyone find the issue tracker useful in a way that this forum is not?

[jimmycuadra]

Seems like a good idea to me!

[glaebhoerl]

Does anyone find the issue tracker useful in a way that this forum is not?

It’s good for ‘keeping track’: making sure ideas, and previous discussions about them, don’t just fall off the face of the earth after activity lapses. (In particular I don’t feel that RFC issues are, were, or should be a place for pre-RFC discussion - the two serve distinct purposes.) I think internals is more “discussion-oriented” and RFC issues are “topic-oriented” - an internals thread gets started any time someone wants to talk about something, and you don’t ever close an internals thread for being a duplicate. Precisely because active discussions get bumped to the top, it also feels much more ephemeral: you don’t ever really scroll down to look at older ones. By contrast every proposed/requested feature should have a single, persistent, canonical RFC issue to keep track of discussions, postponed RFCs, and so on about it.

They could use some pruning and triage and organization though!

[aturon]

By contrast every proposed/requested feature should have a single, persistent, canonical RFC issue to keep track of discussions, postponed RFCs, and so on about it.

So I agree that this sounds good in principle, but actually keeping such a thing organized just doesn’t seem realistic (especially given our experience so far); I can say for sure that the lang team simply doesn’t have the bandwidth to keep this up – it’s hard enough to keep up with the active RFCs. I’ll note that in both the tracker case and the internals forum, you need to search to find existing threads – I’m not sure how the issue tracker makes it particularly easier to find a thing.

My thinking is that, if we can’t keep the whole world organized (and I think we can’t), then we should try to focus on visibility of the most important issues. I think the way that this forum works, bumping threads to the top, is a helpful way to keep focused on what people are actively thinking about or hitting. And in general, the community is quite good at linking back to previous discussion.

[petrochenkov]

I mostly agree with what @glaebhoerl says.

To be useful the RFC repo needs people with GitHub rights “delegated” by libs/lang/tools teams actually doing triage, setting labels, etc. Anything becomes less useful if not maintained. Exactly the same thing will happen with “issues on internals” as well, even worse, GitHub is a tool supposed to be used for issue tracking after all, unlike Discourse.

The triage may be relatively agressive, for example, research topics, various non-actionable issues, issues asking for backward-incompatible changes; all can be closed. On the other side, officially postponed issues, features potentially desired in a couple of years, features just waiting for someone to write a formal RFC; these can be kept.

[briansmith]

At the same time, this forum (internals) has become quite effective for pre-RFC discussion. The fact that replies bump a thread back to the top also makes it much easier to track what the community is actively discussing.

I find this forum software to be worse than GitHub issues, as far as discussion software goes. Primarily because Ctrl+F for search works very poorly due to the forum software being overly clever with its pagination. it would be great if that aspect of the forum software could be adjusted to disable the pagination and search override stuff if this is done.

[briansmith]

What do you think? Does anyone find the issue tracker useful in a way that this forum is not?

If I have a comment from an issue in my GitHub project’s repo to an RFC repo issue, then GitHub adds a nice back-link from the RFC repo issue to my project’s repo. Similarly, if somebody links to an issue in my repo from RFC repo then I see the back-link in my issue. This is very useful because it allows me to see what features other projects are interested in, and it allows me to investigate what workarounds they are currently employing to work around the lack of whatever feature is being proposed in the RFC.

[aturon]

To be useful the RFC repo needs people with GitHub rights “delegated” by libs/lang/tools teams actually doing triage, setting labels, etc.

So, this kind of maintenance would be amazing, but I’m skeptical of it actually happening in practice. We’ve recently rolled out shepherds for the lang team, just for the purpose of keeping up better with RFCs, let alone the issue tracker. I’m just not sure there’s a strong enough incentive or large enough group of motivated volunteers to pull this off. FWIW, we’ve long had a kind of volunteer army for triaging rust-lang/rust issues, including automated emails giving triage assignment, but the issue tracker is still completely overwhelming. But I’d be happy to be proven wrong!

Really my basic point is that, unless we can find some way to actually maintain the issue tracker, moving those discussions here substantially increases the chances that those discussions are seem broadly by the community (including subteam members, who generally aren’t following the RFC issue tracker closely). I fear that people are having important discussions on the tracker and are assuming they’re more widely seen than they are in practice.

[SimonSapin]

What happens to existing issues?

---

One (very important for this IMO) advantage of Github issues is that they can be closed (when they’re resolved one way or another). And it’s very easy to browse our search open issues. On a forum however, inactive open issues will be buried, with no easy way to separate them from threads for resolved issues.

The CSS WG recently started using Github to track issues. Before that there was only a (then 800+ messages / month) mailing list, and inability to close a thread was a big pain.

[withoutboats]

It does seem like a free for all / dumping ground, but that has its own uses. People can build RFCs from the clay of ideas in those issues, bring them here, and then ultimately PR them.

I occassionally sweep through for lang issues that are clearly dead (so far that’s mostly been pre-1.0 issues that simply aren’t possible anymore). I don’t feel like the many open issues have been a problem as much as the many open PRs are, because I feel that no one has any expectation that any of those issues reach any resolution on any time scale.

[bstrie]

Not to put too fine a point on it, but it may very well be that the RFC issues tracker serves an important role as a dumping ground for ideas that aren’t very well fleshed-out. Python has something similar in the python-ideas mailing list, which was deliberately split out of the original python-dev mailing so that the devs could filter out discussions of speculative language extensions (it’s up to dedicated community members to trawl the python-ideas list and pick out the ideas that seem promising and promote them to PEPs). Be aware that by moving “pre-pre-RFCs” to IRLO that you might consign this forum to domination.

TL;DR: It’s not that I disagree with you about the sinkhole that is the RFC issues tracker, it’s that I think that might be a feature, not a bug.

[bstrie]

(To clarify, I think that officially having pre-RFC discussion on IRLO is a great idea. We often use /r/rust or plain-ol pastebins for that today. But I don’t generally consider the issues in the RFC repo to be fleshed-out enough to warrant the “pre-RFC” title.)

[canndrew]

I can say for sure that the lang team simply doesn’t have the bandwidth to keep this up.

This seems to be the crux of the issue then. How can we expand the number of people working on Rust? Particularly on the lang team? Could we:

• Look for extra sources of funding outside of Mozilla?
• Try to organize volounteers more officially and allocate work to them?
• Reallocate resources amongst the rust teams and leave more of the non-language-design work up to volounteers?

[aturon]

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