Organizing Pop! Volunteers

[mmstick]

I am starting this thread to initiate an onboarding process for open source volunteers to the Pop! project. All of the Pop! projects are open source, and developed exclusively out in the open in public view. Anyone who would like to contribute to the development of Pop! is encouraged to do so, and will see their work deployed on Pop! systems everywhere. Any such works that get accepted and merged into our projects will find their names listed in our weekly Pop! posts. Over time, I will update this post with more information to guide newcomers into the process.

Why

Despite being open source, almost all contributions to the project are by System76's team of engineers. Although to be expected, establishing Pop!_OS as a developer-friendly OS means that we need better resources for encouraging open source contributions and discussions. I feel that the primary blocker for most contributors is likely attaining guidance in getting acquainted with our development workflow, or otherwise making the first to reach out. As a result, this thread will serve as a starting point for many who would like to contribute, but do not know where to start. Hobbyists, students, and professionals alike are all welcome to join the community.

Getting Started

Write a comment here describing your interests and skills, or any questions that you have about our development workflow, and I will respond to help you get started. No one is expected to be an expert to contribute to the project. The capability and desire to learn is the most important skill of all. I may not be available to offer help 24/7, or 7 days a week, but I can guarantee that I will read each post, and get back to anyone who is genuinely interested in contributing to the project.

Contributing as a Tester

Pull requests are opened on a regular basis, and software is continually evolving. Testers are important for discovering issues and providing valuable feedback to aid in replicating and diagnosing their cause. If you are a tester, you can reach out to help reduce the burden on quality assistance by screening pull requests in advance.

Contributing as a Programmer

First and foremost, almost all Pop! software projects are written in Rust. Therefore, familiarity with Rust is vital to contribute to our projects. However, years of experience in Rust are not required. There are very few people today (March 2019) who have a lot of experience in Rust, and more than half of the existing Rust community have been programming in Rust for less than a year. A basic understanding of the language, and an ability to write solutions which compile, are good enough. I can offer guidance to sharpen your Rust programming skills through code reviews, or answer any questions in our official chatroom.

All of our projects are located in our Pop!_OS repository on GitHub. That said, what you see there only scratches the surface in terms of how contributors can join in on the development. We do not write monolithic software projects, and there is a lot of encouragement to strip existing large projects into smaller, manageable pieces. Contributions may not necessarily have to be exclusive to contributing code directly to our projects.

You may find that you'd like to help separate complex functionality into a new crate with a higher quality standalone implementation. Or perhaps you'd like to integrate one of your crates into our projects, provided that they have use in our software. There's a general practice in the Rust community to share as much code as possible with the greater community, and do as little reinventing as required.

Contributions do not have to be towards fixing bugs or implementing new features, either. It may be as simple as refactoring the existing code as you get acquainted with our project. Refactoring is always welcome if the refactored code contributes to easier maintainability or readability. If you find functionality which lacks unit tests, of which there are many such areas, you may contribute unit tests as well. Suggestions are also welcome, as are general bug reports and feature requests.

Contributing as a Community Member

Sometimes the best way to contribute is to simply be around to offer advice and insight. When the community has questions, it's great to have regular members who are around to answer those questions, provide perspectives, and spread knowledge. That reduces the burden on Pop's maintainers and support to tackle every community question that comes by. Help others, and you may find them helping you in the future.

If you are a programmer, working together on community projects is a great way to move the Pop community forward. Software projects which may not necessarily be a part of the Pop desktop, but are useful to the Pop community, are just as important as the core Pop projects. The Pop Planet has a Mattermost API and Mattermost GTK project, for example, which would be useful to every member of the Pop community, including the Pop engineers.

Contributing as a Writer

Documentation is perhaps the single-greatest way to benefit the community as a whole. The success of a Linux distribution; or anything, for that matter; is often attributed to the quality of their documentation and official resources. Imagine what Arch would be like without the Arch Wiki, or Linux itself if the Arch Wiki was not around as a resource. The Linux desktop is dominated equally by open source software development, and the documentation of that software. Actually, documentation may be even more important than the software itself.

All of the documentation on the System76 website is generated from this repository hosted on GitHub. If you know how to write documents in Markdown, you're ready to contribute. Everyone is welcome to improve, discuss, and contribute their own quality articles to our documentation project, and have that work hosted on our website. Similarly, the Pop! Planet has its own mechanisms for documentation in the Wiki, which makes discovery and navigation easier.

Contributing as a Packager

Ubuntu has a feature freeze, but Pops are never frozen, unless they are of the 'sicle variety. If you have a desktop project that would be useful to add to our repository, you're free to request to have your packaging included. If you have a patch for an existing project, feel free to submit an issue to our Pop GitHub repository with your patch, and we can investigate including the patch. We may not be able to accept every request, but the opportunity will always be there. This is a particularly tricky area, however, as packaging comes with the burden of maintaining those packages.

 

[derpOmattic]

Onboarding process! A timely and necessary post, and hopefully a step in the right direction. I'm onboard with Pop!_OS and happy to do anything that I feel confident and capable of within the time constraints of business.

 

[lucas]

Hello! I'm a frontend JavaScript developer by day. A couple months ago I started dabbling in Rust for no reason other than "it seems cool". So far I haven't done anything more significant than the exercises in The Book and the first project in the Rust-wasm book.

I'd love to contribute on the programming side though I'm sure I'd need to get better at Rust first. I've poked around the Github and it looks like there are a few things here and there labeled "first issue" so it looks like there are some low-stakes places where I could test my chops. I basically want to contribute and develop my own skills, without other people feeling like they're having to hold my hand.

 

[mmstick]

I'd love to contribute on the programming side though I'm sure I'd need to get better at Rust first.

If you haven't already, the challenges at Advent of Code are pretty useful for gaining experience in any programming language. You can change the year in the URL from 2015 up to 2018. There's a new set of challenges each year in December.

I've poked around the Github and it looks like there are a few things here and there labeled "first issue" so it looks like there are some low-stakes places where I could test my chops. I basically want to contribute and develop my own skills, without other people feeling like they're having to hold my hand.

There are many possibilities for contribution here, many of which don't have issues created for them:

Refactoring a code base is a great way to learn how it works, and helps us maintain our projects so that we can focus more on developing new features. I generally have a very high level of trust in refactoring PRs for Rust projects. Any form of refactoring to improve the quality of our code is welcome.

Adding unit and integration tests is also really helpful. We have a lot of code which lacks unit and integration tests at the moment, particularly because it takes a while to properly set this up for some types of tasks which aren't easily mocked.

If you have an idea to improve some of our projects, you can submit them as issues for discussion, and then begin working on it once it's been accepted. If you need help getting acquainted with a project's code, I can elaborate the where and why if the code isn't explicit enough.

If you have an idea for a crate which would help us out, you could develop it, publish it, and tell us about it. You may also try out our crates in your projects and give us feedback / PRs to improve our APIs. Many of our current crates haven't had much testing outside of our specific use cases.

Even if you don't contribute directly, writing Rust crates may help us out somewhere down the road.

 

[bitspace]

Now I have a reason to take a look at Rust 25 years of experience developing software, most of it with Java, the past couple of years with ES and node, the earlier years with perl and C, and linux being my base for the entire time. I've always had an interest in different programming languages and have dabbled in everything from lisp to assembly to erlang to Go. My day job these days is nodejs lambda functions in AWS, so lots of YAML/CFT and trying to convince my colleagues that golang is a better choice for lambda functions than node/ES.

I am curious about the thought process behind Rust as the choice for the glue of Pop!_OS.

 

[derpOmattic]

I'm sure a personal reply is forthcoming , but in the meantime 'Getting started with Rust' may help to explain.

 

[mmstick]

I am curious about the thought process behind Rust as the choice for the glue of Pop!_OS.

System76 hardware projects include a mixture of C, where required, and Rust, where possible. Firmware tools, and soon to be open source firmware itself, are written in Rust by our engineering manager, Jeremy Soller. He's also the BDFL of Redox OS, which is an entire microkernel-based desktop OS written from scratch in Rust, and a popular topic of interest in the OS dev community. The mandate to use Rust applies both for hardware and Pop projects.

There's much to like about Rust. It's a systems language for the modern era, which has merged many modern high-level concepts with low-level programming to create a language which is equally useful on either end of the spectrum. It does a better job than C at the low end, and C++ at the high end. In some ways, it can accomplish tasks easier than a managed language, when high level APIs are available for that domain.

Systems languages should be the choice for developing an OS and surrounding desktop platform. The only reasonable options in that space are C, C++, and Rust. if you're developing a platform today, Rust should be the obvious choice, as C++ and C were during their times.

Rust brings many critical features to OS development:

• Cargo crates make it easy to share pieces of specific, sometimes generic, functionality across projects. The Crates.io ecosystem provides a wide range of low and high level types and functionality. Importing them into a project is trivial with Cargo.
• The standard library is built around algebraic data types and trait-based generics. This makes the standard library and error handling fantastic to work with.
• The language itself is built from the ground up around static code analysis techniques, which makes the final product reliable when deployed to production. Some of our projects work on levels that are really dangerous, so you want something that you can depend upon, and which forces you think about how to handle every possible error case, even if it's just to pass up an error with details to write in a log or display to the user.
• Multi-threaded and concurrent programming is very simple, with compile-time checks to validate whether your shared or moved data can be used in and across thread boundaries in the manners that you're using them.
• Traits bring a lot of possibilities to the table when designing and using high level APIs. They are standardizing behaviors, and make it easier to interface different types across different libraries. Instead of taking a T as an input, you could take any type which could Into<T> or AsRef<T>, for example. Type-specific functionality can be separated, and behavior-specific functionality shared.
• Traits also bring in a lot of useful functionality, such as the Iterator and Future APIs: state machines which are constructed and later lazily-evaluated on demand.
• Trait-based generics also make it easy to perform mock unit testing, using separate code paths when testing internal APIs, which would otherwise be handling inputs from system-specific I/O.

Scripting languages aren't an option. Reliable software today is being built around languages with compile-time static code analysis. Ideally we want a low memory and CPU footprint to increase battery life and decrease the overhead of our services and applications. Even managed languages have difficulty living up to the static guarantees that Rust provides for thread safety, and reliable memory handling.

 

[bitspace]

Lots of info, thanks - definitely not criticizing the choice. I'm completely ignorant of Rust, have never found any use for C++. You've given me some things to read to learn!

 

[mmstick]

Lots of info, thanks - definitely not criticizing the choice. I'm completely ignorant of Rust, have never found any use for C++. You've given me some things to read to learn!

C++ has largely collapsed under its own complexity. Getting started with C++ can be very difficult, as you really need to know what you want to accomplish, and how to accomplish it, and with what subsets, libraries, and compilers of C++, in advance. The general recommendation is to aim for a "modern C++" with the latest standard you can support, and using the best practices available for that standard. Yet the optional best practices in C++20 are core, even enforced, principles in Rust.

Getting started in Rust is as easy as cargo new project-name to create a base template for a Cargo project, pulling up API docs for Rust with rustup doc --std, searching for crates to use on either crates.rs or crates.io, and pulling up API docs for crates at any time with docs.rs/crate-name. Internalizing the rules of Rust's borrow checker may take some time, though. Coming from Go, you'll be familiar with how rustfmt works by running cargo fmt from within a project.

Rustup is a bare essential for gaining access to different toolchains, targets, and components of Rust for development. RLS is required to get IDE support. Most editors and IDEs are supported today, though some work better than others. If you plan to develop anything for Pop, it must be compatible with whichever toolchain is described in the rust-toolchain file in our repos. rustup and cargo will automatically use the toolchain defined in that file, so it shouldn't be much of a problem.

If you're experienced in Node, Cargo is very much equivalent to NPM, plus serving a lot of additional tools for building and managing your Cargo projects. In fact, the NPM registry itself is written in Rust today, as opposed to JS/Node. There was a case study on that here.

There's a lot of focus by the core team to work on enhancing Rust's offerings in both backend and frontend (WASM) web development. Actually, the Rust team has a community which is organizing around a collection of working groups, which you can join if you want to. Each domain of interest has a working group, and there are some internal working groups that are focused on specific areas for Rust as a language, such as the "Async & Await" group.