Difference between revisions of "Contributing to GnuCash"
(→Code: Rewrite version control paragraph) |
m (moved Development to Contributing to GnuCash: Contributions listed extend well beyond program development) |
(No difference)
| |
Revision as of 16:50, 22 November 2013
The GnuCash Project is a volunteer-driven organization and depends on volunteers, such as you, to survive and grow. This page explains the ways to contribute to the project.
Many ideas here are taken from this slashdot comment.
Contents
Testing
Programmers can be fine testers, but non-programmers seem to be able to break programs in new and mysterious ways. The trick here is to learn how to give the best information to the programmers about how to reproduce bugs. A programmer will usually only be able to fix a bug they can see; if you can't make the programmer see your bug, it won't get fixed! If you find a real reproducible bug, check with Bugzilla to make sure the developers know about it. Programmers should feel free to add plenty of unit tests (see Testing) as well.
Feedback
Providing feedback on what features are used, and what aren't is important to developers who may spend a lot of time on a feature they think is important instead of a feature that actually is important. From another comment: What this thing needs is some normal human beings using it and saying "you know what, it's NOT acceptable that window A obscures window B and freezes while window B is waiting for input from me." It needs, I am sorry to say, Quicken or MS Money users, who say "It was really easy to do X, Y, and Z, but here, I can't even figure out if it's possible,"
Possible ways of feedback are explained in this section and following of the FAQ.
WishList
Similarly, it is important to keep track of wishlists — both those of the official developers, and of users. Since this is a wiki, a user named Andy Glew has taken the liberty of creating such a WishList.
Documentation
Writing documents on how to do things, see e. g. Concept Guide, (or why to do things, accounting is a black art to many). Help people out using the program. The article said that the programmers are spending a lot of their time answering questions instead of actually getting on and doing the job. Even simple things like "Tips and tricks" are a good start. If users can help other users, then the current programmers can spend more of their time getting new developers up to speed.
Wiki
Write answers to FAQ's. Wiki'ing is very addictive and fun. And while you're at it, everyone learns! As you probably have noticed, you are looking at such a wiki right now. Simply click on the "Edit". If you are a Firefox user, you may like to try the Wikipedia editing extensions to make the job easier.
Localisation
If your natural language is different from english, you can contribute by translating
- parts of this wiki
- the website
- the program
- its official documentation "Help" and "Tutorial and concepts guide"
See Translation for details.
- Add or improve Account Templates for your region.
- Add or improve Tax Reports for your region, which might be nontrivial. But adding a wiki page with [links to] tax forms or the description of the online interface of your tax authority could be a first step as programmers are seldom Certified Public Accountants, too.
- You could also support the Mailing Lists team of your language.
See also #Tools.
Advocacy
You usually get developers because they use software and have an itch to scratch. I'd guess that GnuCash's biggest problem is that programmers don't use the software. Running tutorials, presentations at local LUGs can be invaluable for getting a larger userbase (and therefore hopefully a larger developer base).
Code
If you're a programmer, obviously a good way to help is to start writing useful code :).
- See Building for more details on how to build the program from source code.
- See Development_Process for
- We are in the last stage of converting source code version control from Subversion to Git, which we intend to complete shortly after releasing GnuCash version 2.6 at the end of 2013. New contributors should follow the git Git instructions for cloning the repository and preparing patches. Any current developers still using subversion should switch to git for most of their work as soon as possible in order to be ready for the final conversion.
- Please subscribe to the Mailing Lists and introduce yourself to the development team. You can also hang out on IRC, but that isn't required.
- Read the two files HACKING and README.svn.
- Now try your hand at one of the outstanding bugs in Bugzilla, something from the WishList or your own pet peeve. Please consider adding unit tests (see Testing) for features where applicable.
- The coding style was last discussed on the gnucash-devel ML.
- If your code will contain textual output for the user, have a look at Translation: Tips for Developers.
- If your code adds or changes some functionality, do not forget the documentation:
- Once you have your changes written and well tested - make check will run a bunch of tests -, you'll want to submit it so that someone with commit privilege can add it to the official sources. First, make a patch:
- Git is best. See the patch instructions.
- If you're using Subversion, you can create a patch with
svn diff
- If there's already a bug about it in Bugzilla, just attach the patch to the bug. Be sure to check the "patch" checkbox on the attachment form.
- If there isn't a bug already (be sure to search!), it really works best if you create a new one to attach your patch to.
- Describe the problem or improvement that your patch addresses in the initial comment.
- If you use Git, open the bug before you make your patch so that you can include the bug number in the commit message.
- If there isn't a bug already and the patch is trivial, you can send it to the gnucash-devel mailing list (though we really do prefer patches to go to Bugzilla).
- Please attach the patch to the email, don't inline it in the message, even if you used git format-patch and it made a pretty email for you.
Tools
Text editors / IDE:
- Most developers seem to have used Emacs as IDE.
- Additionally there are some experiences with Eclipse.
- Some are using qtcreator.
Build system:
- Gnucash uses the Autotools as build system
- Additionally there are some experiments with CMake, see Cutecash
Money
The GnuCash Project encourages financial contributions in three ways:
- Small donations can go to the GnuCash tip jar to pay for unavoidable expenses of the project, and for projects agreed upon by consensus.
- Sizable donations go to specific developers to help fulfill feature requests.
- Thanking developers for past work can be done individually, but will not be done through the project.
See also
See WishList for more ideas for small projects of value, ideal for limited contributors.
An informative mail from the archives.
