Doc Sprint/Application/2013

Doc Sprint Summit v3.0 Application

Introduction

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.

Is this a project or an individual application? (Project / Individual)

Project

What is your name or the name of the group you are submitting information on behalf of?

ScummVM

What is the email address you'd like us to use for this application?

strangerke@scummvm.org

What is the phone number you'd like to use for this application?

+32497691686

Are you, or the nominated project, associated with a current or past GSoC Project? (Yes/No/Not Sure)

Yes

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 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 we are pretty sure some people even give up using our product because they don't find easily enough the required information.

With already more than 8.5 million direct downloads of our product, the benefits of the organization would be great: we could keep more new users on one hand, and decrease the flow of trivial questions on the other (thus reducing time spent on support)!

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.

- how to write a documentation for a massively cross-platform product

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?

- how to write documentation for reimplementations/emulators/etc

When projects are based on reimplementation or emulation, how is it possible to write a proper documentation without mimicking the original documentation.

- how to keep documentation up to date for a constantly evolving open source project

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)

Not Sure