Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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.

share|improve this question

marked as duplicate by gnat, MichaelT, Kilian Foth, glenatron, Dan Pichelman Aug 8 '13 at 17:49

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
There's a great free book online called Producing Open Source Software. It answers a lot of these questions about etiquette. –  Scott Whitlock Mar 24 '11 at 15:33
add comment

2 Answers

up vote 13 down vote accepted

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.
share|improve this answer
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
add comment

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.

share|improve this answer
add comment

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