For this blog post, I’ll be introducing the GNOME and Librsvg from a newcomer’s perspective, aimed towards other newcomers or prospective newcomers, and going over how I chose to work on Librsvg.
Getting started is, in my opinion, the most difficult and confusing part of becoming a contributor. There’s a lot to consider, for example:
What languages, both programming and communication, does the project use and how do these overlap with what you know?
What are your interests and how do they overlap with what the project does?
Are you looking at this project because of an internship program such as Outreachy, and if so, what are the program’s requirements and do / can you meet them?
What kind of environment are you looking for?
How in the world do you use Git?
All of these questions are ones I believe are important to consider when choosing a project to contribute to, especially for a program such as Outreachy.
When choosing what project to go with for my Outreachy contribution round, I knew I wanted to focus on just one project, and put my all into applying for it, as I thought that would be the best option versus splitting my time between two or more projects in hope that more would mean a better chance of getting chosen. This was also my final semester of university and I had just had surgery a month prior to applications opening up so I had a lot on my plate when I was considering all of this, so I thought to myself “what would be the most interesting project that I would both have a strong starting point and have the opportunity to learn the most?”
I started looking at the Firefox project to improve the Downloads UI, as that’s something I use everyday, and so I had an interest in improving it, but somewhere, either one of the Outreachy guides or blog posts from former members, I don’t quite remember, recommended against applying for big projects like Firefox because so many people apply to them, and finding a smaller project that is still interesting would be best.
After a short look at that, I started looking at other projects I was interested in, and narrowed down my options to both of GNOME’s projects, Tor, Matrix, and Wikimedia. Tor’s project was essentially helping people in more of a customer-service style fashion, which I’ve worked before and don’t find too appealing, but I support that project so I gave it a thought. Matrix was working on their server stack, moving part of it from python 2 to 3 and while that would be interesting, I had never worked with python outside of minor scripting so I wasn’t too sure about it, so I passed that one up too. Wikimedia was working on a bot for synchronization that was interesting, but also python so I passed that one up.
I had dabbled in Rust programming a bit before choosing to check out the Gitlab page for Librsvg, so I knew the very basics. Rust seemed like a great option for a language to get better at, it is an relatively new language, easier to use than C, and has some of the same styles and patterns I’m used to with languages such as Java (which I got my start programming in almost 10 years ago, can you guess what game I was making modifications for?) and C#, and on top of all of that, it has a really cute mascot. Just look at them:
Aside from the all-important cute mascot, Rust also has an amazing set of documentation sites, from the Rust Book (https://www.rust-lang.org/learn) to a course, and a Rust By Example site which I have found immensely helpful (https://doc.rust-lang.org/stable/rust-by-example/).
Aside from using Rust, Librsvg was doing something else that I find incredibly interesting, going through files (a process called parsing) to create an output. For my game design class in university I spent a lot of time writing a parser to make the writer’s job easier for our visual novel project by letting them write a text file to determine the flow of the game. It’s something that makes me extremely happy to figure out, and like games, it’s something with a visual output. I’m an incredibly visually-minded person, and having the ability to see what is going on in code goes a very long way towards making something easier for me to understand, plus it makes the project even more fun as even if you mess up you can still get some really interesting pictures in the process.
An image of a black line with what is supposed to be two triangles on each end, but they're both pointing the same direction and are cut off the render, making them look like weirdly shaped polygons.
All of this is what led me to ultimately choose to apply to Librsvg.
This is the part where I return to the topic of this blog post, GNOME and Librsvg explained from a relative newcomer’s perspective to newcomers.
I was scared. I had never contributed to a project before, had withdrawn from my university’s Computer Science program because of a variety of reasons I’ll probably talk about in a later post, and was starting at this whole programming thing while finishing up my last semester getting an arts degree in film and media studies. I had used GNOME though, from my first Linux install (Ubuntu 12.04, GNOME Edition) almost 10 years ago now, I have consistently returned to the familiar but evolving GNOME UI for my Linux installs, no matter what version of Linux I am running. I had the experience of being a long time user of the platform, but never a developer or contributor, but we all have to start somewhere eh?
So I started by creating an Outreachy folder in my Documents and inside I opened a terminal and typed out:
git clone https://gitlab.gnome.org/GNOME/librsvg.git
So now I had the code, a great start! But it’s not everything needed to get started, in fact there’s quite a bit more, but maybe this will help.
Getting involved with a project as long-lived, large, and spread out as GNOME can be daunting at first, at least it was for me, but a good place to start is looking at their website! (https://www.gnome.org/)
For starters, GNOME makes the GNOME UI (or GNOME Shell), right now at version 40, which is their most visible project, but taking a look at their technologies page they also work with and on projects such as the Linux Kernel, OSTree (A system for operating system installation, distribution, and updating), Flatpak (an application distribution technology and platform), GTK (GNOME’s own GUI toolkit which powers the Shell), among many, many others. Aside from these there’s technologies for calling, data storage, language integration, display management, even the Linux Bluetooth stack.
The GNOME Foundation knows this is a lot for a newcomer to wrap their head around, so they conveniently have a Get Involved section of the website (https://www.gnome.org/get-involved/). This was the second place I looked at when figuring out how to get involved (the first being Outreachy’s project page, but most people wouldn’t see that unless they were looking to get involved through Outreachy).
There’s buttons to look at every part of the GNOME ecosystem, with the Newcomers guide being the one I chose first. (https://wiki.gnome.org/Newcomers/)
The newcomer’s guide links you to the various chat applications that GNOME uses to communicate, there’s Matrix (https://matrix.to/#/#newcomers:gnome.org) IRC (which is bridged to Matrix, so use the matrix if you’re able to) Discourse, a forum site, (https://discourse.gnome.org/) and Gnome Chat, built on Rocket.Chat, a slack-like platform (https://chat.gnome.org/home)
Along with that there’s the GNOME code of conduct which applies to all of GNOME’s functions and explains the expectations for contributors (https://wiki.gnome.org/Foundation/CodeOfConduct) This part was important for me as GNOME has a good track record for supporting minorities, and they started the Outreachy program, so I felt a lot better about contributing to them versus other projects (that’s not to say it’s perfect or other projects are bad, but not every project has a great track record in this department)
The rest of the Newcomers guide is aimed towards people looking to get introduced with the various applications that GNOME makes, such as Files, the file browser, or the Maps application, how to use Builder to modify and build the app, and then how to find the documentation for the apps.
This is the point where contributing to Librsvg diverges a bit from the GNOME app ecosystem, as Librsvg is a library that is used by other apps to render SVG (Scalable Vector Graphics, if you’ve used Adobe Illustrator or Inkscape, you’ve used them) images. For Outreachy applicants, the project description on their website is a great start, but for those who find this post not through Outreachy, here’s how you get started:
When getting started, knowing where to find information about projects can be almost as difficult as fixing issues in the project itself, but for Librsvg, this is pretty much all centralized in one place, the Gitlab repository: https://gitlab.gnome.org/GNOME/librsvg
This is also the site where you would find the codebases for nearly every other GNOME project, and GNOME Shell itself. It’s also used as a place for teams to share non-code things within GNOME, such as the Design team, you can explore more here: https://gitlab.gnome.org/explore/groups
Going back to Librsvg’s repository, the first page shows the readme underneath the list of files inside the repository (if you’ve downloaded the repository using the command I posted above, you can find this by opening the README.md file) this explains the project from both a user’s and contributor’s perspective, along with links for further reading. One important file for contributing to the project is the aptly named CONTRIBUTING.md file (https://gitlab.gnome.org/GNOME/librsvg/-/blob/master/CONTRIBUTING.md), which explains a lot of terms and processes for contributing to the project.
Yet another file that’s important at this stage is the COMPILING.md file, which explains how to compile Librsvg, an important step for testing changes to make sure it all works. (https://gitlab.gnome.org/GNOME/librsvg/-/blob/master/COMPILING.md)
Now you know how to contribute, and how to compile, but how do you know what to contribute to?
You check the issue tracker! (https://gitlab.gnome.org/GNOME/librsvg/-/issues)
The issue tracker does just what its name suggests, it tracks the issues people have with the library, with the issues tagged by what features they add or if they’re good newcomer issues. To see the newcomers issues you can go here: https://gitlab.gnome.org/GNOME/librsvg/-/issues?label_name=4.+Newcomers
For my first issue I started simple, but I wanted something that would be important, so I chose an issue with the newcomers and prio-high tags (https://gitlab.gnome.org/GNOME/librsvg/-/issues/698) and got started poking around the code. This was an issue with a radius for feMorphology (a filter) being too large and causing the program to run for hours, so I looked around the code to see where that could be located, and found the src/filters/morphology.rs file, which contains the code for this filter. Within there is code for transforming the radius x and y dimensions, so I added a .min() function onto that call for both of them, thus limiting it and fixing the problem.
This was my first commit done! But now how do I get that to the gitlab?
First I made a Gitlab account (https://gitlab.com/users/sign_up) which I could use to login to the GNOME Gitlab, and from there I went to librsvg’s repository and hit the “fork” button at the top right, which made my very own version of the repository, to which I commited my changes.
A good rundown on basic git commands is here (https://www.hostinger.com/tutorials/basic-git-commands)
But essentially what that last part included was setting up git on my local machine, adding my account information from my gitlab account as gitlab explains in their new account setup, then I made a git commit with my new changes, pushed it to my repository, and finally created a merge request in my branch to push that commit to the main repository.
This workflow is described here: https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html
You can find my merge request here: https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/503
That’s it! My first contribution! I’ll make a post about my day-to-day workflow at some point in the future, as I’ve learned a lot about both Git and how to best manage it and my contributions over the past month and I’m excited to share it, but this post has gone on long enough.
This blog post ended up a bit longer than I expected, but it covers basically all the bases for introducing someone to Librsvg and GNOME, along with going through why I chose the project and considerations for future Outreachy applicants choosing their own project.