It seems they do not want you to report an issue without an accompanying fix for it.
> If you would like to report a problem you find when using you-get, please open a Pull Request, which should include [snip]
Can't say I've encountered this before.
> If you would like to report a problem you find when using you-get, please open a Pull Request, which should include [snip]
Can't say I've encountered this before.
A detailed description of the encountered problem;
At least one commit, addressing the problem through some unit test(s).
Examples of good commits: #2675, #2680, #2685
i’m almost tempted to add a test suite just to give people more agency over my output because right now i’m only soliciting feedback in person to cut down on internet bullshit, like what happened to xz-utils
`you-get` is currently experimenting with an aggressive approach to handling issues. Namely, a bug report must be addressed with some code via a pull request.
Maybe they got too much spam.
By the way, `tests/test.py` seems to just run the extractors against various websites directly. I can't find where it's mocking out network requests and replies. Maybe this is to simplify the process for people creating pull requests?
Though what I'm unsure how to deal with is legitimate users being idiotic. For example, recently one issue was opened that asked where the source code was. Not only was there a directory named "src" but there were some links in the readme to specific parts. While I do appreciate GitHub and places like hugging face [0], there are a lot of very aggressive and demanding noobs.
I'd like ways to handle them better.... I'm tired of people yelling at me because 5 year old research code no longer works out of the box or because you've never touched code before.
[0] check any hugging face issue and you'll see far more spam. Same accounts will open multiple issues that just barate owners and hugging face makes it difficult to report these accounts.
It addresses the specific issue but does nothing to prevent future similar issues. A solution to a cold is not handing someone a tissue.
I like that these platforms are open to everyone but at the same time there are a lot of people who have no business participating. Being able to filter those people out is unfortunately a necessary tool to not get overloaded.
Worse, I find that due to this many open source maintainers and up being quick to close issues and say rtfm. I can't tell you how many times I've had this happen where in my opening issue I quote the fm and even include a reproducible test. It's also common to just close and say "not our problem".
There are other cases where Goodharts Law fails as well: consider quant firms, where the "metric" used to judge a trader is basically how much money you pull in. Seems to be working fine for them
Seems to make sense
What you're saying is even worse, since you’re implying someone could be an expert computer programmer or power user, but because they’re unfamiliar with the specific language this project chose, they are incapable of making good bug reports. That makes no sense.
Perfectly fine rule for a maintainer to have.
How do you currently submit bug reports on e.g. MS Word or Adobe Photoshop? This way is certainly more open than those commonly-deployed software.
https://github.com/soimort/you-get/pull/2680/commits/313b8d2...
You do not need to know Python deeply to construct what they are expecting. They’re not actually looking for a unit test or something.
I did. And I looked at all examples of “good commits”, not just the trivial ones.
https://github.com/soimort/you-get/pull/2685/files
That’s already complex for someone unfamiliar with the software (which might nonetheless be able to open a competent bug report).
Or, you know, the user is not a developer. Or is unfamiliar with Python, or their test suite, or git, or…
It is perfectly possible to be good at reporting bugs but be incapable of submitting pull requests.
By asking users to provide reproducible test cases, you can massively reduce the amount of work you have to do. Of course that means 90% of bugs will never be reported. But since you don't have the resources to fix them anyway, why not just focus on the bugs that can be reproduced and come with a test case...
It’s your prerogative if and how you want to limit the amount of people who can contribute, but I was explicitly replying to someone claiming that a person’s inability to code is in any way related to the validity or importance of the bug.
I know how to make an isolated virtual environment, install the package, make a fork, create a test and make a PR. But I don't know whether I care enough about a random project to actually do it.
If this results in the project being easier to maintain and being maintained longer, then I’m fine with this.
Relative to what? Learning someone else's code base well enough to write a useful test is not trivial.
It's not a bad method, but the vast majority of users won't be capable of writing a test that encapsulates their issue.
Provided the maintainer is willing to provide some minimal guidance to issue reporters who lack the necessary know-how, it even seems like a clever back door way of helping people learn to contribute to open source.