[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, 9 Apr 2007 00:07:04 +0100 > What I would like to try and do is to produce a section on the lug > wiki about getting involved but I have (again) no idea what needs to > be put down. To that end (+ getting myself involved in them) do > people want to start submitting posts on how they started or on what > they would like to be there to support them etc.. (This is all from a perspective of working with compiled programs written in C/C++ and similar languages, working with an existing upstream team and leaving packaging for distributions to someone else. There are other ways of contributing but this is how I started. Some items are common to all development work.) 1. Scratch YOUR itch, not someone else's. The single most important thing is a *personal need* to change something about a particular package / application. Not a flight of fancy, something that gets under your skin, something that bugs you (that's why problems are called bugs after all) in an ongoing way. Something that is going to keep you focused on getting the issue fixed. Once you have that, then your choice of where to start is easy - get in contact with that project. File the bug report or add some information to an existing bug report. Get the source, look through it, see if you can fix the problem. Join the mailing list for the project and ask. Also look at the upstream bug system (bugzilla etc.) to see if the issue has been fixed but not yet released. I started with gnucash because it's such a hassle getting data from a Palm into gnucash invoices. http://code.neil.williamsleesmill.me.uk/palm.html It's not done yet but certain elements are now much easier than before. If you don't have a personal itch to scratch, the chances are that you will drift around not getting anything useful done. GnuCash is a v.large application - bear this in mind when you are choosing where to scratch your itch. Bigger is not necessarily better - big DOES mean added complexity and that is usually a BAD idea. Consider if there are smaller tools that can be persuaded to work together to replace or modify how the bigger application behaves. Remember: the UNIX way is a lot of small tools working together, not behemoths that scare away new developers and have a list of dependencies that gets into treble figures. Splitting a behemoth is MUCH MUCH harder than preventing a medium sized application becoming too large in the first place. Package size is no indicator of upstream activity or of the amount of support you may expect from upstream. Personality conflicts are COMMON - don't be surprised when they happen, you are likely to fall out with someone on a large team. Be tactful (you're the newbie again), be polite and above all, apologise fully and openly when you mess up. Don't rush in to fix your error unless you know EXACTLY what went wrong and why - do NOT compound your original mistake with even worse junk. If it doesn't work out with one particular team, find another way to scratch your itch. This is free software, if one method doesn't work there is always another way to do it. > Another idea that I had that I suggested at what i think was the last > meet was that; we as a lug could 'adopt' a project (I suggested > ppracer) and then assist and guide people into getting onto the FOSS > ladder That isn't particularly successful usually - we are all volunteers and nothing will get done unless each volunteer is personally motivated to put in the time. It has to be a personal itch - at least at the start. The start is when you spend the most time reading, thinking, throwing things around in frustration and generally spending time *not* changing anything. Only a deep seated personal bugbear will usually be enough to keep you coming back until the £"$^" issue is solved. 2. BUY at least a couple of general books The DCGLUG library is good for seeing which books to use but generally you are going to need particular books time and time again for months at a time so it makes sense to actually put some money into your development and buy the books. Buy the best reference text you can find for the language(s) that you need to use. 3. Get the DOCUMENTATION and READ IT Install EVERY -doc package of each dependency of the application you want to fix and install something like dwww or some other simple HTTP search and index help browser to help you navigate them all. 4. LEARN the BUILD Learn the build system - nothing will annoy the existing developers more than your proposed fix breaking the entire build. For C/C++ programs, this usually means automake, autoconf and autoheader. Learn what configure.in|.ac actually needs to do, learn what the Makefile does and how to control it using Makefile.am and automake. 5. Don't be scared off by large or complex codebases. Yes, libraries are difficult beasts and there is always more to learn when starting with a library than with any other project with the exception of the kernel or device drivers. Nobody would advise that you start with those but you can start with a library IF you are prepared to put in the time learning the autotools above AND libtool. Remember, for any compiled program you are going to have to deal with someone else's libraries (via their documentation and API) so you have to learn something about pkg-config and the autotools to understand how your code is actually run. Learn the codebase by triaging existing bugs. 6. Learn the development tools. Read about CVS, SVN. Try out various IDE suites (integrated development environments) like KDevelop, Anjuta, Eclipse but don't dismiss the simple options of KEdit|Gedit|Vim|Emacs. 7. TIME and patience. As above, the MAJORITY of your time in the start-up phase of development is you, alone, at your desk simply READING. Reading policy documents, API documentation, manpages, reference books, application documentation, ... Remember this when you start writing code. You benefited from this documentation so make sure those who will join after you get the same or better quality documentation of the changes that you make. Who cares if it takes a YEAR or more for you to get from thinking about helping to sending in your first patch? You will NOT be welcome if your first patch is trash, so get it right first. "Release early, release often" is a good thing overall but it does NOT mean "release early, release rubbish". 8. Keep to what you CAN do, not what you HOPE to be able to do. If you aren't getting the hang of a particular language, tool or project, ask for help and if it still doesn't gel, MOVE ON! Find something else, find a different package that uses different tools or languages and see if you can use that instead. Do not get into the trap of thinking that you ought to be able to solve a particular issue or worse, remove a particular tool from the package - you'll risk becoming a troll. Life's too short - find something else. Same applies if it is a person with whom you cannot seem to just "get along". You're the new face, it's your problem - let the miserable sod go his own way and get on with having fun somewhere else, with someone else. Don't hold grudges, don't deliberately trample on egos for the sake of it, don't be a PITA basically. This is meant to be fun. It's a hard lesson to learn sometimes (it took me too long to learn) but it is important that you retain perspective. Don't let this take over your life, don't let conflicts drag you down - get out, find something else. 9. Don't expect that what you need to do has to involve a new project. Don't reinvent wheels - do your research and spend time interrogating Google again and again and again and again for all possible ways of solving your problem to find people who have tried it before. Reports of previous failures are VERY important to how you fix the current problem - so WRITE about what breaks as well as what works. Write it in a blog or to a mailing list or in README files in the public CVS, anywhere where Google can find it. Don't hide your email address when you sound off about things breaking - someone may find your post and have a fix that you didn't consider. 10. DOCUMENTATION. Write it. Yes - write it. You, not someone else. YOU. Now. Yes, NOW! You wrote the code - YOU document it and at the time that you write the code too. At least get the comments started so that someone with different skills can improve the grammar or syntax. If you don't write what you know, no-one else is going to be able to make it into half-decent documentation. Bad documentation can always be improved but if a package is simply *not* documented at all, it is almost impossible for someone else to work out how to document it later. I'm not talking about writing a complete reference book, just liberal HELPFUL comments throughout the code. Add text to README and TODO files, make detailed entries into ChangeLog and cvs or svn commit messages. Remember, comments and documentation do NOT slow down the program and it compresses really easily so downloading well documented code is not a problem. A lack of comments and documentation WILL cripple any project eventually. Code should be brief, comments should be verbose, all documentation should be uploaded to public servers for Google to find. If the code is complicated, aim for 25% code and 75% documentation/comments. Use automated documentation generators (doxygen, scrollkeeper) and remember what it was like to have to read other people's documentation when you were starting out and make yours better than what you had to read. Obfuscation can be a fun pastime but it does not make for a happy development team. 11. Although this is all about compiled applications, don't omit the other areas where help is appreciated: Documentation, translations, website development, bug triage, answering questions on mailing lists (to free up time for other developers to get on with writing code) etc. Feel free to edit this post for the Wiki. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp7t9VMDvzpV.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html