Notes from GUADEC 2015


Screenshot automation references from GUADEC 2014:

An example configuration file with script-based procedures consumable by the screenshot automation framework:

Any media which we need to use for screenshots need to be public domain.



  • Create stock photos of our own, e.g. photo app w/ public domain images?
  • Dogtail doesn't take shots of GNOME Shell - only of apps.
  • Might be a good idea for the developers to help docs create scripts that can then be used by the docs team


Challenges to onboarding for both docs and translation teams

  • Reducing the barrier of entry - if something is too technical
  • Humanization - who is part of this community that I'm joining? (might have privacy issues)
  • Retention


Summer of Code - retention mechanism, pretty good. why? mentor - personal coaching, length of time, get past some of the barriers, pre-internship interest, team style (significant contributions, like a few pages of content... in GNOME, then you have to submit a patch and get it accepted).

Commitment: Right now it's been about 3 years of contribution for the docs team.

Community: all interns should attend a hackfest in their first 6 months (doc sprints)

Look at Julita's blog for ideas on IRC onboarding tips:

Docs Team

Challenges for the Docs Team:

  • Changing the English affects all languages, therefore it makes people less likely to try to change things in English.
  • Retention & ROI with mentoring people.

  • Blip ( didn't get worked on. We would like a way to see the completion status of all of the pages.


  • What are the different roles and "job descriptions"?
  • Docs process and workflow is not well known.
  • Need to know when things are out of date. How can we make the process for reporting errors easy?

Action Steps for Docs:

  • Translation statuses - which ones are ready for translation and which ones are not? Might want to set some internal deadlines and cycles.
  • Readiness status needs to be implemented in ITS. Mark things as final or not. - (@Shaun) - talk to the Zanata people to try to implement flags. Extension in ITS 3.0! This is the infrastructure in order to allow for flags. Investigate doing readiness tool.
  • Create an open source style guide or a docs team style guide. (Might be done at a 5 day hackfest.) Look into Google's Book sprint? @Kat & Shaun to look into a hackfest.

  • Refresh the wiki pages. Add a link to the voice / style guide on the wiki page or somewhere in the onboarding process.
  • Might want to include:

  • This is BOF material, want people who are not docs people!
  • Make people more aware of the yelp-check ( People should be using it. Blog about it or somehow else make people aware of it. (Shaun just tweeted it!) What are other ways we can do this?

  • Engage people by showing them where they can contribute. List of areas or general projects that a new person could work on. Or, urgent areas.
  • - a great start! Is there a way to make this more engaging / keep improving?

  • Easy docs bugs:

  • Create a process for how non-writers can flag things that are out of date or that can be improved. This is BOF material - feedback button in Yelp (send to docs feedback group)? @Shaun with Dave (to put a button on Yelp)

  • Review Allan's doc and give feedback: Design notes: @Kat, David & Petr

Who We Want as a Contributor:

  • People who know English well
  • Be able to use the tools but don't need to hack, can learn technical things easily
  • Needs to be a user (can be any kind of OS). Need to be able to actually run the software
  • Link to it from

See Also:

DocumentationProject/GUADEC2015Notes (last edited 2015-09-25 09:04:08 by PetrKovar)