What is this for?

[afeld]

This org came out of tweet from @trek on the Twitters:

https://twitter.com/trek/status/555385216651776001

What do we want this org to be?

/cc @sindresorhus

[sindresorhus]

Good idea! I've been wanting to do something around making it easier for people to get started in OSS and/or contribute to new projects.

One misconception I feel we have today is that you can mostly only contribute code. That couldn't be more wrong. Maybe this place could outline various ways to contribute based on different skills.

What are your thoughts around this org?

[trek]

👍 on contribution don't just need to be code.

[afeld]

Existing things around this space (and the links that stem out from them):

• https://github.com/h5bp/lazyweb-requests
• http://hackerhours.org/resources#getting-involved-in-open-source
• add maintainer guidelines 18F/open-source-program#57
• https://github.com/codeforamerica/project-ideas

My big questions are:

• Is this a place to post project ideas, or general guidelines?
• Is this oriented to new projects, or existing projects as well?
• Is the target audience:
  • Just people new to OSS, or anyone?
  • Project maintainers, or potential contributors?

As one example, I remember hearing that the MongoDB issue tracker has a label neweng, meaning issues that are small and a good entry point for new contributors to the project.

[trek]

One major reason I think the "help wanted" label idea hasn't panned out is just knowing someone wants help is rarely actionable.

I've seen this play out in 2 ways

• Contributors still don't know how to help so shy away.
• Contributors help, but in some way that doesn't make any sense (once you know the project), so the PR is rejected. Contributors feel bad. Owners feel frustrated.

Owner/Collaborators forget they keep a lot of implicit information about a project in their head. For them there are a few obvious paths forward, but to someone new, a "small task" actually looks like this:

1. Read entire project and internalize all its style and unspoken organization
2. Issue "small" PR

Documenting a "project's structure" to help new people sounds like a good idea, but ossifies really quickly as projects naturally change over time.

I've been playing with first investigating an issue until I understand a way forward and then listing what I think the smaller stages a successful PR would be: trek/beautiful-open#256, https://github.com/trek/ember-api/issues/15

At this point I understand the problem enough to offer guidance to a new contributor. The instinct I have to fight is the feeling that "well, I can just do it myself now!" Fantastic for short term velocity, but long-term less so.

As they say

If you want to go quickly, go alone. If you want to go far, go together.

[FrancescaK]

A good resource is the Community Kit I created while I was at MongoDB:

https://github.com/FrancescaK/MongoDB_Community_Kit

It outlines a number of ways someone can be involved in FOSS. One of the best things people can do is contribute via a 'neweng' label, as Aidan pointed out, but offering support on forums or IRC and contributing to documentation is also equally valuable. It's not all about contributing code. Contributing your skills in any capacity is a very powerful thing in FOSS.

[botimer]

I support all of these goals and steps. This is something that has been an important challenge to me over the last ten years of open source engagement. Working hands-on with a volunteer is great but isn't always practical.

I think the middle ground approach of spiking far enough to be reasonably confident in an approach, yet leaving the proof to the reader can be an effective one. It is much like designing a good exercise or workshop for general teaching. Note that the trade-off is similar: some up-front investment by someone more experienced to illuminate an on-ramp does not solve an immediate problem but gives an opportunity for someone else to step in and solve it and similar problems. This is especially important in community building, where this exchange is not just downstream learning, but social as well.

My choice of terms above is not arbitrary. I tend to think of this with the same analogies as I use with specific software problems. If I build a good tool for moving boxes around (a ramp, maybe), it gives me some mechanical advantage. If I build a good script for generating a manifest and compressing files in a package, it gives me leverage on that type of problem. If I build a good on-ramp for extending a software community, it gives me a way to include more people to help solve more problems while giving those people a way to get there without some generational jump in their own expertise.

Any of this tool building is a short-term investment with the goal of improving the long-term condition of the project. In a big or interesting enough project, building good, simple tools usually repays the investment pretty quickly.

[ef4]

Read entire project and internalize all its style and unspoken organization

Reading is definitely one of the key gaps between beginners and experienced people. I don't think it's quite as extreme as needing to read an entire project, but the sentiment is correct: veterans can read and navigate unfamiliar codebases quickly (often zooming in on the parts that are relevant without having to read the whole thing), so to them the reading is not a big deal. Newbies lack the practice and cultural exposure, so to them it's much harder.

If this project actually starts generating commits, it would become a valuable source of practical exercises. Each issue is a problem statement plus a real codebase. Each solved issue also includes an accepted answer. Students can gain practical reading experience just by going through all the solved issues and reading them well enough to understand what's going on.

Read enough small successful PRs against a project and pretty soon it stops being magic, you absorb the patterns, and you gain the confidence to submit your own.

[daguar]

For people relatively new to programming/open source, one thing that has jumped to my mind as super valuable and approachable is making the README work for you. For example:

• Improve the installation/local setup instructions so that they're approachable to someone with little knowledge of the language/framework
• Add examples of usage
• Make sure the overall "README experience" makes sense — were all your questions answered? did you know how to find out more? if not, PR away!

[vanhalt]

+1 @daguar

My idea would be to promote a "Project Starter Kit" for every project containing:

• Dependencies statement:
  I have failed so many times setting up a project because I don't know how to
  find, install, compile, require, link, insert, import, export
  a dependency.

• Installation/Setup detailed guide:
  This is the entry point for me, because if I can't install it... there is no
  way that I would manage myself to fix/improve something.

• Easy Area / Neweng Area:
  Sometimes for me reading the "main" script of the project is really far away from
  being the easiest way to understand or get started in the project, actually, is the worst
  entry point ever. So in my opinion telling beginners where is the "Easy Area"
  to start with, would be a great win. Sometimes I am not looking a project
  because I want to collaborate in the first place, but just because I liked it.
  Later I realise that I would like to do something... but it seems that I just
  don't know where to start.

• We did it!:
  Collaborators guides sometimes just include how to do the PR dance... and nothing
  more. I have seen that looking at closed/merged issues/comments/PRs is good to understand
  how the people in the project think, how they work, how many people actually collaborates
  and work together to help you fixing an issue and the approach that they took solving it.
  Including past successful collaborators work can encourage new comers to see what is really
  happening in the project and maybe wipe out the fear that the issue that you found interesting
  to contribute with is not as hard as its name states.

• ** People Contact **:
  Yes... yes and yes. In my opinion having the chance to get in touch with key people or actual
  collaborators from the very moment when you show intentions to work with then despite your
  knowledge or skills, is vital for new people to get on board. If any of the previous items is missing
  this last one can make it irrelevant, in my opinion.

  :)

[frozzare]

I think is great to start a org with good documents about how to get started to contribute to projects. 👍

[kytrinyx]

Another resource that has been useful for me as I try to make my project more accessible is OpenHatch: http://campus.openhatch.org/projects.html, which helps guide projects in developing a good onboarding experience for new contributors.

[ahmadnassri]

adding TODO Group can't seem to find peeps behind it, but seems very well aligned with this initiative.