[Sugar-devel] GSoC proposal changes

[James Cameron]

On Sat, Mar 30, 2019 at 03:52:08PM +0530, aniket mathur wrote:
> James wrote:
> >  "your timeline has a queue of components in a set order; it is
> > more likely you'll need to work on all components at once; that's
> > how it seems to work for me."
> 
> Suggestion given by @quozl for my timeline. Should I make my
> timeline as a certain percent of work done on all components
> together before phase evaluations? Need suggestions. Link to my
> proposal.
> https://docs.google.com/document/d/1uGwlzPMUG7Z_ZJEloORGc8tEiXs72qLurO-R7GlomsU

Thanks for asking.

No, I don't think a certain percentage could work; how would we
measure?

Consider the varying purposes of a timeline;

1.  so that we can see the weeks you'll be working,

2.  so that you'll have something that can be assessed during
evaluations, something that is working and 90% done by midterm,

3.  so that we can see you've thought about the size of the work,

4.  so that we can see if you have iterated into estimates of
subtasks,

Also, the timeline is not going to be kept as-is; you and your mentors
will adjust the timeline during the project.  When a timeline is not
adjusted, that usually means mentors and student are not paying
attention to the timeline.  In my experience an unadjusted timeline is
a reliable sign of impending failure.

Implementation mistakes of working with timelines that I've seen are;

- stopping work when you've no idea how to proceed, and you have to
  ask questions of mentors, or other project teams; you must have
  something else to work on while you wait for an answer,

- not working on next week's tasks when something takes a shorter time
  than expected; the spare time should be used,

- moving on to a different task when a task is not finished; can be
  fatal to a project when there are task dependencies.

See also Google Summer of Code - Student Guide - Writing a proposal,
https://google.github.io/gsocguides/student/writing-a-proposal which
does not talk about timelines.  There's an early paragraph about time
management.

Now, your timeline seems to follow the "Project Task Checklist" in the
idea.  We put that checklist there because those tasks have a somewhat
forward dependency.  But there are some traps in using that checklist
as a timeline.  Many of those tasks may stall for one reason or
another outside your control.  Some of them are ill-defined; for
example the port to TelepathyGLib is needed eventually for all
activities, but only the Fructose set are to be ported by your
project, so that suggests only the Fructose set and the Toolkit should
be ported to TelepathyGLib.

So a good timeline will depend on planning of the tasks, and that may
in turn depend on good estimates.  An invaluable input to estimating
software effort is to try to use the software or cobble together a
minimum viable prototype.  I know what sort of traps you would hit if
you tried that.

-- 
James Cameron
http://quozl.netrek.org/