Guidelines

http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf

http://shakthimaan.com/downloads/glv/presentations/communication-guidelines.pdf

http://shakthimaan.com/downloads/glv/presentations/i-want-2-do-project-tell-me-wat-2-do.pdf

Before you start

  • When interested in doing a project, please mention your:
    • Skills (languages)
    • Domain of interest (application/system/databases/web/embedded development etc.)
    • Time frame for the project
    • Write something about your interests, about yourself when you are interested in a project. Don't make orders like these:

"i like to be a project member in your team. please send me the details."

  • Mentors can only tell you what to do. Mentors cannot write abstracts/code/project documentation/presentation for you.
  • If you're intention is to do a project just for the sake of submitting a final year project, then a FOSS project is not the right project for you.
  • Double check your spelling, before you write to the mentor.
  • If your English is bad, get some help. All that Peter jokes that you played with others in college will not help you in your career. Welcome to the real world! Get serious, get help with your English.
  • Always have a one-to-one chat discussion with the mentor, during weekends.
  • Mentors who work are busy during weekdays, so discuss only during weekends.
  • Never _ever_ do last minute work.
  • Candidates should be interviewed by mentors for skill-sets, ability to correspond/converse, before being assigned the project.
  • Because mentors working in the industry work on tight schedules, expect the FOSS project timeframe to be tight. The candidates can complete the project early with the mentor, compared to the long timeframes given by colleges.
  • It is better to give a small assignment to the students for a week or 10 days, and see how they follow instructions and get the work done, before you assign any further tasks in the project with them.

During the project…

  • You are going through a learning curve, and you are bound to get stuck. You will hit road blocks. But, you should be able to seek help from the FOSS community, websites, search engines, IRC etc. and get things done. The help is already there, and you need to seek it. This is education.
  • Always Google for answers, check in mailing lists, ask in IRC, before you post a question to the mentor. Most of your questions are already answered somewhere on the Internet. You need to go and find it.
  • When you get stuck in the project work, always give as much info as possible. Give detailed info such as what you did, what was the output that you saw. Provide screenshots, logs of what happened, always. You need something for debugging.
  • Asians, in general, are poor in their English. So, by trying to explain it in your own words, you only make it worse! So, if you get an error message, instead of trying to explain the error, always post the error messages. It really helps that way to debug from the code, rather than having to understand what you are trying to say.
  • Keep a journal of all the e-mail correspondences, notes, links you learnt during the project. It will help you in documentation.
  • Send weekly status updates to your mentor.
  • In the Industry, punctuality is very important. Not being ontime is considered very rude. If you are not able to attend the online discussion meeting, always inform the mentor, before-in-hand, so they can get on with their plans rather than keep waiting for you. Time is precious.
  • When replying to a mentor's e-mail make sure you answer all the questions the mentor has asked you. When you read English, don't read between the lines. Just read the lines.
  • When following HOWTOs, documentation, make sure you follow the instructions step-by-step. Never make assumptions and skip ahead.
  • If you didn't understand any statement, you should always ask for clarification. By being silent and not asking, mentors may assume that you have understood it. So, always feel free to have open discussions with the mentor. The more you hesitate to ask questions, the more you are at a loss.
  • When asking a question, put a question mark at the end of the sentence: "that would be great. so our parser should be to". How does anyone know if you are asking a question?
  • "what are the GNU coding styles?" Always Google around before asking questions.
  • Never ask personal questions to your mentor. Must accept and respect other peoples' privacy.
  • When sending project update e-mails, always CC to the team members. Never forget to do this, else, you will lose your trust within your own team members.
  • Never make your own decisions, especially when working in a team. Always consult with your mentor before doing anything.
  • Never make assumptions before you do anything. Always test things to make sure it works before you say anything. For example, you want to move your ADSL modem to your friends' place and come for an online meeting/discussion with your mentor, when you are not sure if the ADSL modem actually works in your friends' place! This is a risk.
  • Write small code and send it to your mentor for review. The mentor will make appropriate corrections (copyright, license, coding style etc.), and you can follow that. It is best to do it early, rather than having to complete the project with bad code and later trying to fix each and every line.
  • The tendancy of students to tag along their friends to the project is very likely. Each and everyone must be interviewed before pulling them to the team. No partiality or bias should be accepted, in any way. In the real world, and in the Industry you don't get to work on projects only with your friends.
  • Ask students to inform you well in advance of any internals, tests in college, during which time they cannot do any project work. It is better to ask students to send project updates once in every two days. Even if they couldn't do any work, they should send an update. Honesty is very important.
  • It is better to give small tasks to complete to assess the students' potential before giving any big tasks. They will sound very enthusiastic, but, they seldom know the risks of project management.
  • Students need to learn to talk like an engineer. Simply saying, "I have compilation problems", "yeah it does show that it has the file, but when I see download the file, there is no file" doesn't help anyone. You have to clearly be specific/precise in your statements and write technically - for the above you should mention file, where you downloaded etc. Learn how to write proper bug reports/e-mails:

http://testobsessed.com/wordpress/wp-content/uploads/2007/01/webr.pdf

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

http://marianne.in2p3.fr/datagrid/bugzilla/bugwritinghelp.html

  • When mentors give step-by-step guides or instructions or HOWTOs to students, they should prompt them if they have understood it or not. Give them some time to go through the instructions, and if they have any doubts they should ask before proceeding. Students are very hesitant to ask questions, and we mentors assume that they have understood our instructions. At the end of the week, they tell us that they need help and have not understood the instructions. Time is precious.
  • Don't make mentors ask for status updates. Whether you do the work or not, just send an update on what is the status of the project, once every week, say Saturday.
  • If students keep repeating their mistakes, again and again, don't waste your time. Call off the project, and move on.