Is it worth submitting a high-quality pull request to add a --dry-run flag to the basic Linux rm command (rm --dry-run -rf), so users can quickly preview all files that will be deleted before actually executing the command? The current workaround of piping yes n to rm -i is not a perfect solution and doesn't match rm's behavior because it asks if you want to descend into a directory, which requires y, nor do several other workarounds (find, ls, etc) match its behavior exactly. I've contributed to open source but haven't contributed to Linux source code before but I think adding this flag would benefit users.
Would a pull request like this be rejected or have a chance of being merged?
3 possibilities:
1. It gets accepted. People who don't care about it can ignore it. People who want to take advantage of it will. You get bragging rights, you benefit, and others benefit.
2. It gets rejected. Assuming your proposed patch is made public, then it will be of benefit to someone who wants to include it themself in their own build, and it can serve as an educational aid to someone who wants to understand the codebase more. You can still point to the PR as evidence of your activity and support for FOSS software. You still benefit, and it may benefit others, depending on their activity.
3. You don't submit the PR at all. You benefit from the personal knowledge that you gained, but it is very difficult to demonstrate/prove that to anyone, and any work that you did will not benefit anyone else.
In other words, just do it. That's my suggestion. It's your life, and at the end of the year, would you rather have tried and failed, or let someone here talk you out of trying at all? Your only choice is whether or not to try. If you succeed, then that makes it even better. But DO NOT pass up opportunities to try to do things like this.
Context: I just had the same opportunity, but with Manim, so I decided to record the process (it's now on YouTube), and I submitted the PR to Manim last night.