<div dir="ltr">Thanks for answering and guiding.<div>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.</div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 1, 2019 at 12:50 PM James Cameron <<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Mar 30, 2019 at 03:52:08PM +0530, aniket mathur wrote:<br>
> James wrote:<br>
> >  "your timeline has a queue of components in a set order; it is<br>
> > more likely you'll need to work on all components at once; that's<br>
> > how it seems to work for me."<br>
> <br>
> Suggestion given by @quozl for my timeline. Should I make my<br>
> timeline as a certain percent of work done on all components<br>
> together before phase evaluations? Need suggestions. Link to my<br>
> proposal.<br>
> <a href="https://docs.google.com/document/d/1uGwlzPMUG7Z_ZJEloORGc8tEiXs72qLurO-R7GlomsU" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1uGwlzPMUG7Z_ZJEloORGc8tEiXs72qLurO-R7GlomsU</a><br>
<br>
Thanks for asking.<br>
<br>
No, I don't think a certain percentage could work; how would we<br>
measure?<br>
<br>
Consider the varying purposes of a timeline;<br>
<br>
1.  so that we can see the weeks you'll be working,<br>
<br>
2.  so that you'll have something that can be assessed during<br>
evaluations, something that is working and 90% done by midterm,<br>
<br>
3.  so that we can see you've thought about the size of the work,<br>
<br>
4.  so that we can see if you have iterated into estimates of<br>
subtasks,<br>
<br>
Also, the timeline is not going to be kept as-is; you and your mentors<br>
will adjust the timeline during the project.  When a timeline is not<br>
adjusted, that usually means mentors and student are not paying<br>
attention to the timeline.  In my experience an unadjusted timeline is<br>
a reliable sign of impending failure.<br>
<br>
Implementation mistakes of working with timelines that I've seen are;<br>
<br>
- stopping work when you've no idea how to proceed, and you have to<br>
  ask questions of mentors, or other project teams; you must have<br>
  something else to work on while you wait for an answer,<br>
<br>
- not working on next week's tasks when something takes a shorter time<br>
  than expected; the spare time should be used,<br>
<br>
- moving on to a different task when a task is not finished; can be<br>
  fatal to a project when there are task dependencies.<br>
<br>
See also Google Summer of Code - Student Guide - Writing a proposal,<br>
<a href="https://google.github.io/gsocguides/student/writing-a-proposal" rel="noreferrer" target="_blank">https://google.github.io/gsocguides/student/writing-a-proposal</a> which<br>
does not talk about timelines.  There's an early paragraph about time<br>
management.<br>
<br>
Now, your timeline seems to follow the "Project Task Checklist" in the<br>
idea.  We put that checklist there because those tasks have a somewhat<br>
forward dependency.  But there are some traps in using that checklist<br>
as a timeline.  Many of those tasks may stall for one reason or<br>
another outside your control.  Some of them are ill-defined; for<br>
example the port to TelepathyGLib is needed eventually for all<br>
activities, but only the Fructose set are to be ported by your<br>
project, so that suggests only the Fructose set and the Toolkit should<br>
be ported to TelepathyGLib.<br>
<br>
So a good timeline will depend on planning of the tasks, and that may<br>
in turn depend on good estimates.  An invaluable input to estimating<br>
software effort is to try to use the software or cobble together a<br>
minimum viable prototype.  I know what sort of traps you would hit if<br>
you tried that.<br>
<br>
-- <br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote></div>