Live data from Hacker News

Helping newcomers become contributors to open projects

journals.plos.org

51–60 of 99 posts

Re: Helping newcomers become contributors to open projects

#51

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 hundreds of replies after that indicate it did not help.

Re: Helping newcomers become contributors to open projects

#52

Genuinely interested: How are gender identity, race, ethnicity, etc. of any relevance in Open Source Projects? Is this a regular topic of discussion besides the code?

If you look at some other stories, specifically "Text Rendering Hates You" and "Text Editing Hates You Too", working with non-English languages in text is tough, and it gets harder the farther from English you're working with.

Considering ethnicity is the only way to prioritize issues like that.

Re: Helping newcomers become contributors to open projects

#54

Genuinely interested: How are gender identity, race, ethnicity, etc. of any relevance in Open Source Projects? Is this a regular topic of discussion besides the code?

If you look at some other stories, specifically "Text Rendering Hates You" and "Text Editing Hates You Too", working with non-English languages in text is tough, and it gets harder the farther from English you're working with. Considering ethnicity is the only way to prioritize issues like that.

I wasn't thinking of the end user experience, but more of the developer experience. I'm wondering why such a clause is even written in CoCs.

Re: Helping newcomers become contributors to open projects

#55

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…

The CI is something that keeps me from contributing. I don’t say it doesn’t do it’s job and I don’t say it’s not useful. What I mean is the CI is often set up to enforce rules that aren’t clear when you create the pull request.

I’ve a pull request to Ansible that’s open for ~ 2 years now and I keep on doing commits just to satisfy the CI without getting any actual feedback from the Ansible maintainers whether or not my pull request will be accepted.

And just yesterday I opened a pull request on the Azure cli and the CI pipeline forbids pull requests to master without telling first time contributors the accepted workflow.

My contribution is just a small typo fix in a help text, but adding a sentence of how to create a good pull request in the issue template would actually go a long way.

Re: Helping newcomers become contributors to open projects

#56

Genuinely interested: How are gender identity, race, ethnicity, etc. of any relevance in Open Source Projects? Is this a regular topic of discussion besides the code?

It seems likely to be related in some way to this trend.

https://en.wikipedia.org/wiki/Contributor_Covenant

Re: Helping newcomers become contributors to open projects

#57
post #4

Beware, pitfalls. * Make governance explicit: Mostly backfires. * Have and enforce a code of conduct: Mostly backfires. All the recent dramas were entirely caused by having explicit governance and code of conduct bylaws, which would not have happened (and didn't happen) without these before. It only encourages public fights over these.

I really like the Djando CoC (in case someone needs a template): https://www.djangoproject.com/conduct/

Re: Helping newcomers become contributors to open projects

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

I had a similar experience. I sent in a bug fix and some new features. The maintainer partially accepted my fix and ignored the other patches. After many messages and additional work, he just said the features would not be added to the project and that I was free to maintain my own version. Sometimes it's better to just let go.

They probably had their reasons for that... at least you got a closure.

That's why it probably good to talk about bigger fixes first, so you can align your visions.

Re: Helping newcomers become contributors to open projects

#59

Genuinely interested: How are gender identity, race, ethnicity, etc. of any relevance in Open Source Projects? Is this a regular topic of discussion besides the code?

They are relevant due to the "people" aspects of projects, as in, the collaborative aspects of the project. I am guessing you are pulling that line from the code of conduct portion of this post. They specifically mention having a committee of several people from different backgrounds so that the can better assess potential breaches in the code of conduct.

As for if this is a regular topic of discussion besides the code, that obviously varies wildly, but I believe it's being discussed more these days.

Re: Helping newcomers become contributors to open projects

#60

Earlier quoted context omitted.

> Document how to build and run it. This, especially in non-web repos (C/C++) is common mistake of READMEs and docs. Let's take an example of XFCE-WM project [0]. The main README does not include any information how to compile it, nor provides any link to the documentation how to build this very specific code. If you will google it you might find following wiki page [1], which is general for all repositories. In the…

To be fair, that looks like a mirror that’s been separated from its “intended” location (where there might be a link to these instructions) plus it’s a traditional “./configure && make && make install” type project anyways

> that looks like a mirror

Yes, sure - it's a mirror, but take a look at original source [0][1]. I haven't found much information about "build & run" either.

> it’s a traditional “./configure && make && make install” type project

Yes, it is but you are talking about "building" not "running", which is also important process in terms of development. Also, deduction (from source code) what kind of combination of commands might be is a no-go argument for many would-be contributors (I looking at few friends who fall in love in npm start), not saying it requires some experience in specific tooling (here, how to build C projects), which not everyone has.

[0]: https://git.xfce.org/xfce/xfwm4/about/

[1]: https://git.xfce.org/xfce/xfwm4/tree/

Post reply on HN