First of all, this post is not emotion-driven, and I am fully aware that the developers of Rust project work very hard. I'm not here to push anyone or blame anyone.
There are two main types of issues in Rust project that I care most:
Bug issues
Tracking issues
Although many issues can be quickly resolved, there are still so many long-standing issues. In terms of scale, those issues could be divided into two kinds:
Major issues that almost everyone care about
These issues can even decide the future of Rust. For example, GAT, const generic, async/await, specialization, etc.
Minor issues
These issues may only affects a few users, or be very corner-cases. For example, tracking issues of some simple std APIs, or bug issues about comipler diagnose output.
This post is about minor issues.
For issues that I have subscribed in recent years, the reasons of the long-standing situation of those minor issues can be roughly summarized as three kinds:
Knowledge-limited
Users posting or responding to this issue lack sufficient knowledge of how to solve this issue. For example, this bug issue is related to LTO, which seems to be hard to fix.
Effort-limited
This is mainly about tracking issues. Some tracking issues have already had implmentations, but still need some more unit tests and documentation. However, as the issue owner and core developers do not have so many efforts, something more important are scheduled first.
Discussion-limited
This is also mainly about tracking issues. Some tracking issues have already had implementations, but there are still some unresolved questions that need more users to discuss.
Here are my questions:
For these long-standing minor issues:
If it is knowledge-limited
As there are more and more talented people joining the Rust project, will they even be aware of certain issues? Is there any stable mechanisms that could show those core developers that "there is a long-standing issue here, and maybe it falls into your expertise"
If it is effort-limited
I think these does not need deep understanding as core developers do. Is there any stable mechanisms that show everyone interested in Rust project that "there is a long-standing issue here, and maybe you could complete it without so much knowledge into Rust compiler"
If it is discussion-limited
This is the most easy one for people to participate in. Is there any stable mechanisms that show normal Rust users that "there is a long-standing feature which have been partially completed, and maybe you could try it and give your opinion about those unresolved questions"
And for a long-standing issue, if I do not have ability to push it forward, how can I express that I care about this issue very much? Does the thumb reaction of the issues count? Does the subscription users number count? This is also related to the last question:
Is there any public docs about how issues are sorted for Rust core-devs to solve?
Hey so for long-standing tracking issues specifically: of you find the API or whatever is very useful, one thing you can try is writing up a stabilization report. This can help move things forward, especially for relatively minor changes.
Another thing that's always helpful is providing constructive feedback. If you encounter an ergonomic issue or if using the feature makes things significantly easier for you, report back.
Is it better to report back in IRLO or directly in tracking issues? I used to share a use case in tracking issue, but got marked as off-topic (here (perhaps because this feature is not minor issue and this would spam a lot of people?))
It seems like an assumption underlying your questions is that there are people who want to contribute to Rust, have the ability and the time, and are looking around for things to work on because they aren't finding enough to work on.
I'm not sure that's the case. I think people involved with the project already have more they would like to make progress on than they have time to make progress on, so providing more awareness for particular issues won't actually change anything.
Niko and others have been coordinating "project goals", and this is the process by which teams are deciding on and communicating about the high-level projects they're working on. I'd suggest starting with the most recent project goal update blog post and following links from there to learn about this process.
I totally agree that we should not push any more burden on Rust project developers since there are too many things.
However, there may be some sort of convoy effects here. The Rust project goals main focus on the major issues I mentioned in the post. I'm not saying it's wrong. They are important and should be pushed forward in a higher priority. However, solving them is very hard, so it's almost impossible for the Rust core devs to solve those minor issues, which leads to more and more long-standing minor issues. On the contrary, the minor issues may not be so hard, so I think those are better to be solved by other people that are not so familiar with Rust compiler internal. As a result, I expect there would be some sorted lists of minor issues (just like the "help wanted" section in TWOR)
I think the best way for these minor issues to get done, then, are for those people that care most about them to work on them! If you're looking at those issues and thinking "I have no idea how to do this"-- please ask for help, pointers, places to start! I think it's way more likely for an issue to get fixed if the person working on it is highly motivated, because yes, it's difficult (but doable, everyone starts somewhere).
