3 ms·

>For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs I certainly do, but I'm worried about the signal

>For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs I certainly do, but I'm worried about the signal to noise ratio on PRs sinking through the floor. After all, it's not as if the difference between a good PR and a bad PR is magically known to me before I open it and read the patch. The maintainer has to spend a certain amount of time to see if the PR is any good, and if there are a hundred PRs more than usual, then the maintainer going to be much more likely to mass-reject all the PRs from a given institution, regardless of how good they are. We've seen exactly this situation with Huawei and the Linux Kernel, where the kernel maintainers threatened to reject all patches from Huawei because it became apparent that engineers at Huawei were optimizing for the number of patches in the kernel, rather than quality of patches. In the same manner, if a university mandates that a student must have at least one patch to an open-source project in order to graduate, then there is a rather large population of students who will spray patches at every open source project available to them until one of them happens to accept their patch, intentionally or not. Now, that said, I'm not opposed to the idea. Writing patches to an open-source application could be good as part of a larger project. Have the student pick out an open source project (it doesn't have to be big) and write up a report about the architecture used, the reasoning behind the design, and what issues they see. Then, as part of that process, have them write a patch against the project. This patch should be reviewed by the instructor, and should be graded on its own merits. Then the student should submit the patch to the project. At that point, while acceptance of the patch would certainly be nice, the professor should have enough data about the student's ability to evaluate an existing software project and make a meaningful contribution to it to grade the student even if the patch is not accepted by the time the semester ends.

shagie 5y ago
While we don't often look at it that way, each PR has a cost associated with it. If its job code and I spend an hour going over the changes, that's an hour of cost and the org is aware that reviewing PRs is part of my responsibilities and I get paid for that. For open source projects, when someone submits a PR, that cost of time is done by volunteers. For larger projects, reviewing even a "trivial" PR could incur a few hours of work by the reviewers and maintainers. For a non-trivial PR, this is even more of an investment of time by the maintainers. I'm not trying to say "don't contribute" but rather "be mindful of other people's time." The "students should contribute to open source projects" and similar "have a class go and contribute to Wikipedia" or "have a class ask and answer Stack Overflow questions" pushes the responsibility of reviewing that material out to volunteers. The costs of Hacktoberfest and similar "contribute to open source" as a KPI for some organizations are very hard to calculate - but they're there and should not be ignored. This cost is increased when the person is doing it as a one off contribution rather than ongoing as, again, the costs of onboarding the contributor to the workflow for the project is borne by volunteers.

shagie 5y ago

While we don't often look at it that way, each PR has a cost associated with it. If its job code and I spend an hour going over the changes, that's an hour of cost and the org is aware that reviewing PRs is part of my responsibilities and I get paid for that. For open source projects, when someone submits a PR, that cost of time is done by volunteers. For larger projects, reviewing even a "trivial" PR could incur a few hours of work by the reviewers and maintainers. For a non-trivial PR, this is even more of an investment of time by the maintainers. I'm not trying to say "don't contribute" but rather "be mindful of other people's time." The "students should contribute to open source projects" and similar "have a class go and contribute to Wikipedia" or "have a class ask and answer Stack Overflow questions" pushes the responsibility of reviewing that material out to volunteers. The costs of Hacktoberfest and similar "contribute to open source" as a KPI for some organizations are very hard to calculate - but they're there and should not be ignored. This cost is increased when the person is doing it as a one off contribution rather than ongoing as, again, the costs of onboarding the contributor to the workflow for the project is borne by volunteers.