gEDA-user: Tips for a successful GSoC

[Stuart Brorson <sdb@xxxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user