Note: I also sent this out yesterday, but it appears to have been spamblocked. Therefore, I am resending it. Please accept my apologies if you get more than one copy of this e-mail!
Hi -- As promised, here is a list tips and suggestions I'd like to see used by all GSoC projects running under the gEDA umbrella. The idea is to promote transparency and community involvement in the GSoC projects, as well as to create a framework which will help the student bring his project to a successful conclusion. 1. Please use the geda-dev (or icarus-devel or gnucap-devel) mailing list for mentor/student communication about the project (i.e. questions, suggestions, etc.). There are several compelling reasons for this: -- It provides some visibility for everybody interested in gEDA into how the project is going. -- In some situations, you may get a faster answer from somebody on the list than your mentor (who might be momentarily away from the computer). -- The gEDA Project is lucky to have a number of very high level developers participating in it. Students, you can learn a lot from these guys! Posting questions on the list provides you an opportunity to interact with them. Note that using the developer mailing list for project communication may lead to some confusion, since lots of gEDA hackers have differing opinions about how things should be done, and they are not hesitant about expressing their opinions! This is a normal part of any open-source project. Students should use their own judgement when deciding what suggestions to accept, and which to ignore. Ultimately, the mentor is the boss, so in the event of confusion, do what your mentor says. Of course, sensitive or personal communication should be done privately. I put a prefix "[private e-mail]" on the subject line of private e-mails so the recipient immediately knows that the message is private, and was not sent to the list. 2. Everybody hates writing specs, and I'm not going to say we should do that here. However, I do think that each mentor and student should find some written method to flesh out the details of each proposal. In particular, for projects in which the user interface plays an important part, the student and mentor should write down and agree upon a bunch of use-cases. Mentors can decide what level of detail is enough. 3. Mentors should require at least one CVS checkin per week (or other agreed-upon period). This helps ensure that regular progress is being made on the project. It also ensures that the student isn't getting way off track. 4. Mentors may want to set up a separate branch in cvs/svn/git for the student to work out of. Merging of the student's branch into the trunk is a task for mentor and student to work out amongst themselves. 5. Students are encouraged to create a blog where they post their ideas & accomplishments. A blog is a great tool to tell others what you have accomplished, and what you intend to do! 6. In lieu of a blog, mentors should at least ask for a weekly list of goals accomplished from the student. The list doesn't have to be exhaustive. It should just take 10 min to put together, and summarize the big-picture accomplishments made. Mentors, please feel free to add other ideas to this list. Cheers, Stuart _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user