[[!meta title="Getting started with contributing to the project"]]

If you like ick or would like to contribute to help make it better, we
would love to have you join us!

This page has some suggestions for how to get started with that. Some
things are really easy, others will need more effort and commitment,
but you may well find a small thing to move the big thing further. How
much you want to do is your choice. You can contribute as little or as
much as you want.

First things
=============================================================================

You probably want to start with these kinds of things.

* Use ick. Set up instance for your own use. Report any problems in
  the process, any missing information from documentation, any unclear
  parts, anything that is inconvenient, etc.

* If you have access to the hardware, do some ick stress testing. Set
  up an ick server with a very large number of workers, a very large
  number of projects to build, and see if ick can handle that. Report
  the problems. The unofficial wish is for Ick to handle 1000 worker
  nodes building 1000 projects concurrently.


Documentation things
=============================================================================

* Read the ick website. Is anything confusing, weird, or looks wrong?
  Can you spot the typo? Where should we insert a picture of kittens?

* Write, or outline, some user-oriented documentation. There is a
  skeleton manual page for `icktool`, add to that. Write a completely
  separate manual, either adding it to the ick source tree, or as a
  completely separate project. If you don't know something, ask.


Development things
=============================================================================

* Build ick locally. Check out the source from git. There's no build
  process (given it's in Python), but run the full test suite: run
  `./check` at the top of the source code tree. This is especially
  useful if you don't use Debian 9 (stretch) on the amd64
  architecture. Report any issues.

* Review all the ick source code. Is anything confusing, weird, or
  looks wrong?

* Read the ick
  [[architecture]] document. Is
  anything confusing, weird, or looks wrong? Do you get a feeling you
  understand how ick is designed at a high level?

* Review any [[open tickets|issues]]. Is there any issue you can help
  with?

* Review the Debian packaging of ick. Suggest improvements.

* Add packaging for other systems: Fedora, RHEL, OpenSuse, Gentoo,
  Arch, CentOS; etc. Offer to maintain that in the future. Suggest
  ways in which that could be done, and how the workflow should be.

* Make a web UI to do the equivalent of `icktool status` (a read-only
  operation). Design a more powerful web UI that can do everything
  you'd like to do with a CI system. (Read-write operations will need
  to wait until ick gets a good IDP that supports web applications,
  but that is happening.)


Advocacy things
=============================================================================

* Compare ick with other CI systems, such as Jenkins, BuildBot, go.cd,
  Travis, GitLab CI, etc. How do they compare with ick? Write up a
  short report. Or a long report, if you feel like it. (We don't
  expect anyone to prefer ick at this stage.)

* Write a short article, long article, list of bullet point, on what
  you personally would like to have in a CI or CD systems. Especially
  useful if describe how ick would need to change for you to want to
  start using it yourself.