How to become a contributor

This is an unlisted, ad hoc draft, to act as a placeholder in order to provide a link that can be used in other articles and a place to define what content is in scope or not.

If you’re a user looking for the actual information presented with proper formatting, please see the article on the same topic. This draft will most likely remain difficult to read for some time due to the lack of structure and proper formatting.

Gather information from the following articles:

Get involved
Writing tutorials
Development (patch)

Link to How to create a mirror, but keep that article out of scope for this since it has another target audience.

Link to How to become a tester, but keep that article out of scope for this, which is focused on producing the content to be tested.

Introductory summary.

Table of contents.

There is primarily the product, the Chakra™ operating system. There are also online services, including but not limited to a GitLab EE installation at, a Discourse installation at, and the two websites and

The Discourse installation is primarily meant to provide a means of technical support on how to install and use the product, by and for the community. There are three principal categories with distinct functions, here listed in the desired order for users to proceed in:

  1. #tutorials, description topic here, instructions on subjects pertaining to the installing and usage of the product
  2. #help:faq, description topic here, frequently asked questions, here with answers
  3. #help, description topic here, should neither of the previous two help, one may find others with the same question here, or ask oneself

One may send an e-mail to to post a topic in #help, or register an account to participate. There are different access levels, “Trust Levels”, briefly like so; the #meta category is not displayed unless you are logged in, and you may not post there until you reach TL1. The #lounge category is for offtopic discussions and pretty much anything goes as long as it isn’t abuse. Shitposting and memes are fine. I would recommend avoiding politics, religion, or other controversial topics.

The GitLab EE installation provides source code management (using the git version control system), as well as common software development utilities such as issue tracking. In general, based on &5:

  1. A user will encounter a bug in the product
  2. The users reports said bug on the issue tracker
  3. A developer will create a merge request for said issue with a fix for said bug
  4. The CI/CD will build the new code – if it fails, return to step 3.
  5. Testers will perform a quality control (does the fix work?), and if it is as it should, the merge request will be approved – if not, review discussions on the merge request will need to be resolved
  6. If approved, the merge request may be merged by a project maintainer (subject to change)
  7. The newly built version of the product will be made available to the public

One may send an e-mail to to create a new confidential issue in, or register an account to participate. Documentation on how to use GitLab EE is available here. There are different access levels, and I will refer to the documentation on that. The current setup we use I would describe like so (groups are in bold, projects are not):

  • Chakra
    • Akabei
      • Akabei core library
      • Akabei client library
      • Akabei frontend
    • Packages
      • core
      • desktop
      • lib32
      • gtk
    • Build system
    • Calamares modules
    • Continuous integration scripts (see website#118)
    • Docker base image (merge with below into “Docker image”? See website#117)
    • Docker makepkg and live media images (merge with below into “Docker image”? See website#117)
    • GFXBoot theme
    • Hardware detection scripts
    • Heritage
    • Keyring (an initiative by me to replicate the Arch Linux equivalent, and to better understand the topic, see core#169)
    • Live media
    • Website
    • Welcome plasmoid
  • Testers

The idea of the Testers group is to enable those willing to quickly get into the workflow and make use of their feedback directly in merge requests, giving them the right to approve or point out mistakes. This way of using GitLab EE regrettably broke recently, see website#156.