* Contributing to the Mono project Mono has not been completed yet. It is a project under active development and with a vibrant community. If you are looking at ways of helping the project, you have come to the right web page. There are three different philosophical approaches to helping the Mono project, the selfish way, the altruistic or the educational way. The selfish way is packed with adventure. You start by building your own software, and start using the compiler and tools that come with Mono. Eventually you will run into missing features, or a bug in the software. Since we ship all the source code for Mono, you can start tracking down the problem. Depending on how much time you have to devote to the problem you could: File a bug report (read this); track down the problem and provide a better bug report; fix the bug and provide a patch (you can post it to the mono mailing list; or discuss the solution on the mailing list. Ideally you will also write a regression test so the bug does not get re-introduced in the future. The altruistic is probably the easiest because you get to pick a piece of Mono that you might want to work on. You can pick an unfinished class (from our class status page); help with the documentation effort (mailing list for the documentation effort); fix existing runtime bugs; compiler bugs; help with the tools or writing tests that help make Mono more robust or help with the Winforms effort. The educational way is an interesting one, because you pick a technology you are interested in, and work on that technology to learn the technology. Those are just broad things that need to be worked on, but something that would help tremendously would be to help with small duties in the project that need to be addressed. You can see what needs to be done in the class libraries here * IRC Channel Many developers get together on the #mono irc channel on the irc.gnome.org server. ** To start contributing As a programmer, you can contribute in three different scenarios to Mono:
In addition to bugzilla, posting to the list is fine if the bug merits larger exposure or design discussions to solve; posting to the list twice or more is just a way to annoy people and make them waste time, specially when you start a new thread about it. * If the test involves libraries or assemblies that are not part of mono, add info about where to download all the dependencies, and how to compile/install them. * If compiling the test case requires more than:
mcs test.csprovide the full command line you used to compile the test. * If running the test requires more than:
mono test.exeprovide the full command line needed to replicate the bug. * Provide info about the version of the software you're using (both mono and the operating system or relevant libraries). * Provide the output you expect the test case to produce. * Provide the actual output you get from the test case.
mount -t smbfs -o uid=miguel,username="Miguel de Icaza" "//quack/c$" /mntIn the above example, my Linux user name is `miguel', and this will allow this user to have read/write access to the share. The host name is `quack', and the name of the share is `c$' (that is the C: partition). The file system is accessible on /mnt. You can perform your cvs update and cvs commits from the /mnt directory, and run Emacs or your favorite Linux text editor on the Unix side in this way. Then from another terminal, you can ssh into your Windows box using ssh, like this: ssh "Miguel de Icaza@quack"