[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: My Summer of Code Application draft
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-03-27 19:25:45
Message-ID: 200803272025.45417.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 26 March 2008, Keith Bowes wrote:
> The Wiki says that I should write a draft and get it reviewed before
> submitting it.  I guess this list is the best way to do it.  The best
> way isn't listed.

Submitting a draft is meant to help you get rid of any misunderstandings or 
weaknesses before the mentors really start to rate them.

It is not required and if you don't get any specific feedback please apply 
with whatever version you are comfortable with.

> I'm sorry about this being in midweek. 

No problem.

> I've had a terrible time 
> getting the compiled programs to run.  I get these undefined symbols
> errors.  I finally figured it out, that it was using the included
> version of Qt instead of the Qt beta required by the SVN trunk
> (LD_LIBRARY_PATH in /etc/profile wasn't being set; go figure!), so I'm
> ready to apply and work on it now.

You wouldn't have needed that at this point of time, there is plenty of time 
between the selection period and the official start, i.e. the community 
bonding phase.

> I guess that's all I have to say.  I know you're supposed to include a
> timeline, but to tell you the truth, I have no clue.  Based on
> previous experience, estimates are just dead wrong.  Seemingly small
> things can take a long time and seemingly big things can turn out to
> be easy.  So, I really don't know.

TImeline and even goals can be adjusted, especially if unexpected difficulties 
are encountered.
KDE's goals are to get useful and maintainable code and optimally a new long 
term contributor. There is no point in doing quick and dirty hacks just to 
meet the original goals on time.

However, the initial timeline will be used by mentors to decide whether a 
student has had a good look at the problem and identified the main tasks 
correctly.
As a suggestion: once you have identified the subtasks and their dependencies, 
consider reordering independent tasks such that there is something 
sufficiently complete for the mid term review if possible (doens't make sense 
to rearrange stuff if another ordering is way more efficient)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]