19.1.4. Smaller tasks

Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills.

1. If you run FreeBSD-current and have a good Internet connection, there is a machine current.freebsd.org which builds a full release once a day - every now and again, try and install the latest release from it and report any failures in the process.
2. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself.
3. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions).
4. Help translate FreeBSD documentation into your native language (if not already available) - just send an email to FreeBSD documentation project mailing list <freebsd-doc@FreeBSD.ORG> asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this - in fact, the documentation most in need of translation is the installation instructions.
5. Read the freebsd-questions mailing list and the comp.unix.bsd.freebsd.misc newsgroupoccasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on.
6. If you know of any bugfixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder.
7. Move contributed software to src/contrib in the source tree.
8. Make sure code in src/contrib is up to date.
9. Look for year 2000 bugs (and fix any you find!)
10. Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings.
11. Fix warnings for ports which do deprecated things like using gets() or including malloc.h.
12. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version)
13. Suggest further tasks for this list!