Apologies if this is the wrong place to ask this; I haven't contributed much to Rust yet so I'm not entirely sure how the process works.
I would like to have the Cargo feature described in rust-lang/cargo#8743. I'm happy to do the implementation work myself, but I see on that issue thread that it's been marked as S-needs-team-input for a couple years. How can I move this forward? Should I just open a pull request? Or is there a different step I would need to take first?
Please don't "force the issue" by opening a PR for an Issue that hasn't been marked as "S-accepted". That is explicitly going against cargo's contribution guide.
Yes, this has been needing further consideration for a couple of years. To put that in perspective, we have 109 issues in that state as well as 590 more that need triaging and we have to split our attention between our lives and day jobs, implementing our own features, reviewing PRs for accepted issues, discussing designs for RFCs, and triaging our 1500 issue backlog.
I apologize, it seems like I may have struck a nerve; I opened this thread here first specifically because I was attempting to be respectful rather than just opening a PR, because I read the contribution guide and it didn't seem to say what I should do in this case. I'm aware of the general issues around open-source fatigue/entitlement/etc.
So just to make sure I understand: it sounds like your answer is: "please don't do anything, just wait"?
This would be the easy way, yes. Since the cargo team obviously is understaffed (see @epage's reply), you might as well consider becoming a member of the cargo team and then helping from the inside.
Sure, I'd be happy to do that. I have a couple questions:
A good first step for this would be to provide feedback on the alternative to Ability to suppress "Finished dev target" and "Running <path>" lines without hiding progress indicators · Issue #8743 · rust-lang/cargo · GitHub that was proposed in Ability to suppress "Finished dev target" and "Running <path>" lines without hiding progress indicators · Issue #8743 · rust-lang/cargo · GitHub. If that gets you enough of what you want, maybe you could work on Console output should better reflect the build process · Issue #8889 · rust-lang/cargo · GitHub instead.
As for being a team member, it is a commitment that comes with specific responsibilities and requires demonstrating being able to fulfill those to join. This can be done by regular involvement in development, reviews, and design discussions though it can also help to also have a major contribution that you see through stabilization (e.g. cargo add, workspace inheritance, sparse registry support).
This is a bit of a catch-22, because the current overwhelmed state of the Cargo team makes it hard to contribute.
Going through the right processes risks getting the work stuck in the triage queue for months or years. This is extremely frustrating and discouraging. For an outsider, it feels impossible to get anything substantial done and shipped in Cargo through the proper external contributor process.
OTOH just implementing the things without waiting for the triage process is seen very negatively by the team.
The process feels like it's meant to shield the Cargo team from external contributors wasting their time. That's unpleasant from the contributor's perspective, and it doesn't even feel efficient use of the team's time — having to decide on, approve and plan every change puts the team as the bottleneck, instead of letting more contributors collaborate on the code, and improve upon other contributed code.
It also heavily discourages small improvements and "scratch an itch" contributions, because the whole approval process can take more of everyone's time than just implementing the change.
Please, find a way to make the process not treat PRs as "forcing issues".
I feel that if Cargo had lower barriers to contribution, and was more open to merging unplanned PRs, then it would make it easier for external contributors to get started, and also let other external contributors refactor and refine each others' code, and you'd have more people overall who are familiar with Cargo's codebase and can work on it.
This also goes when reporting issues. With rustc I feel this is largely a neutral or even positive experience as an outside reporter. With Cargo it feels hostile: it is my workflow that is at fault is their default stance until otherwise proven.
(And for rustdoc and clippy you are instead just ignored, it usually takes weeks or months before anything at all happens with a report. Which is still a better experience than with Cargo, somehow.)
Thanks for writing this out! And I largely agree on what you've said.
The process and label system wasn't designed for that. On the contrary, it was initially kicked off for guiding contributors toward a successful contribution (see Improve contributor experience by labeling complexity, ambiguity, and consensus of an issue · Issue #11788 · rust-lang/cargo · GitHub). I wouldn't say it is perfect, but it is not a failure either. I think it was us (at least me) not using it well to help contributors.
I understand that most people don't really read the contributor guide before submitting pull request. I often don't either 
, so can totally relate to the frustration when presenting a hack in high mood, and then got a reply of "this is not yet accepted, and per our contributor guide please open an issue first." It must be a terrible experience. Being the one who opened rust-lang/cargo#11788, if its goal is having a better contributor experience, I feel like if strictly following the process doesn't make it friction-less, we should relax it.
This is a good example that the discussion feels good and smooth, even it was happening within the pull request itself. This is bad because I rejected the proposal too fast, and I could have avoided mentioning the contributing process completely. This is also a failure—I promptly slapped the process in their face and closed the PR just because it was incomplete (can't believe I did that 
). The discussion could have happened there, and then post back to the thread, given the thread is already too long.
For me, the first step is softening the wording in the contributor guide. I'll also keep in mind we're all human. Don't take maintenance as routine works and lose the friendly tone.
Thanks for the feedback again. I really like to see the contributor experience getting better.
Note that these opinions are mine, not from the team.