CAcert Software Development Team
How to start
This very much depends on your previous knowledge, and on what you want to do. First of all you should create yourself an account on the Mantis Bug Tracking system, and try to get a bit aquainted to it. This is the primary channel to communicate on specific tasks.
More generic communication is done on the mailinglist mailto:email@example.com. You'll probably have to subscribe to the mailinglist on the mailinglist server before being allowed to post messages to the list.
There's also an IRC channel #cacert-devel on the CAcert IRC server, but you have to be a bit lucky to find someone active there.
Testing bugfixes is often considered an easy task for newcomers, but you should not underestimate its complexities.
If you want to play around with the CAcert software without ruining your real account (or CAcert's productive database), our Testserver Management System allows you to set up your own account on the CAcert testserver.
If you need extended access, like the support console, an Org Admin's interface or something like this, ask on the mailinglist or contect one of the Software Assessors directly.
Keep in mind that there are many different ways of testing:
Reproducing error reports: IMHO this is the supreme discipline of testing. If there's only a single user's report about an error, the first thing to do is to check if you can provoke the same symptoms. Sometimes this is simple, usually because something quite basic is broken. But more often, if you do the same thing as the user (at least as you understand him or her) no problem can be found. In this case it's easy to write something about RTFM and blame it on a user error. But a good tester won't stop unless she really knows exactly what the user did to get the described symtoms, and then decides if this is indeed a user error (so the user manual has to be improved) or a software bug (so the software has to be improved or changed). And she can describe the peocess to provoke the error. This often includes getting into contact with the reporter and investigating what he really did, which is often quite different from how you initially understood his report! If you can do this you are a very useful tester in every software development process, not only CAcert's.
Verifying bug fixes: One level easier is the verification that an installed bugfix indeed does fix the bug. Ideally you have the detailed process how to provoke the error, and once the fix is installed you re-try this process and verify that everything works as designed. Then you try to think of a few variants and verify that they also work correctly. Than you start to be evil and try to break the bugfix by providing unexpected or "illegal" data. To become good in this discipline you usually have to be able to read the code relevant for the feature in question. And sometimes you are able to teach the software developers a lesson or two on good coding...
Generic testing of functionality: Though there are people who say that this would be better done by automated testing procedures (and they are probably right) we usually don't have such procedures for the CAcert software. So, when looking for unexpected side effects of a code change we still have to "play around" with the system. There has to be no explicit connection with any bugfix or other code change. Just think of something you'd like to do with the software and try to do it on the testserver. Or pick some feature of the software and try to find out how it works in detail, ideally adding the result of this experience to the user manual. Or just have a look around what all those menue entries really do. This also is a good way for newbies to get to know the more seldom used parts of the system, and a good basis to become a better tester. And maybe you even find a bug in a more obscure corner of the software which has hidden there for ages! Or you get an idea about how a simple additional menu item can massively improve the usability of the software.
Of course testing is made a bit difficult by the widespread absence of specifications and user manuals, so it's sometimes hard to say if a symptom is a bug or a feature. If you stumble over such a symptom, the best way would be to create or improve the documentation, see below.
... ToBeExtended ...
The very basic documentation about the current progress of specific cases is done directly in the Mantis Bug Tracking System, but we also need documentation with a wider scope, like specifications and descriptions of software modules, user and sysop manuals and much more HowTos about the development process.
This kind of documentation is mostly done here in then WiKi. So especially if you're interested in documentation you should ask for an account1 with write access to the wiki at firstname.lastname@example.org. Note: I have not verified this, and it is a long time abo when I got my account. So, if they tell you to ask somewhere else, it you be your first edit in the WiKi to correct this paragraph!
Which leads to the next thing, probably noone is better for writing HowTos for newbies than an ambitioned newbie! If you're new, there are thousands of things that all the veterans take for granted, but are still a total mystery to you. You can make life for the next generation much easier if you just collect the problems you are running into and put them into FAQs or HowTo. It's a bonus if you also find a solution to your problem, but even if you don't, maybe someone else does.
If you are in for the bigger things, the structure of information here in the WiKi is probably not ideal (if you allow me this euphemism). Many people have tried to find better structures, but usually with only small or very localised effects. You could bring the Software Team a big step forward, and maybe CAcert as a whole, if you had a good idea to organise the present information in a way which is easily maintained and allows easy recovery of knowledge. But expect to encounter some big difficulties here. And even small or localised effects can bring us a little step forward.
Before starting to write code it would be great if you have some basic knowledge about Git. You should know how to clone a project from a Git server (like GitHub), create a new branch or checkout and existing one, commit changes and push them back to the server.
At the moment we primarily use GitHub for "public" source management. Therefor, while not absolutely essential2, it makes some things easier if you have an account with GitHub, and know some basics about GitHub's Pull Requests.
Though in theory it is possible to work directly on GitHub without installing software locally3 it's probably better to use a local installation of Git on your own computer. Together with tools like for example KDiff or GitExtensions life's much easier...
Once you are somewhat familiar with Git, Software/WorkingWithGit shows you how we use Git in the CAcert development process.
You can find things to work on in the next paragraph, but you can also ask on the mailinglist or just browse the Bug Tracking System.
Bug#1417: Replacement of <keygen> tag, early stage of research
- Bug#1464: Creating an interface to allow script based issuing of certificates, early stage of research/evaluation
- Bug#1260: Make the source compatible with recent PHP versions, test and code review
- Proposals for future development envionment for server based tasks. We currently do most server based tasks in PHP, with a bit of shell- and Perl-Skripting in some corners. Some people have expressed that PHP may not be the ideal tool for clean, easily reviewable and secure coding. I personally see some truth in this, but yet noone has proposed a convincing alternative. There are currently some jobs (like creating an API mentioned in Bug#1464) which could be used as a "proof of concept" for alternatives, since they are comperatively unrelated to existing code.
... ToBeExtended ...
Some of the more "prominent" members, which you may contact personally if you are too shy to try the mailinglist.
Marek M. Mazur (observer)
- TimoAHummel (Felicitus)
- to be completed
Mantis Bug Tracking system has detailed stuff in it.
- patches can be developed for those issues and forwarded to the maillist
SystemTasks is a list of jobs that we'd like done one day.
Join the Developers' maillist.
Sourcecode is available from http://www.cacert.org/src-lic.php
Administer our Test Machine.
Software/Internships are possible for the brave!
Have a look
You can have a look at the development environment by yourself. The development workflow is described at the Development Workflow.
Of course, every community member is encouraged to ask for auch a WiKi account! We just had too many problems with spammers while write access to the WiKi was open to self-registration. (1)
I did not try it, if you know it does not work please tell me or adjust this paragraph. (3)