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/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel