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 months. 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. Again, this is peer review, not official guidance. And to be clear, I myself am not participating in GSoD; I thought I might but chose instead to simply volunteer.
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 discussion. 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.
participants (1)
-
Ben Nathanson