On Wed, Feb 11, 2009 at 12:27 AM, David Van Couvering <da...@vancouvering.com> wrote: > Hello. I've been following CouchDB from the sidelines for a while but > haven't been able to put much time into it. > > Recently, however, Sun laid me off, and I thought this would be a good > opportunity to get a little more engaged. > > No better way, IMHO, than to help out with the project. FYI, I'm already a > committer to Apache Derby, although I haven't been active there in the past > few years. > > I was looking at your road map and it looked like you want to get a lot of > documentation written. I was thinking that would be a great way for me to > start learning CouchDB. Is there a specific document that you would like to > me to try my hand at? Also, what are your processes, technologies and > standards around documentation? > > I can also start poking around at your bug list and perhaps offer some > patches to get my feet wet. Is there anything in particular that you would > like someone to focus on? I don't have an Erlang background, although I'm > interested in learning. My background is server-side Java and databases, > for the most part. > > I look forward to hearing from you. Meanwhile I'll try to get a build going > and see how that goes. > > All the best, > > David > > -- > David W. Van Couvering > http://davidvancouvering.blogspot.com >
David, It's awesome to hear your interest especially given your recent situation. Re: Documentation As far as I'm aware the only guidelines in terms of documentation are to put things on the wiki. I would say that if a specific section of CouchDB interests you, start learning the code base from that aspect and add good wiki information on it. I know that I, for one, am not the most vigilant in keeping things in sync. Another aspect to documentation would also be documenting the Erlang documentation best practices. It doesnt sound as sexy, but getting a good set of rules for native Erlang documentation would be a Good Thing ™. There have been attempts at getting autogenerated docs. Having a good distillation of rules as well as a working build integration with the website would be an awesome advancement. Re: Patches The two biggest suggestions I have would be to start reading code via the *_httpd_*.erl sources. In terms of behavior, these have the most documentation as well as being a very logical root point to start tracing code paths. If you have something that tickles your fancy, its fun to follow an HTTP request all the way to disk. I took a shining to view generation and ended up reading through the btree code. There's lots of the seductive, "No fucking way it can be this easy" type of code that makes the internals fun to read through. My other suggestion is fairly closely related. Start walking through the list of bugs that are blocking for 0.9 and see what you're comfortable dealing with. I'd definitely suggest adding comments to bugs or popping on IRC if you find something approachable. JIRA is a PITA when it comes to assigning things, so I spend a good chunk of my time trying to remember if someone on the ML or IRC claimed progress or on going work. For reference, Jan has an awesome page setup that will get you the list of blocking issues for 0.9 at [1]. Hopefully he'll keep it updated beyond the 0.9 release. [1] http://jan.prima.de/fuckjira.html HTH and welcome to the community, Paul Davis
