Doc Sprint Summit v3.0 Application
For the 3rd time, Google is organizing a Doc Camp at Mountain View, the week before the mentor summit. It consists of an unconference and 2-5 Book Sprints to produce books on free software - facilitated by Adam Hyde of FLOSS Manuals.
Please address all items in RED
Is this a project or an individual application? (Project / Individual)
What is your name or the name of the group you are submitting information on behalf of?
What is the email address you'd like us to use for this application?
What is the phone number you'd like to use for this application?
Are you, or the nominated project, associated with a current or past GSoC Project? (Yes/No/Not Sure)
Projects only: Please outline in brief detail how the nominated project would benefit from attending the 2013 GSoC Doc Camp.
Currently the project is badly lacking professional and maintainable end-user documentation. We have several wiki pages, more or less updated, and we link the users to those based on their questions. But regularly, people are asking for something more formal and structured and we are pretty sure some people will have given using our product because they don't find the required information easily enough.
We already have more than 8.5 million direct downloads of our product and it is easy to see that the benefits of the organization would be great. Allowing us to keep more new users on one hand, and decrease the flow of trivial questions on the other (thus reducing time spent on support)!
We also have some less common documentation problems to overcome such as having issues with aligning good formal documentation to a project that supports such a wide variety of platforms with wildly different characteristics.
Projects only: List up to 5 individuals that you would like to attend. Please provide the country (and state if applicable) they would travel from, and one or two lines about why each person is a good candidate. Indicate those who would require full or partial travel assistance.
In alphabetical order:
Adrian Astley, from USA Adrian is a native English speaker and is a GSoC 2013 student. His English is excellent, and he spent a lot of energy to enter the project. He therefore has a decent knowledge of our product, and doesn't have all the (bad) habits the long-term members may have.
Arnaud Boutonné, from Belgium Arnaud is an engine developer for 4 years and was promoted co-project admin for the project 2 years ago. He's got a good insight of the project. He also has some experience about writing user guides and documentation, as he wrote some for European Commission (DG Agri, DI, DG Taxud, DG Research) in the '00s.
Péter Bozsó, from Hungary Péter is also a GSoC 2013 student and like Adrian he has invested a lot of time before the beginning of GSoC to gather all the required knowledge. He has experience of explaining things to people, as in the past he has been helping students from lower grades to learn Pascal, C and C++.
Thierry Crozat, from United Kingdom Thierry is the coordinator of the translation team. He has a very good insight of the project too, and knows particularly well how the translations of the project works. He also coordinated the effort to write the (partially outdated and incomplete) user manual on the wiki (http://wiki.scummvm.org/index.php/User_Manual) for a while and was one of the main contributors.
John Willis, from United Kingdom John has been a member of the ScummVM team for 7 years and looks after several ports of the platform. He has helped with documentation and project communication in the past. He is a firm believer in the need for good quality 'living' documentation to support a project (It is a critical requirement for the day job of being an Enterprise Architect).
All 5 would need travel assistance.
Projects only: Propose a topic of the Book Sprint and outline in a few sentences what you would like to cover.
Our product runs on more than 30 platforms. What are the best practices and obvious pits when you write documentation for massively cross-platform products?
When projects are based on reimplementation or emulation, how is it possible to write a proper documentation without mimicking the original documentation.
One of the issue we encountered with our previous effort to write a user manual was to keep it updated when releasing a new version of the software with changes in the GUI, new options, support for new games... What are the best practices to ease that effort?
Will you (or anyone you listed before) be attending the 2013 GSoC mentor summit? (Yes/No/Not Sure)