My name is Ilmari and I'm working for the Document Foundation as a development marketing person. It takes a lot more than C++ to keep LibreOffice going as a project, so I want to summarize the various supporting activities.

It's useful to get an understanding of the big picture. When something in the software is changed, you have to ask how does this affect documentation or quality assurance or localization.

We should respect equally the work of everyone and every team. Translating requires one to have a good command of the target language.

The translation produced cannot be machine-like. It should be easy to read and stylistically appropriate. Translators have to use specialized technical vocabulary. Usually this involves researching what sort of terminology is established in the target language.

As a first step, it's recommended to subscribe to the localization mailing list. The user interface and help can be translated in WEBLATE.

You log into WEBLATE using your TDF account. To get full translation rights for a language, you have to contact TDF's localization manager, Sofie Gotia. If you want to start a new language project, refer to the instructions in the LibreOffice localization guide wiki page.

The links will be included in the slides. When translating the user interface, you're dealing with very compact expressions and you have to keep track of the context in the software itself. In a future version of WEBLATE, we will be able to associate screenshots with translation strings.

Sometimes help content goes out of date, so it's a good idea to check the reality in the software. It would be ideal to contribute to keeping help accurate instead of duplicating outdated information in numerous languages.

If a mistake is spotted and corrected early, it will prevent lots of unnecessary work. Mistakes and proposals for new things should be reported to Bugzilla. Sofie Gotia gives assistance in these cases. The guidebooks are writer documents, but you can still take advantage of translation tools when working on them.

Existing translated terminology in the UI and help can be brought over when using desktop translation tool called OmegaT. The translated guides are hosted at documentation.libreoffice.org.

Announcing your intention to work on a guide is advised to avoid duplicate work. TDF wiki hosts frequently asked questions, technical documentation and various other things. Not everything in the wiki needs to be translated, such as meeting minutes, highly specialized technical notes and event pages.

Then quality assurance in its most basic form has arguably the lowest threshold to contribute in. One just has to follow steps in bug reports and to witness the result.

In the context of QA, one can report problems, confirm the reports of others and prevent problems by constructing automated bug catching methods. For helping us analyze bug reports, we are eagerly awaiting some machine learning based tools, but nothing can fully replace human analysis.

Bug report analyzers known as triagers can be incredibly useful and save a lot of time from developers. Often triagers are able to pinpoint the exact code change that caused a bug.

Debug reports are found in TDF bugzilla and resemble discussion threads. Having a diverse group of triagers is important because a single person cannot deal with the complexity of LibreOffice's functionality, supported platforms and locales.

In addition to bugzilla, coordination of the work happens in chat channels and the QA mailing list. It is possible to write unit tests in Python to test the correctness of LibreOffice's internal functionality.

Creating user interface tests is easy as one can now simply log usage actions and automatically convert the log file into a Python test file. These tests prevent incorrect behavior on the level of UI slipping in. They can also find crashes.

LibreOffice QA is a massive topic with tons of technical documentation in the wiki. This is why we point beginners to a crystallized quick start guide. Contributing to TDF infrastructure requires skills in Linux system administration.

Due to the nature of the work, it is usually best to start by attending an infra-team call. The calls are announced on the mailing list called website. Software on TDF servers is deployed using the salt automation solution.

Infrastructure tasks are tracked in the Redmine project management system. TDF relies on many web applications that support the contributor community. Sometimes this means creating customized sites using frameworks, but usually just changing the look and feel of special purpose applications.

Here we see a selection of some of the applications that run on our servers. We have the programming languages used at the left. Doing web development does not necessarily require privileged access to our servers.

In many cases we can provide a local copy for use in development. Someone with the ability to contribute upstream improvements to the applications we use would be very valuable. This type of development would happen in collaboration with the other teams.

Deployment of new features on our servers might take some time depending on what they concern. User support requires a patient and gentle attitude towards your fellow human beings, some knowledge of LibreOffice and the ability to search for information.

We don't have a customer support hotline, but other than that, support work can happen all over the known digital communication channels. Users can reach out for help through social media such as IRC or Facebook.

TDF wiki lists local and global social networks, mailing lists and chat channels. We host our own questions and answers site at ask.libreoffice.org. It is available in multiple languages. It is especially valuable if the support person is able to identify bugs in user questions and submit them to our bug tracker.

There are three types of documentation for LibreOffice. Help content is dry and brief, acting as a reference. Guidebooks are for holding the user by the hand.

The wiki has mostly documentation related to organizing contributions and contributor team workflows, but also how-to guides and frequently asked questions. The wiki has the lowest barrier to entry. You can log in with your TDF account and immediately start improving the content.

The guidebooks are written and reviewed chapter by chapter as individual files using LibreOffice itself. New contributors introduce themselves on the documentation mailing list and are given access to the guide author's next cloud group.

Guide authors announce their intentions and progress on the documentation mailing list. The help content source files are in a custom XML format. Creating and editing these is unfortunately not very straightforward.

TDF staff has worked on tools that make the editing experience more pleasant. Help improvement tasks are tracked in Bugzilla and submitted through Gerrit code review system. Technical writers are able to get paid for working on LibreOffice documentation by participating in the Google-sponsored season of docs.

The documentation team sometimes holds meetings using Jitsi conferencing. The meetings are announced in advance on the mailing list. The marketing team values new perspectives tremendously.

If you have an idea on how to make more people aware of LibreOffice, please let us know immediately. LibreOffice being a global project, a centralized approach to marketing is not enough. We trust that LibreOffice enthusiasts all around the world are aware of the best ways to spread word in their area.

TDF regularly sponsors people who want to represent LibreOffice at local events. The marketing staff at TDF writes blog posts, interviews contributors, creates videos and interacts with users on social media.

Anyone is welcome to do the same on their own, but TDF staff can also edit and publish content offered to them. There are lots of marketing resources and materials found in the wiki. Marketing conference calls are open to everyone and are announced on the marketing mailing list.

The local and global social networks, mailing lists and chat channels also act as platforms for planning and conducting marketing. Visual designers find an ally in the marketing team. Designing things for marketing materials often allows the imagination to run wild.

Media for the marketing materials include flyers, stickers and t-shirts. Motion graphics in particular is welcome as we regularly release video clips.

Here we have an animation created by a Taiwanese team celebrating the LibreOffice Android viewer. This was created in Blender. Shout out to Franklin Wen for commissioning the work.

Then a more constrained form of design is found in icon teams and document templates. Contributors are encouraged to discuss with the design team before starting any icon work.

TDF Bugzilla contains a treasure trove of user requests. There are both new and old reports that need to be analyzed with a critical eye.

The user experience team has to consider tough questions. Is there a better way to achieve the thing being requested? Does a request belong to the core software at all? How should the requested feature be implemented in detail? Will a change cause problems in some use cases?

The weekly design team meetings are Jitsi conference calls and they are an opportunity to discuss a selected handful of reports. Other methods of communication are chat channels and mailing lists and they are listed on the design wiki.

UX team members might contribute graphical sketches of proposed changes to the user interface. Sometimes they will directly modify the files that define the UI. This does not require C++ skills.

The work is reviewed in Gerrit. The design wiki documents guidelines and user personas that help when reasoning about UX. Changes to the user interface often require updating the help content. Ignoring this aspect creates a minefield of obsolete help articles

so it should be taken very seriously and planned alongside the actual changes. Sometimes we receive proposals for a complete and unified user interface overhaul. However, LibreOffice has deliberately been built so that it conforms to the appearance of the operating system.

Therefore, these types of proposals are not useful in practice. As mentioned earlier, we have a ton of different websites and web applications so we happily invite web design contributions.

And finally, TDF administrative positions. Getting into these is not so straightforward because one needs to win an election. The positions are perfect for people having governance near to their heart. The first step is contributing for some months in any area.

One can then join the TDF board of trustees, in other words, become a member. Any member can nominate themselves for the board or membership committee elections. The board decides where TDF resources are directed to.

The membership committee monitors the contributor community and handles membership applications. That was all, so thanks.

Does anyone have a question?

Sure, I hope people might use this in some local events, translate the content.

Yeah, I have it already in the notes.