GSoD 2020: Technical writer applications guidelines
Starting 2020-06-09, the GSoD Technical writer applications are open!
This issue describes some useful information about this important step.
Warning
GSoD VideoLAN mentoring is a small team of volunteers, and there are a lot of candidates.
So do not be afraid if your questions are not answered instantly - it could take a couple of days.
Form
As described in the Google GSoD documentation, you will have to send a project description of the work you want to perform during the GSoD event.
We can try to help you on this. If you want to discuss about your proposal with us, you can:
- Create a confidential issue (check the
This issue is confidential and should only be visible to team members with at least Reporter access
checkbox when creating your issue) with your ideas, questions, etc. - Add
GSoD 2020:
at the beginning of your issue title
Content of the proposal
First of all, go read the GSoD 2020 VideoLAN introduction page if you did not before.
What we expect in your application proposal
- Explain what you want to do: at least,
- which theme you want to work on,
- the goal (the "story line") of your proposal,
- why you want to work on this specific subject,
- how do you want to do it:
- What kind of information and resources you will need, how you will use them,
- the structure of your future documentation (the "storyboard") and why,
- the tools and technologies you will want to use,
What we do NOT want to appear in your application proposal
- code. This is not the time to write and submit code/merge requests - it will come later. For specific themes, you can talk about tools, services or technologies, of course.
- your current or past contributions to (this) User documentation repository. This is definitively a good idea to participate to the current project, essentialy because it is a fast and efficient way of understanding our context and issues, but it is not mandatory for this step, and definitively not the purpose of this step.
Advices
- Try to determine the target audience of each project:
- where the reader comes from (how did they end up on these pages?),
- what they are looking for (tip, tutorial, exhaustive/reference guide, etc.),
- their technological knowledge & experience (the terms and vocabulary they can understand, whether they can easily setup their computer/device environment, etc.)
- Documentation writing is one of least appreciated duties of developers, and maintaining documentation can be an absolute nightmare because of that. Especially for the projects that are linked to development (API documentation, etc.), every automation strategy or technologies that reduce the documentation-specific work is very welcome.
- Documentation reading is considered extremely boring (sometimes on purpose) by users. To minimize this feeling, you have to focus on:
- Simplicity (no obscure technical term, unusual acronyms should be defined, etc.),
- Clarity (explicit text subjects, one subject at a time, structure consistency, etc.),
- Look & feel (cool looking - and coherent - screenshots, easy and responsive navigation, etc.),