11

I am a fairly novice programmer - 6 months into an internship.

I have decided to sign up to an Open Source project to learn new skills, and I have been accepted onto one. It seems the project is quite early in its life. They accept beginner programmers and I have explained that I am one.

Obviously as this is my first contribution, I don't want to annoy anybody ont he project. As such, what things do I need to be aware of? Any specific etiquette I should be aware of? Will I need any specific software? I have VS2010 which is okay for C#, but what about source control? Is that managed through the Codeplex site?

Thanks.

Darren Young
  • 2,175

2 Answers2

13

For source control, you'll just have to find out what they're using.  It'll likely be SVN, if I to guess.

As for etiquette, I'll tell you my two biggest pet peeves in my few years of "professional" programming and several years of group projects in school. I'll list them as two things, but they generally go together, as one usually causes the other.

1. Lack of communication.

  • Not knowing where someone is on their part of what they've been given when we're coming up on a deadline / milestone / etc.  This is obviously less of a big deal for you when you're working on a project like this as opposed to trying to make deadlines for your customer and/or professor, but still. It's good to know where everyone is and how they're doing.
  • Not letting someone know if you're having trouble with something you're working on. I'd rather spend a day answering 100 emails asking about the specifications, or how some language feature works, or something like that than spend a a few hours trying to track down where someone was too timid to ask and just tried without saying anything - if you're not sure, google it. If you're still not sure, ask. If I have to go back and fix your code later, it's probably still going to be shakey.

I consider both of these extremely poor form, because inevitably they leave your team out in the breeze.

2. Submitting untested, uncompleted, or known buggy code to the repository.

  • I don't even think I need to explain this one. If my class relies on your class, and you commit unfinished changes, and I update and now I can't compile...

You know what, I'm adding some emphasis on testing..

2b. Lack of thorough testing.

  • Test your code. Test every function. Test it for wild insane inputs that no reasonable human being would ever try. Test it for things a monkey at a computer with a sledgehammer wouldn't even try. Have a test plan for every function with clearly defined criteria for success, and before you commit your code, make sure you have a big green PASS in the Pass/Fail column. Nobody likes running through their part of their code and crashing because your class wasn't tested properly.
trycatch
  • 1,100
  • 1
    You have a syntax error, you should append </rant> =P , but +1. – dan_waterworth Mar 24 '11 at 15:33
  • I'll admit.. I tend to soapbox when it comes to testing and bad teamwork.. but it's something that just can't be emphasized enough. If I could get all the hours of my life back that were spent fixing something or trying to find ways to insert features that someone didn't include in the original specifications... – trycatch Mar 24 '11 at 15:55
2

Good points from all the answers. I will only add...

  1. Start with submitting documentation. Improve the documentation on how to install, and use the software, or how to use APIs. It's amazing how much value you can add here without touching the code.
  2. Add test cases to existing code. That will help you discover the intent of the existing code. It will also teach you about writing test cases.

Do these 2 things, and you will build trust, and then you will be able to do more.

BTW, this is the same method used by IBM to start contributing to the free/open-source software community. They started with documentation, testing, and setting up the Apache foundation. And now they're a big part of the FOSS community.

Jay Godse
  • 1,184