There will be slots for unscheduled talks and discussion panels during the core days. You will have an opportunity to propose a topic in the morning which other attendees can +1 if they are interested in it. At 16:00 on Friday, 13:30 on Saturday and 16:00 on Sunday, the most popular talks will be posted to the schedule board, so make sure to check back regularly!

Lightning talks will take place on Sunday the 14th of August, you will be able to sign up on the day!

2015 saw the return of training sessions at GNOME.Asia. Apart from the documentation and development training sessions, Andika Triwidada from the Indonesian localisation team and Alexandre Franke also spoke about translations. This year, a larger number of contributors with experience in different areas of GNOME attended the training day so we were able to offer more instructors per trainee as well as training in more areas, including marketing. From a documentation point of view, this felt more successful and less stressful than 2014 as we were able to offer more support to attendees.

Rather than re-run the documentation talk like I did last year, this year I presented about contributing to GNOME. As usual, the question of “where do I start?” came up a few times so I think it was productive to emphasise that coding is not the only way to contribute to and promote GNOME.

After the conference, Dave and I visited Bogor, a lovely, green city which contrasted quite drastically with Depok and Jakarta. Taufan Lubis and his family were kind enough to host us for the visit, and to show us around the area.

Thank you to the GNOME Foundation for the travel and accommodation sponsorship, to Collabora for the time to attend the conference and to the local team for making such a great event happen.

Licensing

gedit documentation saw some licensing improvements thanks to Jim. A number of the help pages had previously been published without a license which is something that the team has been fixing over the last few years. Adding the license after the pages have been written is a bit of an arduous task. Progress has been slow but steady.

Developer Documentation

Bastian Ilsø and David King made further progress on gnome-devel-docs. Bastian made improvements to the first user experience of writing an application using the platform demos and learnt the importance of validating the XML.

yelp

Around August 2014, the documentation team started accepting emailed feedback about the documentation from help.gnome.org. It has been quite a success and yelp will see this feature as soon as Shaun McCance can build it.

Mallard

Shaun also improved projectmallard.org, the home of Mallard, and furthered the development of DuckType, a markdown Mallard language.

We had a grand total of 59 sponsorship applications for GUADEC (up 5 on 2013) and a budget of €30,000 (approximately $43,000). The requests amounted to $63,799 which we calculated would be more realistic at $61,899 after verifying travel and accommodation costs. We were able to offer sponsorships to the amount of $39295 to 58 applicants. We helped find an alternative source of sponsorship for the applicant who was not offered sponsorship.

The first application was received on the 12th of May (thank you for being organised) and seven applications were late (one of which was over a month late).

Some people who couldn’t make it to GUADEC did not tell us so beforehand. Unfortunately, the lack of communication has cost the Foundation a little bit of money as we did not have a chance to cancel the rooms which has been booked for those people. At a time when the sponsorship budget is very tight, this could have been handled with more consideration.

9 people sent in their receipts past the deadline.

A fair few people used the plain text application form when sending in their sponsorship requests, which I find easier to process than the LibreOffice form as I don’t need to open it in another application.

In somewhat related news, the Travel Committee is now verifying considerably more stringently that the sponsored attendees for all events fulfil their duties.

(André is always happy when the Foundation can help people come to GUADEC.)

It is traditional for the documentation team try to meet a few times per year for hackfests, alternating between Europe and North America to help the whole team make it to at least one event per year. The hackfests serve two purposes: getting work done and motivating/rejuvenating the team.

GUADEC was interesting this year. It was great to meet up with old friends, meet lots of new people (/me looks at Shobha) and new old people who I should have long since met by now. Tarte flambée and whisky were had by all. Hair happened to some. Tea, damsons and mirabelles also happened (shortly after we returned, I found a mirabelle tree in the shared green space across the road from our house). It was nice to see everyone enjoying themselves at the picnic and football. Bastien always wins.

It was a shame to not see as many documentation team members at GUADEC as we’ve had in previous years and the team didn’t really have a proper hackfest either (although we did participate in a screenshot automation BoF). Spending two days in board and adboard meetings isn’t fun, but is necessary and generally much more productive than phone meetings. I was disappointed to see an anti-harassment policy for the conference: it is a shame that it is thought that the community is tending in the direction of harassing behaviour to a point where there is a requirement for the community to enforce the law (harassment and discrimination are illegal in many, if not all, European countries). I want to be part of a community built on mutual respect, not distrust and inability to communicate. It also seems that the policy can only be used by specific individuals, not everyone, which does seem counter-productive.

It seemed to me, having been involved in GUADEC organisation for the last four years, that 2014 was an especially challenging year. I appreciate all the work that Alexandre and the team have put into making it happen. I foresee even more challenges for 2015, but I’m sure that we will all be there to support the new team.

3.14 was a bit of a slow release cycle for documentation as the team as a whole have not had much free time to work on updating it. I would like to thank the translation teams for being awesome and helping out by filing bugs and patches (both of which are very welcome). There are currently rather a lot of documentation patches and branches to review, so I will be concentrating on those in the next few weeks. I hope that the team will be able to hold another hackfest in January or February to prepare for 3.16, but this is currently a bit of an uncertainty unless we can find sponsors to help with travel. If you know of anyone interested in sponsoring the hackfest please get in touch with the team or with me.

Thank you to the GNOME Foundation for sponsoring my travel and accommodation at GUADEC, and to Liam, Ella, Finn and Martin for looking after the chickens. I wouldn’t have been able to make it to GUADEC without you.

Dave, Petr, Mike, Jim, Shaun and I are now half way through Open Help in Cincinnati, OH, USA. This is the fourth Open Help and I’m happy to say that the documentation team has made it to all four so far (and also to Writing Open Source, the predecessor to Open Help).

We have heard a number of fascinating presentations so far, generally themed around engaging contributors and creating a community. Eric Shepherd talked to us about breaking down barriers to contribution and fostering the Mozilla community. Rich Bowen shared his wisdom on helping newcomers with documentation. Shaun McCance has been building a community around Clifton Market in real life, which has proven to be an interesting challenge.

Dave and I took the opportunity to talk about how the documentation team does outreach, the challenges faced with interships and barriers to contributions.

Tomorrow, the documentation team are going to start on the sprints where we will be working on the system administrator guide.

Last Friday, the documentation team ran a training session for 25 odd newcomers to open source contribution. While the silence in response to “How many of you have ever contributed to any open source project?” was deafening, it was refreshing to see so many people turn up to try something new and the enthusiasm was overwhelming.

Many of the attendees came with GNOME in a virtual machine or installed, as we asked them to make sure that they had a recent version or gnome-continuous in a VM, which is essential for documentation. While most of the attendees were running Unity or GNOME, some were running Windows.

The tools which the newcomers had to have were a text editor, git and yelp. yelp-tools was also desirable, but although we covered yelp-tools briefly, we didn’t get around to using it.

The newcomers started by finding the GNOME documentation team space on the wiki and navigating to the tasks page. While they would normally have been expected to pick the link to easy bugs from there, for the training session, we picked some bugs that had especially low barriers to entry. These bugs did not generally require one to build applications, had especially good descriptions and were relatively clear.

When the newcomers reached Bugzilla and picked a bug, the next step was to figure out which project the help was in (gnome-user-docs or one of the applications, this is listed under “Product” in the bug details), then find the product in git. One of the issues which we came across was that the search for git repositories is a little bit unreliable. For example, searching for “gnome user docs” gives no results, instead of showing gnome-user-docs. While I would generally start a browser search for the repository name on the page, almost all the newcomers went straight for the search field in the page.

Next up, the newcomers had to understand the bug, and in some cases find which page it was on. While the majority of user docs are in /help/C, it was very confusing that gnome-user-docs are in /gnome-help/C. And why not help/en? C is intended to be the source docs, and it’s only convention that they happen to be in English in GNOME. There’s no reason for them to be in English other than that more people are able to write in English and translate from English.

Files were edited, changes were made. Various text editors were used, such as vim, vi, emacs, nano and gedit, to name a few. Files were not always saved.

Lastly, the patch creation and attaching patches to bugzilla were simple last steps to finish off over an hour of work.

The experience has reinforced the idea that the biggest step to first contributions is setting up the working environment and figuring out how all of our tools work. This is surprisingly difficult for many people who want to contribute and learn how we work.

We had around 25 attendees, some of whom worked in pairs. Unfortunately, it’s currently not possible to have multiple authors for a commit, so some of the newcomers who worked in pairs will not be listed as authors in git. In total, there were around 20 odd bugs that were looked at. André, Dave and Aleksander helped out at the event, but it was still difficult to effectively help so many people. Under ideal circumstances, I would prefer to have an absolute maximum of 4 individuals per mentor and preferably around 3 or so capable attendees per mentor.

The documentation team will be at GNOME.Asia this weekend and we are running a session for newcomers today, and there’s also an introduction to GNOME 3 development session which is being run by David King. The GNOME.Asia team have been really great at helping us arrange and set up the training sessions, so they definitely deserve a big thank you!

There will be a re-run of the documentation talk during the conference, on Saturday, for those who are not able to make the pre-conference event and I will be happy to help give people a hand with making their first contribution to documentation!