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

81–90 of 99 posts

Re: Helping newcomers become contributors to open projects

#81

Post by fourthark »

saagarjha wrote: post #15
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…

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

Does that happen? Sounds pretty extreme, I hope you are exaggerating.

Re: Helping newcomers become contributors to open projects

#82

Post by yongjik »

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.

Somebody should tell this to Kubernetes developers.

Also, thanks to Github's braindead UI of marking every issue as either "Open" or "Closed", once I click a Google link to any Kubernetes issue I have no idea if (1) the issue is closed because it was fixed in the latest version (so I have to upgrade), or (2) the issue is closed because it turned out to be invalid (so I have to search for something else), or (3) the issue wasn't solved at all, but Kubernetes team decided to tell everybody "Haha we don't care. And to really drive the point home that we don't care, we're gonna auto-close it for lack of activity."

So I have to scroll all the way down and read the discussion. Sorry, that was my pet peeve #168 for Kubernetes. Carry on.

Re: Helping newcomers become contributors to open projects

#83

Post by dspillett »

beart wrote: post #50
dspillett wrote: post #44

Earlier quoted context omitted.

> and hopes that users won't notice the issue It is a little more than that in many cases. People judging a project overall by the number of open bugs reports, no matter how minor, isn't really fair if there is considerable development on more important bugs/features/other elsewhere in the project.

It also isn't fair for people who assume a project that has a large number of closed issues is highly active, when in fact, a large number of those issues have just never seen any activity and were closed for being stale.

If the issues are closed with WONTFIX or similar status, as discussed nearby in this thread, then it should still be clear that something is going on. It is then up to the reader to decide if that something is enough for them to worry about or not.

Re: Helping newcomers become contributors to open projects

#84

Post by jacobolus »

dessant wrote: post #26
scrollaway wrote: post #18

Earlier quoted context omitted.

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

You can learn about a maintainer's experience with closed issues that keep being bumped here: https://www.henryzoo.com/an-issue-with-issues/ Even though I'm maintaining Lock Threads [1], I sometimes shake my head when I come across a closed issue that was locked by it, but I also have to admit that all I want is to ask a question quickly and get the information I need, without considering how my shortcuts affect main…

There’s no special reason maintainers have to respond to (or even read) every comment on some years-old issue.

If maintainers have their email set up to pester them every time someone writes a comment anywhere, that’s the fault of the email setup, not the commenters’ fault.

Instead of locking the topic, consider just leaving a note that future discussion there is likely to be ignored by the team, and then letting users continue to discuss workarounds, etc.; often the issue tracker is the only kind of discussion/help forum available to project users.

Re: Helping newcomers become contributors to open projects

#85

Post by GhettoMaestro »

pjc50 wrote: post #49
TeMPOraL wrote: post #46

Earlier quoted context omitted.

More likely that the person complaining about a social problem is actually trying to make the project worse. Like e.g. outsiders coming out of the woodwork to push CoCs on projects that don't have them. > so all we have to do is ban the person who said that groped them at a conference and we can get back to work Yes. Such an issue should be brought to the police, not be posted on an issue tracker for rallying social…

> Such an issue should be brought to the police ... who will often ignore it. > Cases of exaggerating or straight up lying about sexual harassment in order to remove or destroy someone are common enough Are they?

> ... who will often ignore it.

Acknowledged that it may happen in some cases, and that is extremely regrettable and frustrating. However, I believe that is no justification for jumping straight to what I consider pretty much "mob justice".

Investigations still matter. Facts still matter. You fundamentally have a right to confront your accuser and challenge the evidence in a court of law, before a judgement and potential punishment is rendered upon you. You don't get the same benefit when you are being tried in the court of public opinion (social media). I get suspicious when people skip the court of law route and only pursue the court of public opinion route.

Re: Helping newcomers become contributors to open projects

#87

Post by astrid88 »

dessant wrote: post #19
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.

Yeah, I have a feeling that plenty projects start with this nice set of rules and they get lost along the way...

Re: Helping newcomers become contributors to open projects

#89

Post by StavrosK »

A few friends and I created a community to help maintain abandoned OSS projects, and one of our goals is to foster newcomers and help them make their first contributions to open source projects.

If you want to start (or know someone who does), please point them to our page:

https://www.codeshelter.co/mentorship/

Re: Helping newcomers become contributors to open projects

#90

Post by ljm »

beart wrote: post #51
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…

When I see projects on Github using the Stale Bot to automatically close issues, I don't bother looking any further. There is something so incredibly infuriating about having an issue closed automatically - when I know it is still a problem but no one has had time to look at it yet. It reminds me very much of the MSDN community threads where the accepted answer is "reinstall Windows and see if that fixes it" with hun…

I wonder if this would change if GitHub took the simple step of removing the PR/issue counters from the navigation.

Because I can’t see a reason for automatically dismissing issues you ignore as stale, unless you think the issue count is bad optics for your project.

As well as github’s issue triage piece being non-existent. All you’ve got is a list that shows you 20 things at a time, and it suffers from the social media effect where anyone can add bullshit memes to the thread once someone on twitter has directed the mob to it.

You don’t really see that happen so much outside of github.

Post reply on HN