[Sugar-devel] GSoC proposal changes

[James Cameron]

Okay, thanks.

I'm not requiring any changes.  You're welcome to change it if you
like.

On Mon, Apr 01, 2019 at 02:07:42PM +0530, ANIKET MATHUR wrote:
> Thanks for answering and guiding.
> I am aware of the obstacles that I might face, also I am aware of
> the flexibility of the timeline that might change as the work
> proceeds.  My timeline is just an approximate idea of how long it
> might take to perform tasks in chronological order. To determine
> that I went through the previous work done on each task and the work
> remaining to be done, to make out approximate figures. I accept that
> the real difficulties are faced only once you start working, which
> might entirely alter my timeline. 
> 
> Also, I consider it as a possibility and accept it that I might have
> to work on things not mentioned in my proposal during the program,
> like porting other activities to TelepathyGlib, or other
> contributions to the source code essential at that time. I know this
> is how things work, rather than sticking to a timeline. 
> 
> Still, I am not clear about the changes that I have to make, because
> there is no such thing as a strict timeline. So do I have to keep my
> timeline the same and let my mentors guide me through the work that
> I have to do during the program itself? 
> 
> On Mon, Apr 1, 2019 at 12:50 PM James Cameron <[1]quozl at laptop.org> wrote:
> 
>     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.
>     > [2]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,
>     [3]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
>     [4]http://quozl.netrek.org/
>     _______________________________________________
>     Sugar-devel mailing list
>     [5]Sugar-devel at lists.sugarlabs.org
>     [6]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:quozl at laptop.org
> [2] https://docs.google.com/document/d/1uGwlzPMUG7Z_ZJEloORGc8tEiXs72qLurO-R7GlomsU
> [3] https://google.github.io/gsocguides/student/writing-a-proposal
> [4] http://quozl.netrek.org/
> [5] mailto:Sugar-devel at lists.sugarlabs.org
> [6] http://lists.sugarlabs.org/listinfo/sugar-devel

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