Granularity of proposals
Peter Danenberg
maximum) with our proposals?
I'd like to avoid a brittle, over-engineered proposal that has to be
scrapped; at the same time, I wonder if it's legitimate to submit a
rough but thorough proposal that we could incrementally refine under
our mentor's care.
Arun Raghavan
This is really a very subjective question, so I suggest you use your
own judgment here. The most sensible thing, IMO, would be to make a
draft that you think hits the right balance, and then let your mentor
review it once and let you know what (s)he thinks of it.
The proposal is not something that is set in stone once you start --
if things need changing while you're working that's fine. The
application is supposed to let the mentor that you understand the
problem and (to a reasonable extent) how to solve it, and that you
will be able to do so in the time available.
Cheers,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
David Anderson
mentors before submitting your application, and incrementally refining
it to their liking. I don't think that there is any universal sweet
spot.
Speaking as a mentor, I'd at least like to see in a proposal some
understanding of the challenges and steps involved in accomplishing
your task. I want to be sure that you understand what it is you're
signing up for, in terms of work. Saying that you're confident you can
accomplish the task means nothing if you haven't understood what the
task involves :-).
To that effect, one of the things that works best for me is a rough
timeline. Show me the big steps of your project (granularity of 1-3
weeks), and how much time you intend to spend on each. That gives us a
clear impression of whether you know in which general direction you
should be going, even if the details are still fuzzy. It also tells us
how much time you estimate each component will take, which helps us
figure out if you can actually make it work in time.
A little preliminary design work is also welcome, if you're designing
a new feature, since it shows that you've already dug into the code
and design of the project a little bit. For instance, if you were
adding a feature to a program, you could say "It seems that part of
the functionality of the frobnicator is already present in the pilfer
grommit subsystem. I propose to first extract that functionality into
an internal library that can be reused by both the frobnicator and the
pilfer grommit. Then, I will work on expanding that library's
functionality and API to meet the needs of the frobnicator, before
starting on the UI code." It shows that you've poked around a bit, and
have a rough plan of where you want to go, even if you don't yet have
a specific API in mind for the internal library, or for the UI you
plan to build (though it might be a good idea to have a few key ideas
for UI, if your task requires one).
Keep in mind this is all my own personal sweet spot, and the advice to
get in touch with your mentors as early as possible to iteratively
refine your proposal is still the best advice I can offer in general.
Hope this helps,
- Dave
Greg Lund-Chaix - OSUOSL
<snip>
Um, yeah, What he said. :-)
We definitely would like to talk a bit with our applicants before
getting a formal application. We are happy to assist with formulating
a proposal - it helps us better understand what you as the applicant
want to do and we get a chance to get to know you. The more we know
about you and your proposal, the more likely we are to score it
highly.
-Greg
--
Greg Lund-Chaix
OSU Open Source Lab
gch...@osuosl.org ~ http://osuosl.org