Live data from Hacker News

Helping newcomers become contributors to open projects

journals.plos.org

61–70 of 99 posts

Re: Helping newcomers become contributors to open projects

#61

Earlier quoted context omitted.

Yeah. I've witnessed so many controversies I started archiving and collecting them. Code of conduct enforcement is flawed to say the least.

I would be interested in seeing these. My naive hope is that a code of conduct could be crafted with defensive measures to at least mitigate such problems, but that is probably hopeless in the face of bad actors.

> I would be interested in seeing these.

I have some links bookmarked:

https://github.com/nodejs/TSC/issues/325

https://archive.is/XcxSf

https://archive.is/YnGGz

https://archive.is/EJmJ7

That directly followed a failed attempt at enforcement that led to a fork:

https://web.archive.org/web/20170821212745/https://github.co...

This article covers the whole thing:

https://theoutline.com/post/2206/the-node-js-code-of-conduct...

An HN discussion:

https://news.ycombinator.com/item?id=15101668

> My naive hope is that a code of conduct could be crafted with defensive measures to at least mitigate such problems

The problem isn't the letter of the law, it's that the rules don't seem to apply to certain groups of people.

Re: Helping newcomers become contributors to open projects

#62
projects should not just say that they welcome new members: they should make a proactive effort to foster positive feelings in them. One way to do this is to post a welcome message on the project’s social media pages, Slack channels, forums, or email lists. Projects might also consider maintaining a dedicated "Welcome" channel or list, where a project lead or community manager writes a short post asking newcomers to introduce themselves.

I have not found it especially helpful to have a place set aside for the express purpose of letting newcomers introduce themselves and be officially welcomed to the community. This is an extremely shallow way to do this and I don't believe it's especially effective.

(I am not an open source maintainer. I do have moderating experience.)

It's generally better to "greet people at the door." In other words, the first time a new person says something, engage them. Be polite. Be respectful. Try to keep things on topic.

If they ask a question and it doesn't get a reply within X period of time, reply to it even if you don't know the answer. Don't make them feel ignored. Replying may bump it and get it answered. Even if it doesn't, they won't be afraid to keep talking.

"The silent treatment" should be used to intentionally starve problem behavior of attention (a la Don't feed the trolls). It shouldn't be seen as a valid response to a newcomer just because you don't know what say to them.

Keep knowledge up to date and findable

You can't document everything and newcomers don't necessarily read your extensive documentation.

I would focus on making sure some key stuff is covered and occasionally reread it to make sure it doesn't say anything egregiously wrong and misleading because things have changed. Minimal, accurate documentation is more useful than extensive inaccurate documentation.

They recommend that you have and enforce a code of conduct, then admit Research on these is still in its infancy.

If you are in an influential position, get with the person in the mirror regularly. If you see a problem behavior cropping up regularly, wonder what you are doing that is inadvertently causing that to somehow be acceptable and make sense to people.

Watch your sense of humor. It is often a source of unintended consequences.

Codes of Conduct, like Rules of Law, basically are their most useful when something has gone very, very wrong and a third party needs to arbitrate. They mostly aren't that useful for fostering good behavior. You mostly foster good behavior by how you comport yourself.

Too much focus on Codes of Conduct can be counterproductive and can signal "We are so badly behaved, we need it constantly explained to us what good behavior is supposed to look like."

It's good to have some guidelines and best practices, but be careful that you don't spend an excess of time overly focused on nominally rooting out some particular evil.

Think of it this way:

If you feel you need to state up front in your dating profile "No Rapists!!!!" then maybe that dating site should be skipped altogether. It's fine to do a little polite hand slapping occasionally to establish where to more clearly draw that line, but you shouldn't need to aggressively focus on things that should "go without saying."

Ironically, a genuinely healthy and well mannered environment has a certain tolerance for interpersonal friction. It needs to be a place where hand slapping can occur without turning into major drama.

An environment where everyone needs to walk on eggshells is not a polite environment. It's a terrifying and very unhealthy environment.

Re: Helping newcomers become contributors to open projects

#63

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…

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

This is the cause of many people giving up contributing to software projects. Clearly pointing to specific versions, distributions used, or (if willing to move one step ahead) prepping a VM Image or container with all the dependencies set is really helpful

Re: Helping newcomers become contributors to open projects

#64

offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while d…

I'm a writer who has asked similar questions in the past. I don't recall finding any slam dunk "This is how writers get involved!" solutions.

I have had some luck with suggesting better wording for projects submitted via Show HN. Some of that has been adopted and I've been sincerely thanked a few times. I've documented a little of that as part of a kind of portfolio.

I haven't tried super hard to pursue this. If you want to get involved in earnest, you need a little luck (plus some quiet, patient persistence). You should look for situations with an extensive need for writing help plus good personal rapport between you and one or more key people.

That's basically how you get involved in something when they aren't really looking for you. You identify a need you can meet, then try to establish those personal connections that aren't overly personal, but are personable enough where you can have good and useful conversations about stuff not currently on their radar without them giving you the cold shoulder because they see you as a waste of time.

Re: Helping newcomers become contributors to open projects

#65

offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while d…

This is a similar issue for designers. Lots of open source projects desperately need UX help (or could at least benefit from a nicer website) but very few of them extend any kind of welcome to the people that could help.

Re: Helping newcomers become contributors to open projects

#66
After being a subscriber to hn for the last decade, a post I'm affected enough by to create an account.

After wanting to contribute to open source projects for my entire career (I've previously worked at FAANGs and am a technical lead now), I've had 0% success in attaining this goal. Here's been my experience:

  -reached out to the Apache Tomcat team -> silence

  -joined Linux Kernel Newbies -> code is such terrible quality I might unlearn somethings

  -joined LLVM's mailing list -> lack of issues for beginners
I'm now looking to contributing to Spring Boot, Apache Cassandra, or Hadoop, but I didn't imagine it would be difficult to contribute to open source.

Re: Helping newcomers become contributors to open projects

#67

offtopic-ish but maybe somebody sees it: can anyone recommend places around the web to look for open source projects where I can help out as a writer? I write and edit professionally but am bad at code beyond some 101-level Java, and beyond that the usual html/css. I've always appreciated well-written help docs, manuals, FAQs, etc of any kind and would like to help out if I can and hopefully learn some things while d…

At FreeSewing, we would welcome you with open arms: https://github.com/freesewing/

Documentation is one of the most important things for the well-being of a project. Your contributions would be extremely valuable. So if you think what we do is worthwhile, please get in touch.

Full disclosure: I am the maintainer

Re: Helping newcomers become contributors to open projects

#68
post #49

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.

Which is still not a justification for making public accusations of illegal, perhaps criminal behavior on a project issue tracker or mailing list.

> Are they?

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

Re: Helping newcomers become contributors to open projects

#69

Confession: I've been a professional software developer for 24 years, and I've never been able to get my foot in the door for an open-source project (other than my own open-sourced license stuff). I think part of it is because the projects that are most worthwhile have no shortage of participants, so they don't need to extend any welcome to newcomers; and the projects that need participants often end up that way beca…

I've had a career about half of yours (where does the time go?) and this has been my experience as well. I would have loved to contribute to at least half a dozen projects in the last couple of years.

Re: Helping newcomers become contributors to open projects

#70

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…

so true.
Post reply on HN