Add: list of things for getting started contributing

1 files changed, 81 insertions, 0 deletions

diff --git a/getting-started.mdwn b/getting-started.mdwn
new file mode 100644
index 0000000..9a21bab
--- /dev/null
+++ b/getting-started.mdwn
@@ -0,0 +1,81 @@
+[[!meta title="Ick—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.
+
+
+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.
+
+
+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 packaing of ick. Suggest improvements.
+
+* Add packaging for other systmes: 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 featureful 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, suchas 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.