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.

 

[justXuX]

Hello, my name is John. I am using Linux since 2011, but was distro-hopping a lot, until I used Pop!_OS for 2 weeks already and I fell in love, in my opinion it's the first distro I can recommend to others.
So I want to contribute to the project. I am novice in programming, can write documentation, can help people in chat or forums the best I can or test things out and give suggestions to improve Pop!_OS from experience accumulated over years of distro-hopping. I think getting the best from other distros and mitigate the worst will increase user base in Linux as a whole and improve experience. Thanks for all your hard work.

 

[mmstick]

Hello, my name is John. I am using Linux since 2011, but was distro-hopping a lot, until I used Pop!_OS for 2 weeks already and I fell in love, in my opinion it's the first distro I can recommend to others.
So I want to contribute to the project. I am novice in programming, can write documentation, can help people in chat or forums the best I can or test things out and give suggestions to improve Pop!_OS from experience accumulated over years of distro-hopping. I think getting the best from other distros and mitigate the worst will increase user base in Linux as a whole and improve experience. Thanks for all your hard work.

You can hang out in our Mattermost chatroom if you'd like to give support. We do questions in there from time to time. You can submit improvements to our documentation on GitHub, or even help out with documentation here on the planet wiki. Testing pull requests and giving feedback on them can be useful. That helps out QA if you're able to spot and report some issues so that QA doesn't have to stumble on them.

You'll want to learn Rust if you want to contribute code, since most of our projects are written in it. Luckily, there are a lot of great resources for Rust on Rust's website. You can majority of the Rust community on Reddit if you have questions about Rust / want advice on your code.

 

[craigtaro]

Hi - I'd be interested in helping as a writer. As I was reading through some of the documentation I noticed a typo/grammar issue and thought "there's something I could fix". So I've cloned the GitHub documentation repo and found the document.... I'm just not sure what the approved process is from this point. I've used Git in a limited fashion so I understand the basics. I'm just curious if there's a specific workflow to be followed. Or anything else I should be aware of before diving in.

 

[thealetree]

This is awesome. Getting traction and momentum with any community is tough, regardless of how great the purpose (Pop!_OS is AWESOME).

I'm just really starting to get jazzed about FOSS. Pop!_OS is the first linux distro that has really clicked with me 100%. I run it exclusively on my custom rendering rig at home.

In exchange for the awesome OS, I really want to contribute... But I don't really know how I would. I can write fairly well, but probably not in the software manual style/voice. I dabbled in Python, but never in Rust.

9-5, I do graphic design, branding, and 3D still/animation and audio production/recording (www.abodabobrand.com). I know those aren't really skills you're looking for, but I have to at least put it out there. Your icon set and theme are solid btw. Props to your designers.

Anyway I'm just really grateful and would love to contribute however, if ever, I can.

Thanks and please keep it up!

 

[mmstick]

9-5, I do graphic design, branding, and 3D still/animation and audio production/recording (www.abodabobrand.com). I know those aren't really skills you're looking for, but I have to at least put it out there. Your icon set and theme are solid btw. Props to your designers.

There are a lot of open source projects that are in need of graphic designers, UX designers, etc. It's one of the more rare talents in open source. Open source software is largely driven by programmers, but programmers often aren't that great at design. Perhaps you could donate some of these talents towards Redox OS?

I dabbled in Python, but never in Rust.

Opportunities are endless once you've learned it. There's a lot of PL theory to learn in order to use it effectively, though. There has been a sense that it's easier to learn if you aren't already experienced with some of the older languages. I suspect that's more to do with correcting the bad habits which Rust was designed to protect against.

 

[mmstick]

I'm just not sure what the approved process is from this point. I've used Git in a limited fashion so I understand the basics. I'm just curious if there's a specific workflow to be followed. Or anything else I should be aware of before diving in.

Regardless of where you contribute, our workflow is pretty simple. The maintainer of a project will review your changes, and then either provide feedback and request changes to your changes, or will approve and merge it. Some projects, particularly the repos that packages are built from, may require two approvals before they can be merged. This is most often one approval from a maintainer that can evaluate the implications of the code that was changed, and one approval from QA that the changes do what they say, and don't break anything.

If the changes are adding new items, or are making substantial changes, it's a good idea to open an issue to propose and discuss your ideas with the maintainers of the projects, so you have a good idea of what the best direction will be for that project. This will greatly increase the success rate of your merge requests when you submit them. When making substantial changes, it's also a good idea to open the merge request early as a draft, to enable discussion on the implementation as you develop it.

 

[thealetree]

? Thanks for the reply! Looking forward to 19.04

 

[ramdal]

Hi there. I am the pop os rep for Romania and i would like to help writing in markdown. Best regards.

 

[Xavier]

TL/DR: I want the external monitor configuration that I input to be persisted and used, where is the code that takes care of that.

Hello! I am a new user of pop although I've been running linux for years. I am an SRE with programming experience in Go, Java, Python, etc... I went through a brief tutorial about Rust about a year ago so I guess that doesn't class as "experience developer" Anyway, I just posted in the Laptop forum (https://pop-planet.info/forums/threads/external-monitors.125/) because I am experiencing a very annoying issue with external monitor configuration and I think it shouldn't be very difficult to solve, at least the part when the configuration entered by the user is saved. Could someone point me on the right direction if I want to look at it?

 

[mmstick]

TL/DR: I want the external monitor configuration that I input to be persisted and used, where is the code that takes care of that.

Sadly, that's not an area where you'd be able to use Rust. The HiDPI daemon is here, the monitors.xml file is configured by GNOME Control Center, and applied by Mutter. GCC and Mutter are written in C, so patches for those would also be written in C. The HiDPI daemon is written in Python.

 

[pup_atticus]

Hi there!

I am a recent college CS grad and have been looking for a good open-source project to contribute to for a while. I'm currently working as an automation engineer in a .NET environment, but I'm competent with programming in Rust and Python as well.

Let me know if you have any recommendations for projects to look into. I'll keep skimming through the pop GitHub projects to see if anything catches my eye. I've been using Pop OS for about a year now, so I'm happy to work on testing/documentation as well.