Discovering Open Source: up-for-grabs.net

As open source gains more and more traction in the .NET space everywhere, a common question that keeps coming up is “How can I help?” To answer that question, a growing number of projects are tagging specific bugs and feature requests as good places for a new contributor to start. The tag to identify such tasks has not been standardized, but you should be able to figure it out…if you go and look.

To make discovering such projects easier, I’ve whipped together a site (page) hosted on GitHub: Up For Grabs. I’ve seeded the site with a few project links, but I hope over time we can grow this into a resource for newcomers to the open source scene to discover projects and get guidance on how to jump in!

Thanks to Scott for the nudge to get this started.

Update: Though the genesis of this site was a discussion on challenges facing the .NET open source community, I’ve come to realize that barriers to entry for new contributors exist across the entire open source ecosystem. So, if you run (or contribute to) any open source project that 1) has bugs and feature requests that you would consider “up for grabs” for new contributors, and 2) are interested in mentoring new contributors on their way to becoming great contributors, please add your project to the list.

Related Articles:

About Keith Dahlby

I'm a .NET developer, Git enthusiast and language geek from Cedar Rapids, IA. I work as a software guru at J&P Cycles and studied Human-Computer Interaction at Iowa State University.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Terry A Davis

    I wrote my own compiler. Github and this site have no use for my users. I do not have networking, my files are kept in a compressed format, my language syntax is unique and I like to do GREP with string replace all day long.

  • Henri

    Is there any way of knowing how responsive these projects are to pull requests? Nothing is more frustrating than submitting a request and waiting months for a response only for it to be superceded by a commit by someone in the core developers.

    I’d really love it if there were stats on how many ‘up for grabs’ pulls are merged and long it takes for that to happen.

    • http://www.deavlead.se/ Mattias Karlsson

      Commit log is one way to se how many external contributors an project have.
      Something I often miss is a short description of what authors expect from pull requests, general guidelines like code style, folder layout, documentation etc.
      Many project have a close circle of people contributing, with days/month/years of implicit undocumented knowledge.
      Perhaps something like “pullrequest.md” that is displayed when pull request are created, only a few lines that i.e. could link to more detail info on wiki or homepage.
      Also don’t be discouraged if your pull request isn’t merged minutes after created, easy to be, often you have put hours into some code, but 1st they don’t know that, also if it’s a substantial request it takes time to review, here a good description, comments etc. is very helpful.
      But to not get too invested/disappointed start with a small change like a typo/method/etc. if it gets merged quickly at least you know the projects alive.
      And there’s always the fork option, often I only have to think fork for my pull requests to get some response:)

      • http://solutionizing.net/ Keith Dahlby

        Many projects have a CONTRIBUTING file that documents their expectations, and GitHub even calls this out when creating a new issue/PR: https://github.com/blog/1184-contributing-guidelines.

        If you’re going to dive into an existing bug, definitely make a note on that issue first expressing your intent, asking for guidance (any dragons I should be aware of?), etc. If you don’t get a response, it may not be worth your time (unless you plan to maintain a fork). But also understand that maintainers are often busy, either with other projects or this “life” thing I hear about so often.

        Ultimately it’s a two-way interaction – one of my goals for the Up For Grabs project is to make that relationship work better in both directions.

  • gleb Chermennov

    Submitted a PR to add Fluent NHibernate to the list

  • georgexcollins

    This sounds like something that could be automated – say by having something crawl Github looking for projects with issues labelled ‘UpForGrabs’, ‘EasyFix’ etc.