Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helping newcomers become contributors to open projects

journals.plos.org

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Helping newcomers become contributors to open projects

#11

Post by FeepingCreature »

JD557 wrote: post #10
FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

> * Have a style guide. Link it in the README. This saves you time in review. I would go even further and recommend using some automatic style formatter. That way, you can fail the CI step if the code is not correctly formatted and that problem is trivial to fix (just run the formatter).

Oh yeah, good point.

Re: Helping newcomers become contributors to open projects

#12

Post by Kenji »

What do you do when the owner of the repository just ignores your pull request? I put hard work into some improvements and I would also change and adapt them to the repository owner's liking, but he just doesn't reply. He doesn't even say he doesn't have time, he's just completely absent. (And yes, the library is very popular and used by many) It's annoying because I depend on that library, so now I have to depend on my own branch which is obviously not main.

Re: Helping newcomers become contributors to open projects

#13

Post by saagarjha »

Kenji wrote: post #12

What do you do when the owner of the repository just ignores your pull request? I put hard work into some improvements and I would also change and adapt them to the repository owner's liking, but he just doesn't reply. He doesn't even say he doesn't have time, he's just completely absent. (And yes, the library is very popular and used by many) It's annoying because I depend on that library, so now I have to depend on…

Try sending them an email. Be polite, and ask them if they'd be willing to take a look at your change. Make sure to explain why you made it and how it'd improve the project.

Re: Helping newcomers become contributors to open projects

#14

Post by saagarjha »

JD557 wrote: post #10
FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

> * Have a style guide. Link it in the README. This saves you time in review. I would go even further and recommend using some automatic style formatter. That way, you can fail the CI step if the code is not correctly formatted and that problem is trivial to fix (just run the formatter).

Plus I find that having an impersonal tool tell people that they did something "wrong" makes them a lot more likely to fix it and still be amenable to your future suggestions.

Re: Helping newcomers become contributors to open projects

#15

Post by saagarjha »

mlthoughts2018 wrote: post #3

I think some combinations of items 6 and 9 are often missing from projects where there’s a quick rush to view issues and bug reports as nuisance instead of viewing them as a lifeline of critical feedback the project needs for survival. I’ve seen it so many times where open source projects have critical bugs, but the existing contributors rush to play the false defense along the lines of “pay us if you want this fixed…

> Obviously no contributor in an open source project _has to_ do anything. But at some level if you’re working on the project because you care about the project instead of burning the commons in a land grab for satisfying personal projects, then taking priority from reported issues and even thanking people for pointing out urgent bugs whose fixes should supercede the fun features of some planned release has to become the expected default.

This is a very important point that I have generally found it hard to express, because it seems so go counter to generally accepted view of "open source means I owe you nothing". Which is mostly true, but in certain exceptional cases it's important to understand that popular but problematic projects suck the air out of viable competing undertakings, and it's somewhat inconsiderate to "squat" on something you wrote for fun at some point, promote it until it is widely used, and then refuse to work on it anymore until people pay you because they can't use anything else.

Re: Helping newcomers become contributors to open projects

#17

Post by saagarjha »

matheusmoreira wrote: post #16

Detailed mailing list instructions would be very nice. I read all I could find about them and still screwed up when I tried to participate in one.

There's unfortunately a lot of song-and-dance that goes into joining a new mailing list, and unfortunately the fact that they go to everyone and often have a different etiquette than other types of online communication can make them a bit scary :(

Re: Helping newcomers become contributors to open projects

#18

Post by scrollaway »

FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

> Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed.

And don't lock them as stale once closed. Holy shit, it's infuriating seeing projects abuse what is essentially an anti-harrasment tool to prevent people from pinging old issues with relevant information. Especially if said old issue is a top hit on Google for some set of keywords.

Losing the context of the old issue often kills contributions outright.

Re: Helping newcomers become contributors to open projects

#19

Post by dessant »

FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

These are all sensible rules, and I think plenty of open source projects are doing fine on this front, though its important to note that properly keeping up with these practices is a full-time job.

Re: Helping newcomers become contributors to open projects

#20

Post by pjc50 »

ermir wrote: post #6

Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher…

It's infuriating to see those complaining about very real barriers to contribution or actual abuses smeared as "rail thieves". For example, the percieved gender of the submitter making a difference to pull request acceptance rates: https://peerj.com/articles/cs-111/
Post reply on HN