About you
- What Free Software projects did you contribute to? Please provide URLs that show what you have done by yourself. It does not need to be code: bug reports, meaningful discussions, mentoring, etc. are equally important.
- What are your areas of expertise (use
[x])?- User Interface
- User eXperience
- Web design
- Infrastructure
- Sysadmin
- Development (whatever the programming language)
- Community management
- Funding
- Mentoring
- Project management
Your Free Software contributions
- I installed Ubuntu onto several laptops
- I used Compiz and Pantheon
- I installed elementary OS
- I wrote a lot of Upstart jobs
- I bought a Chromebook to take notes during class
- I bought a used Thinkpad because the Chromebook was trash
- I used Arch because that is what was installed
- I did not bother with Arch much, I was too busy with school
- I learned R and Python to some degree, mainly in connection with statistical analysis and graphing
- After I graduated school I switched Void Linux for Arch, and started hacking on Upstart again
- Released my changes as "Startup" via GitLab
- Had CI going, the test suite passing, no trademarks being violated
- Fixed some issues in Upstart around quirks in the event system
- Mainly just integrated with the new software I was using, namely Sway
- Used startup as both my system and session/user service supervisor
- Main configuration focus was the user services
- Now have pipewire integrated pretty well, including service readiness notifications
- Also worked on some graphics-adjacent software: brillo, a CLI brightness utility that I forked from light
- Added lots of interesting features to brillo, forked because light went in a weird direction with the codebase
- Namely, brillo supports smooth adjustments to the brightness instead of stepped
- Like the backlight fades in and out when I press the brightness up/down key, or when my laptop is idle too long
- Also forked gammastep from redshift, and released with Wayland support
- Patches had been submitted to redshift, but the maintainer went AWOL
- I notified the maintainer that I intended to fork and release if there was no activity
- I released with wayland support and all of the former maintainer's emails scrubbed (but not names or copyrights)
- Updated the docs
- Have accepted up some follow up PRs to improve the user experience
- I try to release when some fix is available, and respond to bug reports and PRs promptly
- Most bug reports are actually upstream issues, but no biggie
- I work with the Void Linux team a lot
- I improve docs, package new software, submit package updates, review packaging PRs
- Void Linux uses GitHub for so much
- The free CI is hard to pass up, apparently
- My packaging work with Void Linux has led me to interact with numerous people whose software I package
- I file bug reports and submit PRs to fix musl build issues, or cross compilation build issues, or other integration issues
A successfull contribution
User reported an issue with too much storage being used for their Podman installation.
User suggested a reason.
I looked deeper into the issue and how I had packaged Podman.
I submitted a fix that added configuration for users to use the low-storage option.
A difficult contribution
I submitted a new module to NixOS. The NixOS module configured and enabled Envoy (the reverse proxy). I was not quite familiar with Nix or NixOS prior to working on the module, neither the nixpkgs test framework.
A failed contribution
I could not get enough buy-in from the maintainers to merge support for a non-forking readiness protocol into swaylock. That and I left the PR stale after some time.
<!--
[User Research](https://jdittrich.github.io/userNeedResearchBook/) is about observing how you use tools when creating Free Software. Ideally we would sit with you and take notes. This would give us clues about the challenges you are facing, how you overcome them. And also what you find useful, the patterns that help you be an efficient Free Software contributor.
This survey is a kind of shortcut that saves you and us valuable time. All you are expected to do is tell the story of what you did, as you remember it. Just the facts, in chronological order. There is no need to write down a story that is nice to read: bullet points are perfectly fine.
As much as you'd like to give your interpretation of why something was good or difficult, this is not in scope for this survey: it is all about collecting the facts that make your own personal experience unique. All the surveys will then be compiled and analyzed to get a idea of the [mental models](https://en.wikipedia.org/wiki/Mental_model) common to most Free Software contributors.
The Forgejo roadmap will use this output to figure out what matters most, what should be adressed first and why, based on factual evidence that you provided. It would be faster to rely on the decision of project leads. But, however brilliant they are, it will only reflect their own view of the world and not the diversity of Free Software contributors.
It takes time to build a user centric roadmap and there is no guarantee that what matters to you most will end up there. But it also is the best way for your voice to be heard and make a difference.
-->
# About you
- What Free Software projects did you contribute to? Please provide URLs that show what you have done by yourself. It does not need to be code: bug reports, meaningful discussions, mentoring, etc. are equally important.
1. https://github.com/void-linux/xmandump/pull/10
1. https://github.com/void-linux/void-packages/pull/5069
1. https://gitlab.com/chinstrap/linit/-/raw/master/README.md
1. https://gitlab.com/chinstrap/ready
- What are your areas of expertise (use `[x]`)?
- [ ] User Interface
- [ ] User eXperience
- [ ] Web design
- [X] Infrastructure
- [X] Sysadmin
- [X] Development (whatever the programming language)
- [ ] Community management
- [ ] Funding
- [ ] Mentoring
- [ ] Project management
# Your Free Software contributions
<!--
Tell your story (actual experiences, not imaginary ones) however you feel more confortable.
Please remember that raw facts, in chronological order, are what we are trying to collect and what is most useful in the context of this survey. Here is an example of a useful story:
I created a bug report at https://codeberg.org/forgejo/forgejo and got a solution within a the hour.
* I visited https://codeberg.org/forgejo
* I noticed https://codeberg.org/forgejo/forgejo because it had a logo
* I clicked on the link and saw https://codeberg.org/forgejo/forgejo
* I clicked on "Issues" and saw https://codeberg.org/forgejo/forgejo/issues
* I typed "pipeline" in the **Search** input box and pressed enter
* The results show a few issues although none of them had pipeline in the title which led me to the conclusion that the search was also on the issue description
* None of the issue titles was a match for the problem I was facing
* I clicked on **New Issue**
* The first choice was **Bug Report** and I clicked on the **Get Started** button
* etc.
-->
* I installed Ubuntu onto several laptops
* I used Compiz and Pantheon
* I installed elementary OS
* I wrote a lot of Upstart jobs
* I bought a Chromebook to take notes during class
* I bought a used Thinkpad because the Chromebook was trash
* I used Arch because that is what was installed
* I did not bother with Arch much, I was too busy with school
* I learned R and Python to some degree, mainly in connection with statistical analysis and graphing
* After I graduated school I switched Void Linux for Arch, and started hacking on Upstart again
* Released my changes as "Startup" via GitLab
* Had CI going, the test suite passing, no trademarks being violated
* Fixed some issues in Upstart around quirks in the event system
* Mainly just integrated with the new software I was using, namely Sway
* Used startup as both my system and session/user service supervisor
* Main configuration focus was the user services
* Now have pipewire integrated pretty well, including service readiness notifications
* Also worked on some graphics-adjacent software: brillo, a CLI brightness utility that I forked from light
* Added lots of interesting features to brillo, forked because light went in a weird direction with the codebase
* Namely, brillo supports *smooth* adjustments to the brightness instead of stepped
* Like the backlight fades in and out when I press the brightness up/down key, or when my laptop is idle too long
* Also forked gammastep from redshift, and released with Wayland support
* Patches had been submitted to redshift, but the maintainer went AWOL
* I notified the maintainer that I intended to fork and release if there was no activity
* I released with wayland support and all of the former maintainer's emails scrubbed (but not names or copyrights)
* Updated the docs
* Have accepted up some follow up PRs to improve the user experience
* I try to release when some fix is available, and respond to bug reports and PRs promptly
* Most bug reports are actually upstream issues, but no biggie
* I work with the Void Linux team a lot
* I improve docs, package new software, submit package updates, review packaging PRs
* Void Linux uses GitHub for so much
* The free CI is hard to pass up, apparently
* My packaging work with Void Linux has led me to interact with numerous people whose software I package
* I file bug reports and submit PRs to fix musl build issues, or cross compilation build issues, or other integration issues
## A successfull contribution
User reported an issue with too much storage being used for their Podman installation.
User suggested a reason.
I looked deeper into the issue and how I had packaged Podman.
I submitted a fix that added configuration for users to use the low-storage option.
## A difficult contribution
I submitted a new module to NixOS. The NixOS module configured and enabled Envoy (the reverse proxy). I was not quite familiar with Nix or NixOS prior to working on the module, neither the nixpkgs test framework.
## A failed contribution
I could not get enough buy-in from the maintainers to merge support for a non-forking readiness protocol into swaylock. That and I left the PR stale after some time.
https://github.com/swaywm/swaylock/pull/42