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. 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.