Epiar has two classes of developers: contributors and developers. A contributor is somebody who sends us a patch, a fix, maybe even just a spelling correction. They typically, due to their lack of rigor, are not necessary in the workflow and operate by communicating with others, e.g. e-mailing one of us a patch.
A developer on the other hand is much like a contributor but their work is regular: perhaps they work on Epiar once a day or a few hours a week. Due to their higher involvement, they must know how things operate within the project, e.g. how the developers communicate with each other, how to stay current with the code, how to add code, how to track bugs, how to be assigned tasks, etc.
The following is a description of the Epiar development workflow, and contains all the important resources one needs to become a regular developer. If you're merely interested in sending a single patch, please use the Contact Form on the regular Epiar website, e.g. http://epiar.net/ and we'll take your patch under consideration (thanks for writing it!).
Step One: Say Hello
The most important thing you could possibly due to ensure you understand the development process and to learn more about Epiar is to meet another developer. All the regular developers talk on an e-mail list called epiar-devel, which can be subscribed to at http://epiar.net/mailman/listinfo/epiar-devel . Once you're on the list, say hello (literally, just say hello), and indicate what your experience is and what you'd like to work on. The most important thing to remember when communicating is to be polite: nobody is getting paid here, and everybody wants to have fun, so just be polite, and even if you have a difference, or even a near skirmish with another developer, remember: they are your friends, and they're to be treated with respect.
Check Out the Source Code
You're going to be reading and writing code (that's all programmers do really), so you'll need to check out a copy of the code. Epiar maintains it's master repository as a Subversion tree, but git access is also available. See http://epiar.net/subversion for more information on this. Read through the code and see what you think. Epiar development uses a hybrid git/Subversion model: the Subversion tree is the master repository, but very few people work directly with it: there is one git hub run by the developer knowknowledge, and pushing your changes into his git tree will eventually land those changes back in the Subversion tree, which is the tree used to build the releases.
See What the Problem Is
The easiest way to get into Epiar is to try and fix bugs! We use Trac (as you can see), so check out the "View Tickets" link at the top to see what bugs we currently have. Some bugs are assigned, some are not. You don't have to start your development by bug hunting, but it's one of the more enjoyable ways to just dive into a mostly unfamiliar codebase. After you get bored of squashing bugs (or if you're skipping that entirely), simply decide what whets your appetite and starting developing. It would be best to communicate with one of the established developers most closely related to your particular area of interest to ensure everything goes smoothly and submit patches to them.
And then become a Jedi Master
Once you've made significant contributors to the codebase, you understand the coding conventions and code quality requirements, and people like you (they probably will: reading this far is already a test of character), your git tree will likely become regularly merged back into knowknowledge's tree, who will merge it back regularly into the master Subversion repository and viola!: your code is in the next release (and in a lot of nightlies too!)
Important Things to Remember
If you commit anything to a tree that will make it to the upstream, or if you submit a patch, be sure to write a ChangeLog? entry. If you're accepting patches, make sure you write a ChangeLog? entry in the patcher's identity, e.g. "Chris submitted a patch to fix bug #34".
