Google Summer of Docs Faq and Tutorial Proposed Structure .
Let me first say I'm a volunteer and not a member of the group that
will evaluate proposals. But I can tell you how I would choose.
A right-sized proposal is stronger than an overambitious one. I'd
scale back and pick a single target. From your listed experience, this
would be your first significant docs work. Before you can overhaul an
entire site, you need to get a feel for the pace of the work. The
review process alone guarantees the site can't be transformed in three
For argument's sake, let's say you focus on mining the internet for
how-to subjects. This is not a bad GSoD idea, because it's open-ended:
No matter how fast you write, you'll never exhaust the supply of
topics, and if work proceeds more slowly than you'd hoped, you will
have established a methodology, and any how-tos we get are more than
we have now.
Apart from appropriate scope, a proposal needs credibility. GSoD tech
writers are a coveted resource, so a project wants to be confident
that the writer they pick will deliver the goods. We're scientists and
engineers, yourself included, so we look for evidence. Put evidence in
your proposal. Assuming you pick how-tos, show the NumPy team how
thoroughly you've considered the issues, explain your methodology and
its strengths and shortcomings, and, most importantly, give samples of
how-tos you've transformed.
It's like a job interview, but harder: Not only do you have to provide
the answers, you have to anticipate the questions.
Does that mean you have to do work upfront that you might do during
GSoD? Yes. You're staking capital. The more you put on the table, the
more confident the team can be in your sincerity and skill. That said,
you do stand to lose it all if someone else is chosen. That can happen
even if you send in a proposal that everyone agrees looks good. Your
effort will not be a waste; you'll have developed skill in drafting a
competitive proposal -- useful in grant writing, calls for papers, and
next year's GSoD.
Re: Google Summer of Docs Faq and Tutorial Proposed Structure .
If you do choose how-tos, I meant to say that the first place to mine
should be this very list. For instance, a question the other day on
seeding random sequences sparked an illuminating and far-reaching
Some things that make this list a great source:
* Extracting how-tos from the mailing list does a real service --
questions on the mailing list are much less visible via Google search
than SO questions
* Answers here are likely to be deep and interesting (i.e., not
simply answers you'll find in the docs)
* We own the list; no doubts about usage rights
* We have authoritative answers from code authors
Mining only this list would not be enough for a proposal, however;
there'd need to be something else as well (e.g., mining SO/Reddit).
On the subject of mining SO, I'd suggest not only weighting by
frequency but also searching out answers that came from the community
-- e.g. Robert Kern, Warren Weckesser, Jaime Fernández del Río
(jaime), and others whom I apologize for missing. Here again we'd add
value by giving prominence (and an imprimatur) to the best answers.
NumPy-Discussion mailing list
[hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion