Do you want to contribute to the LibreOffice development, but you don’t know enough about the LiberOffice code internals? Do you want to enhance the application or fix a bug in LibreOffice, but you don’t know how to do that? LibreOffice developer community can help you not only for at the beginning, but by helping you focus on the right aspect of the code. Reviewers will review your code that eventually will be part of the LibreOffice code!
How to understand the LibreOffice code?
There are good ways to grow your knowledge around LibreOffice. Let’s review some of them:
1) Learn how to start development
First things first: see our “Getting started with LibreOffice development video“:
Getting Started (Video Tutorial)
Also, make sure that you have read this page in the Wiki:
2) Read the developer documentation
One way to understand the LibreOffice is to read the documents, manuals and other learning materials. We have gathered many of them here:
But as a community driven project, not every aspect of the code has comprehensive documentation. So, the other way would be as follows:
3) Read the code
The code itself is the best source to understand the internals of the software. You can use OpenGrok to browse the code better. Module documentation and Doxygen output (for example, see doxygen documentation for canvas) can help you to understand many aspects of each module.
But as agile manifesto says, we are supposed to value people over other things:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation”
So, other than the referring to the code itself, a good way is to ask help from other people:
LibreOffice Conference 2016 in Brno
4) Ask help from the experts and other developers:
LibreOffice developers community consists of a large number of people. According to our developers’ page in the TDF Wiki, we have more than 1000 people involved in the development of LibreOffice in which a third of them were active during the previous year:
You can see the top contributors to LibreOffice core here:
Among these contributors, there are people with more experience and are experts in different areas of LibreOffice development. We have a list of these experts categorized by their field of expertise:
These experts are available in the LibreOffice developer mailing list. Please do not ask your question directly from these people by email, but rather discuss it in the mailing list or CC them in a bug report or in Gerrit. Discussing the issues in the mailing list and bug reports can take a while, but the results are usually well thought answers. To get a quicker answer, the #libreoffice-dev IRC channel would be a better choice.
While asking on IRC, please ask your question directly with enough details. If you want to send many lines of code or other lengthy text, please use a paste website like paste.debian.net and then provide a link.
If you want to know how a specific feature is implemented in LibreOffice, or how to approach to fix a bug, or any other questions related to development, this room is a good place for you.
How to Ask Good Questions
To get a good answer, you should ask a good question. For a suggested reading for asking smart questions that lead to good answers, take a look at this article from Eric S. Raymond:
One important note about IRC is that the LibreOffice IRC rooms are bridged into the matrix space: https://matrix.to/#/#libreoffice-space:matrix.org, so that you can easily use several Matrix clients to access to the IRC rooms. It is specially good when you want to access the previous chats, or you want to access the rooms via a mobile phone. There are several good Matrix clients available for the desktop, web and mobile platforms.
Due to the nature of the FOSS software and its community, active people in the LibreOffice developer community are usually helpful and are willing to help. Get help from LibreOffice developer community and start contribution and help make things better in the LibreOffice!