couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Helping out
Date Wed, 11 Feb 2009 06:58:56 GMT
On Wed, Feb 11, 2009 at 12:27 AM, David Van Couvering
<david@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 &trade;. 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

Mime
View raw message