6

I'm a scientist that's a self-taught programmer. I've worked on several open source projects before, but the developers gave me a better idea on what to work on. This guy just sent me a link to github and told me to go for it. There's no README and most of the bugs are front-end (which I don't have much experience with) and checked out to him anyway.

This looks really exciting, and I'm happy to help out, but I'm not sure where to start. Looking around at the files, there's lots of things with 'initial hello world' as the description and several files labelled .gitignore. I figure I could probably do some housekeeping but I'm not sure how to go about it, in terms of usefulness and efficiency. Also, documentation - there isn't any.

To be frank, this would look awesome on a CV, so I don't want to just write it off.

Improve this question
3
  • Care to add a link to the project (perhaps in a comment so it doesn't matter if it goes stale)?. It might be easier to give you some pointers if we can look at it and see where it needs work. That might also help make this a little less 'broad' and stave off the close votes.
    – kdopen
    Commented Aug 24, 2015 at 18:27
  • 2
    I'm voting to close this as too broad. If a good answer could easily be a blog post or a book, it's too broad. If you provided some details about the project you're interested in, this would be s much better question.
    – RubberDuck
    Commented Aug 24, 2015 at 23:46
  • Two posts that I found helpful: - A general post from Andre Arko with three questions you should answer for yourself before diving into an open source project: cloudcity.io/blog/2017/01/25/… - A 15 minute a day plan from Andre Arko on how to go from newbie to core contributor on an open source project: andre.arko.net/2016/11/12/how-to-contribute-to-open-source
    – edenhensley
    Commented Feb 8, 2017 at 0:39

3 Answers 3

Reset to default
7

Just do it!

Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.

If the project is using Git, make sure you adhere to best practices with regards to branching and pull requests:

  • Create a clone of their repository (in GitHub this is referred to as a "fork")
  • Create a branch in your clone for each bug/feature/refactor that you work on.
  • Don't merge it into master, send a pull request from your branch to the original project developer.
  • If he/she doesn't like something, you'll be told to improve it.
  • Make those changes in your branch.
  • He/She will merge your changes into the master branch.
  • You pull their merge into your clone, and now it's part of your master.

The above process is especially important when you're working with unfamiliar code, so that any mistakes can easily be fixed.

Trust me, the project maintainer will be happy to receive any (good quality) work you send their way. Even if it's something they intended to do, they haven't done it yet so you can jump ahead.

If you're only comfortable working on documentation, then do you could do that. But if something outside your comfort zone is more important, then that's a great opportunity to learn something new and (as is your primary motivation) it will be a big step up on your CV.

Worst case scenario is you do some terrible work and the project maintainer tells you why it's terrible, so you can fix it up. You've got yourself a golden opportunity here to learn from someone more experienced.

Improve this answer
4

Attitudes may vary from project to project, but on most projects I participated in "housekeeping" or cleanup patches were always welcome. I'd create a cleanup branch and just start creating patches that clean up those "initial hello world" descriptions. Once you've got your feet wet and have a couple of those under your belt, you could start on more substantial efforts, like writing the documentation.

With regard to the issue tracking system, again, it varies from project to project. On the projects I usually work on we use issue tracking to report actual issues, and accept code improvements without a tracker. Some projects require every patch to be associated with an issue tracker, so you may have to report a "remove initial hello world descriptions" issue and assign it to yourself. If you're unsure about the particular's project etiquette, just ask.

Improve this answer
1
  • Also, check if there is a public issue tracker - it may have some issues tagged as "novice-friendly". If not, see what's there, start to look at new issues and updates, e.g. check if the issue is reproducible or if the fix works. If there is a project mailing list, I'd also suggest to subscribe.
    – Olexandr Konovalov
    Commented Aug 24, 2015 at 20:36
2

In the absence of a link to the project, all suggestions will be vague. However, there are a number of things you need to do to get started, and they often offer opportunities to contribute.

Before you can make any changes, you need to be comfortable that you have some understanding of the codebase and how it's structured. So pull down the code and examine it in your favorite editor. Get a feel for which source files depend on which (the basic structure).

Somewhere in there you will usually find a small source file that has a collection of utility or helper routines used by everything else. This represents the bottom of the call tree, so you should be able to fully understand it in isolation.

Start with that file, and study the code one function at a time. When you really understand the function, document it. Add substantive, explanatory, comments. Provide examples of use for the helper functions. Basically fully flesh out all the things the original author left unsaid because they knew what they were typing at the time.

When you're done with the entire file, create a pull request and see what the project owner thinks. If it's accepted, move the the next lowest module (which probably uses the one you just documented) and start again.

This has the following big advantages

  • It gives you a really strong understanding of the code, which is essential to making later substantive changes.
  • It makes no functional change to the existing code (i.e. you can't break anything)
  • It gives you a way to build a relationship with the project owner
  • It improves the overall quality of the code-base.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.