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]qu...@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@lists.sugarlabs.org > [6]http://lists.sugarlabs.org/listinfo/sugar-devel > > References: > > [1] mailto:qu...@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@lists.sugarlabs.org > [6] http://lists.sugarlabs.org/listinfo/sugar-devel -- James Cameron http://quozl.netrek.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel