Live data from Hacker News

Why Computing Students Should Contribute to Open Source Software Projects

cacm.acm.org

151–160 of 179 posts

Re: Why Computing Students Should Contribute to Open Source Software Projects

#151

Not the worst idea for students to learn to communicate in the open, which is a hard requirement for OSS contributions. Also the more proactive students would in any case be doing this. And making things a bit more realistic motivates people as well. For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs and you can also help out newbies with nice labels as "good…

>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.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#152
post #53

Earlier quoted context omitted.

Not even that is 100% sure. You still need to vet the tests. Documentation is also a good thing to add. The perspective of a fresh user is precious and only lasts so long. Documenting the onboarding process can point to documentation shortcomings that are great to fix.

I have seen a few big bang 'lets test everything' go horribly wrong. Where you were unsure if the tests or the code were broken. Test code is code. It needs to be reviewed too. It is also dead easy to go too far with it (I know I have fallen into that trap more than once).

I would argue that the more pernicious result is tests that are correct and do pass at the moment they were written but are brittle, test internal interfaces and data, and generally ossify the design of the project because making any change now involves making the change and fixing the dozen tests the change breaks. It's hard to say no to those tests, because, on the surface they appear very thorough, and look brilliant on objective metrics, like branch/function coverage tools. It's only later, when every change, no matter how trivial, requires at least five or six files to be touched, that you come to realize the tarpit that you've ensnared yourself in.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#153

Earlier quoted context omitted.

My school had a co-op program where we would actually get paid to do real work. I think if you want your university program to teach real world skills, a co-op program is the only non-abusive way to do that.

What’s abusive?

Forcing people to work for corporations for free as part of their education.

I paid my way through university with co-op jobs.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#154
post #138
post #97

Earlier quoted context omitted.

Politécnicas are regular universities with a different name.

Quoting https://es.sawakinome.com/articles/university-education/diff... as I cannot be bothered to search it more than a few seconds. " En breve: Diferencia entre politécnico y universidad. • Las universidades tienen un enfoque más amplio y enseñan materias con énfasis en impartir conocimientos básicos con muchos aspectos teóricos con un poco de trabajo de proyectos y tareas de laboratorio.. • Por otro lado, los poli…

That's SEO spam and doesn't necessarily refer to Spain. From the way it's written it looks like it was written by a South American.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#155
post #105

Earlier quoted context omitted.

Yeah I think this is a huge issue. It might be good for the students to get this experience, but it would be horrible for the projects. People working on a project to check a box is not going to lead to good outcomes. A better option would be to require students to work on projects which depend on eachother, and practice pull-requests on eachother's student projects.

How about this? The instructor forks a real open source project, with an existing license, contributor guide, etc. The instructor then picks an issue from the issue tracker with a known solution, but no PR yet. The assignment is to submit a PR to the instructor's fork of the project that fixes the issue, and the PR itself is the final project submission. Points can be deducted, according to a rubric, for failing to p…

It might work, but there's always the risk that someone submits a PR to the repo between the time the assignment is given and when it is due.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#156
post #8

> in the 21st century programming proficiency on its own is neither representative of the skills that the marketplace requires from computing graduates, nor does it offer the strong vocational qualifications it once did. Universities are not vocational education facilities though. Time a student has in university is better spent on getting deeper understanding of things that are hard to pick up in the workplace, and…

I really liked the separation of the theory and higher learning from classes vs learning the hands-on real-world programming from summer and co-op jobs. Even before I had those, I was already a hobbiest programmer on my own time. The difference these days is that people go into CS/software development as a career job and expect a degree to prepare them for it. I'm all for effectiveness so it would be up to each institution, but hopefully they're not continually churning out programmers who would have been good to have 5 years ago.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#158

Not the worst idea for students to learn to communicate in the open, which is a hard requirement for OSS contributions. Also the more proactive students would in any case be doing this. And making things a bit more realistic motivates people as well. For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs and you can also help out newbies with nice labels as "good…

>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…

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.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#159

Earlier quoted context omitted.

I have seen a few big bang 'lets test everything' go horribly wrong. Where you were unsure if the tests or the code were broken. Test code is code. It needs to be reviewed too. It is also dead easy to go too far with it (I know I have fallen into that trap more than once).

I would argue that the more pernicious result is tests that are correct and do pass at the moment they were written but are brittle, test internal interfaces and data, and generally ossify the design of the project because making any change now involves making the change and fixing the dozen tests the change breaks. It's hard to say no to those tests, because, on the surface they appear very thorough, and look brilli…

On the other hand well written tests are awesome. When I have a pull request to review that makes change to a code I'm not familiar with, I always go to see the changes in tests first, to see what has actually changed on the interface level.

Re: Why Computing Students Should Contribute to Open Source Software Projects

#160
I had an awesome professor for a QA course at SFU, who for a project had people choose some piece of open source software at their leisure and work on something substantial for it related to QA. (Adding a different test suite, improving the existing tests, writing some documentation, etc). There was no pressure to actually send the work upstream, but people doing so made him happy. I thought that was a good model, where you get to spend some time with a lived-in software project, you discover the wonderful world of sending patches if you want to, but in general nobody's time is being wasted.

This reminds me of that in some ways, and I think its success depends a great deal on how people are incentivized. There's a tremendous amount to learn from doing this - and it is nice feeling like your assignment is actually something useful - but it's really important people don't feel like they have to get some big change merged to get full marks. That can lead to unpleasant situations.

Post reply on HN