In detail

Following the kind of contribution (new additions, fixes or upgrades), these simple steps will allow you to start contributing to guix:

git clone guix itselft
from the guix repository, do:

sh guix shell -D guix -CPW ./bootstrap ./configure make -j$(nproc) ./pre-inst-env guix build hello add and commit your changes, watch the commit message
beware your synopses and descriptions
remember to run the package tests, if relevant
check the license
use an alphabetical order in input lists
no sign off your commits
don’t forget to use lint/style/refresh -l/dependents to check your code

Boring and routinary, right ?

Use sourcehut

Most of all the of the previous can be run automatically with help of sourcehut build farm #ci capabilities. Just simply, push the guix repository to sr.ht. At this point, it is possible to use this manifest file to run the lint/style/refresh -l/dependents testing stages on the yosys package definition, por example:

image: guix
shell: true
environment:
  prj: guix.guix
  cmd: "guix shell -D guix -CPWN git nss-certs -- ./pre-inst-env guix"
sources:
  - https://git.sr.ht/~csantosb/guix.guix
tasks:
  - def_pkg: |
      cd "$prj"
      _pkg=$(git log -1 --oneline | cut -d':' -f 2 | xargs)
      echo "export pkg=$_pkg" >> "$HOME/.buildenv"
  - setup: |
      cd "$prj"
      guix shell -D guix -CPW -- ./bootstrap
      guix shell -D guix -CPW -- ./configure
      guix shell -D guix -CPW -- make -j $(nproc)
  - build: |
      cd "$prj"
      eval "$cmd build --rounds=5 $pkg"
  - lint: |
      cd "$prj"
      eval "$cmd lint $pkg"
  - style: |
      cd "$prj"
      eval "$cmd style $pkg --dry-run"
  - refresh: |
      cd "$prj"
      eval "$cmd refresh -l $pkg"
  - dependents: |
      cd "$prj"
      eval "$cmd build --dependents $pkg"
triggers:
  - condition: failure
    action: email
    to: builds.sr.ht@csantosb.mozmail.com

Submit the manifest with

hut builds submit # --edit

You’ll be able to log into the build farm to follow the build process or to debug it with

hut builds ssh ID

Check the log here. As you can see, it fails: building of yosys succeeds, but building of packages which depend on it (--dependents) fails.

Advanced

Sourcehut provides a facility to automatize patch submission and testing. Using its hub integrator, one may just send an email to the email list related to your project (guix in this case), which mimics guix behavior for accepting patches.
The trick here consists on appending the project name as a prefix to the subject of the message, for example [PATCH project-name], which will trigger the build of previous .build.yml manifest file at the root of the project, after applying the patch. Neat, right ?
If you followed right here, you’ll notice that previous build manifest file is monolithic, affecting always the same package (yosys), which is kind of useless, as we are here interested in testing our patch. Thus, the question on how to trigger a custom build containing an updated $pkg variable related to the patch to test remains open.
To update the contents of the $pkg variable in the build manifest, one has to parse the commit message in the patch, extracting from there the package name. This is not a problem, as guix imposes clear commit messages in patches, so typically something like

* gnu: gnunet: Update to 0.23.0

or

* gnu: texmacs: Add qtwayland-5

Hopefully, parsing these messages to get the package name, and so the value of $pkg is trivial.
Then, it remains to include in our build manifest a first task which updates the contents of "$HOME/.buildenv". This file is automatically populated using the environment variables in the manifest, and its contents are sourced at the beginning of all tasks. This mechanism allows passing variables between tasks.

echo "export pkg=value" >> "$HOME/.buildenv"

Send your contribution

Finally, once your changes go through all the tests,

use git send-email to create and send a patch
consider reviews, if any, updating your patch accordingly with git ammend
resend a new patch including a patch version (v1, v2 ...)

Interested ? Consult the documentation for details, you’ll learn a lot about how to contribute to a common good and collaboration with other people.
#ciseries

sourcehut

#Sourcehut, as a collaborative platform, deserves special attention. It departs from mainstream forges, following a different paradigm based on the most robust, distributed and flexible technology at our hands since decades, plain text #email. Git, since its origins, includes a close integration with email, as they both share a distributed philosophy, avoiding central point of failure silos (surprising how mosft git forges tend to concentrate in silos). Sourcehut core architecture is based on mail exchange, patches and #maillists, which turns out to be a much more flexible approach than that of what most forges propose. Their concept of project goes well beyond that of usual workflows, integrating nicely git with email, wikis, bug trackers and build features. They’re still in an alpha stage, so expect the best still to come.

git

git.sr.ht/~user/project, #git repositories.
There are no groups to combine them. I use dot notation to group my projects git.sr.ht/~user/group1.prj1.

builds

builds.sr.ht/~user, task building service, with the list of builds by the user, with user’s recent activity.
builds.sr.ht, similar to the previous.
Builds are trigger by a .build.yml manifest, or by a .build folder folder with up to 4 manifest files, at the root of a project.
It is also possible to automatically submit builds when a patch to a repo with build manifests is sent to a mailing list. This is achieved by appending the project name as a prefix to the subject of the message, for example [PATCH project-name].
Check doc for details.

hub

The main tab, sourcehut, gives access to the hub hub.sr.ht/~user (identical to sr.ht/~user).
The hub displays user’s projects.
Projects are groups of git repositories, #maillists and bug trackers. There may be any of them in a project.
Sourcehut itself is organised as a project here https://sr.ht/~sircmpwn/sourcehut, and may be used as an example.

todo

todo.sr.ht/~user, ticket tracking service, with the list of trackers created by the user, with user’s recent activity
todo.sr.ht, similar to the previous

man

man.sr.ht/~user/NAME, #wiki service to create documentation, with the wikis created by the user
man.sr.ht, sourcehut documentation
man.sr.ht/builds.sr.ht, builds service documentation
man.sr.ht/hub.sr.ht, hub service documentation, etc.

lists

lists.sr.ht/~user/NAME, #email #maillists service, with the list created by the user, with user’s recent activity
lists.sr.ht, lists the user follows, with recent activity

Extra services are alse provided:

chat

chat.sr.ht, without the user alias, is a paid service. It provides a bouncer to save history of IRC channels while not connected, and may be used from another IRC client.

paste.sr.ht

Paste hosting service.

srht.site

Once again, the official documentation gives in depth details about the previous. And remember, there is also hut to operate from the #cli.

usual suspects

Other than guix channel itself, you may have a feeling of what a guix channel looks like taking a look at the guix-science organization. In there, you’ll find collections of package definitions intended to be used in a context of specific research domains, both in its free and nonfree forms. For one reason or another, they have not their place in the main guix repository, and they live their life in here. Interesting enough, guix-past channel brings old-fashioned software to the present, which reveals useful to reproduce results older than guix itself. Another interesting examples are guixrus, by the ~whereiseveryone collective, providing packages not yet fully tested, nightly releases or alpha quality software; or the guix-hpc channel, with packages related to high performance computing; also guix-bioc, containing bioconductor packages, etc. You get the idea.
To include additional channels, other than the default ones, in your ~/.config/guix/channels.scm file, follow the documentation, and check with guix describe: you’ll get a list of all the channels in use next time you do a guix pull. At this point, you’ll have plenty of new packages to install at your hands ! Just remember the discussion about substitutes: some channels provide substitute servers, some not. This might be an issue, or not, depending of the computing resources necessary to build certain packages.

your first personal channel

Guix channels are simple to create and use. Just put your #guile modules, containing your package definitions, in a git repository. To use them, complete the default guix load path as in

guix install -L ~/guix-channel PACKAGE

You may opt to include this local channel into your ~/.config/guix/channels.scm file, or include the -L flag in your commands. As an alternative, guix searches for package definitions in the $GUIX_PACKAGE_PATH, so you may put your channel path in this variable. Remember that guix builds packages by compiling source code: no substitute server will do the job for you in this case, so plan accordingly with your local resources and patience.

electronics channel

This is about #modernhw after all, so let’s see an example more on detail, my own guix-electronics channel which complements the ./gnu/packages/electronics.scm guix module. This is the channel I’m using daily, where I include all the packages I need and doesn’t yet exist upstream. When they get merged somewhere else, I remove them from here. In the meantime, I’m a happy user of my custom packages.
I classify all my package definitions in #guile modules under ./electronics/packages/MODULE.scm. This is the reason why the compilers module, for example, starts by

(define-module (electronics packages compilers)

Then, proceed as usual (check the guix repo itself for inspiration), putting your packages below

(define-public mypackage
  (package
    (name "mypackage")
    ...
    ))

I create a git repo, commit my changes and push it online to a #gitforge.
I need a .guix-channel file with the url of my channel and a version number. If the code in the channel depends on other channels other than main guix channel, one needs to specify this information in this file too. In this case, for example, several of the package definitions include a dependency on ghdl-clang, provided by guix-science channel, so I need to declare it in here too.
It is also necessary a .guix-authorizations file, with the (GPG key) list of developers with right to push to this channel. This is how guix authenticates channels. Finally, it is important to create a readme file or similar where introduce the channel (first commit, signing key fingerprint). That’s it. Include the channel introduction into your ~/.config/guix/channels.scm file, and you’ll be pulling from your online guix channel.

contributing

The advantage of using a custom channel is to benefit from an increased degree of freedom when using guix, without being dependent of someone’s else time availability to consider your particular needs. Remember, guix is a huge project which follows closely the #freesoftware paradigm, and collaboration works in two directions. You take advantage of other developers contributions to guix, while you participate yourself to improving guix repositories with your package definitions, once they have been tested.
Take for example the list of packages in my electronics channel. I have included here utilities for #vhdl code editing under #emacs, specific to the electronic digital design field, which are not yet available in guix upstream channel. There is also a cosimulation library, #cocotb, which allows coupling #python and #ghdl to simulate a design. I have submitted a patch to include this in guix itself, similarly to python-vunit; once merged, I’ll remove them from here.
Some packages, like open fpga loader are now part of guix. Some others, like the gnat ada compiler and ghdl-clang stable have been merged already on guix-science, as gnat package is obtained from binaries (and so ghdl-clang is also impacted, from guix perspective). I include here a more recent ghdl-clang, non yet released, as it includes some fixes and improvements I am interested in, without having to wait until guix incorporates a new release.
Catch the idea ?
Contributing your code to guix comes to sending #email with your patches attached, it’s that simple. Dont be intimidated by the workflow (this is used by the linux project, for example). Once your patches are submitted, a review of your code folllows, see details. Some tools, like mumi, are helpful to that purpose.
These simple steps will allow you to start contributing to guix:

• git clone guix itselft
  
• add and commit your changes, watch the commit message
  
• don’t forget to use guix lint/style/refresh -l to check your code
  
• use git send-email to create and send a patch
  
• cosider reviews, if any, updating your patch accordingly with git ammend
  
• resend a new patch including a patch version (v1, v2 ...)
  

Interested ? Consult the doc for details, you’ll learn a lot about how to contribute to a common good and collaboration with other people.