CST462 - Service Learning Reflection: LibreOffice

 Service Learning: LibreOffice Software Development Reflection

        Throughout my service-learning experience with LibreOffice, I gained a much-needed and hands-on understanding of what it actually means to engage with a large, long-lived open-source codebase. One of the biggest victories was simply learning how to navigate the environment--getting the project to build, understanding the workflow through Gerrit, and becoming comfortable using tools like "git grep" to locate and modify relevant code. These may seem like small steps but in a project of this scale they are foundational and non-trivial. I feel very prepared to dive into another huge codebase where I must accept that I simply will not be able to understand much of what I see and instead will have to drill down into one specific focus to gain understanding and contribute efforts.

        The most impactful parts of the experience were seeing how real-world software evolves over time and seeing the reality of a large and dense system. Concepts like VCL and a11y (implementations for blind and illiterate users, a shorthand for Accessibility) initially felt overly complex and daunting, but working through them gave me insight into the trade-offs and historical layering that exist in mature systems. Additionally, being introduced to accessibility considerations broadened my perspective on software development, the user experience, and what engineering a functional program for all truly means. It reinforced that software is not just about functionality, but also about who is able to use it and how.

        As for what I would improve, this is not much of a suggestion for TDF to implement, merely a reality of being a working student. I would have spent triple the hours I did on this project if I were not faced with the necessity of paying bills. My biggest regret this semester is not being able to give LO more attention than I did.

        One of the main challenges I faced aside from time and energy constraints was the initial barrier to entry. The build process alone required significant troubleshooting and understanding where to even begin in the codebase was overwhelming. Unlike smaller academic projects, there is no clear starting point (without a dexterous and talented learning coordinator such as I was provided by The Document Foundation's Ilmari Lauhakangas)--progress comes from persistence and incremental understanding rather than immediate clarity.

       My advice to any service-learning student who begins a wonderful partnership with The Document Foundation and LibreOffice would simply be to read the documentation, they are not called TDF for no reason! I have yet to see a more prime example of documentation and clear instructions as the perfect antidote to an extremely steep barrier of entry. For whatever file or bug you are working on, I can guarantee that documentation about it exists. The Document Foundation is so fantastic about providing ample learning materials, providing down-to-earth guidance, and generally being thrilling to work alongside.


Comments

Post a Comment

Popular posts from this blog

Week 1 - CST363 First Post: Relational Database Reflections

From the orientation, your reading from week 1, and your own experience answer the following questions: Relational database tables and spreadsheets look similar with both having rows and columns.  What are some important differences between the two? At first glance, a relational database and a spreadsheet in an application such as Excel look fairly commensurate to each other in purpose and functionality--they both are comprised of rows and columns that hold data organized by column names and row numbers. The truth is that their visual similarity is where the commensuration ends and the vast differences begin. Relational databases adhere to strict and organized rules that ensure they can manage large volumes of structured data as well as complex queries to return results from that data whereas spreadsheets can be filled out arbitrarily. Foreign keys and primary keys can tie individual values or sets of values to other tables of data which in turn impact how data can be returned or c...
Read more

Week 6 - Weekly Reflection

          Week 6 of CST363 offered many learning opportunities both in assigned reading and labs. While the reading gave the initial rundown on database connections, query execution, and the use of prepared statements through APIs like JDBC, the Java labs offered hands-on teaching moments that clarified how to use these concepts in practice. Working directly with JDBC to manage connections, execute SQL queries, and handle transactions worked wonders in solidifying the material. Experiencing Java interface with SQL through IntelliJ and MySQL Workbench additionally contextualized using Connections and using prepared statements to aid prevention of SQL injection attacks. The conceptual topics tackled in the reading are an aspect of computer science that I am always compelled to learn about--in this case it is the different programming paradigms when considering SQL in the context of application development. Qualifying the differences between imperative and dec...
Read more

Week 5 - Slow Indexes Reflection

 Referencing  Slow Indexes in RDBMS : if indexes are supposed to speed up performance of query, what does the author mean by a slow index?       In my time working with indexes thus far, I have seen what miracles they can work for improving query performance. This is my first encounter with unpacking how indexes could actually slow a query down. Author Markus Winand illustrates how index lookups can still be slow and expensive even when functioning properly. Winand explains how index performance entails more than just tree traversal in a clear and inviting fashion. First, the lookup conducts the tree traversal by navigating down the index B-tree to reach the intended leaf node. Upon following the leaf node chain, multiple hits can mean the database needs to retrieve all matching index entries. For each matching index entry, the database will then access the corresponding row in the table, which could be located entirely elsewhere in memory or disk blocks. W...
Read more