Hi Tim, I am not a developer and I don't think I will be too soon as my free time doesn't allow me that. But I've been helping the users to get their products based on CouchDB done and I noticed 4 types of problems a new developer can attempt to solve: 1. installation problems on different platforms; 2. compatibility problems with different external software; 3. undesired (but understandable) differences in functionality (e.g., push vs. pull replications); 4. new cool staff. If you have time, you may want to start with point 1 and, in time, to reach point 4. In time you reach point 4, the confidence is built up and no need to ask yourself if you are good or not for this project because you are already involved in it.
Now, my thoughts about the problems you raised. "serious business" Once one thinks that way, then it's clear he/she needs this task just for adding it at CV. If you do it because you really would like to help, I am sure you will get help with your ideas if you don't manage by yourself. Does everything works in Linux? I recall the time when wireless drivers under Linux were really bad. Implement your ideas at the best of your knowledge and if they work for you, there are many chances to work for everybody (after all, Erlang is supposed to work in the same way on whatever platform). "Erlang, wtf" One way to learn it is reading and trying to understand the code. One step further is to add your own modules. This requires only time and willingness. Not to mention that there are parts in this project which have nothing to do with Erlang. "I still don't understand rereduce" Good point. There may be many points you have no idea how they work or what they actually implement. But nobody asks you to develop CouchDB from scratch. Just focus on what you know at the beginning and leave what you don't know for later. "Where are the easy bugs?" [solved] Really? The easy bugs which are solved are those reported here. Just look at the users list and see how many easy bugs are reported there almost every day and they are not reported in the dev list. That's because they are easy bugs which can suffer a workaround rather than the intervention from the devs (e.g., tests compatibility in different browsers or incompatible tests in the configure script which, in the end, attracted the devs attention, but there are still problems there). You can start by fixing those bugs. "wow, big code base" I think there are few devs here who can claim they know the full code and I haven't seen any message here saying "RTFM" for those who don't know everything. As far as I noticed here, there is a tendency of collecting the knowledge and not to show off with what one knows. Why should it be different for the newcomers? If you have time to study all the code, then it would be great. Nevertheless, in my 2 cents opinion, it's useless to understand the full code from the beginning because you are not going to work on optimization of the code at that point, correct? "Apache project?" Well, it's not like you sign a contract with ASF. I am helping in maintaining the documentation on wiki when it's needed, but I have no idea how it is to work for ASF. It's nothing else but a contribution to a freeware community-based project. Create your own git repository, report your modules and if they proved to be useful, your modules will be added into the CouchDB repository (that I noticed while following this list, but I might be wrong). In time you will be given the committer rights. This is general for all the community-based projects and, therefore, it has nothing to do with ASF at this stage. It may be, like in most of such projects, that from time to time ASF will reward your efforts, but, mainly, people here are doing it without that thought (I think). As I said, even if I wanted to become a dev, I am not able to take that step because I have no time. But if I started, I would follow what I wrote here. I hope these thoughts will help removing the "(perceived) barriers to entry". CGS On Wed, Apr 11, 2012 at 2:46 AM, Tim McNamara <paperl...@timmcnamara.co.nz>wrote: > After chatting with Noah S on Twitter, I offered to jot up some > thoughts on things that my reduce or eliminate perceived barriers to > entry to work on CouchDB. > > Here are a few things that I've been able to think of. In the course > of researching this mail though, I've actually answered many of my own > questions. > > "serious business" > A database seems like the kind of project that only extremely talented > people would touch. People depend on the code working. Getting started > would require quite a bit of confidence. Am I good enough? > > > "Erlang, wtf" > This is a barrier that I've been facing for a while. I'm actually in > the process of learning Erlang, trying to expand my horizons from > Python. Still, a new language makes it harder to have the required > confidence. > > > "I still don't understand rereduce" > I'm personally not 100% clear on how queries work. This is even after > using the db for a while. I don't want to look like a stupid idiot in > front of great developers. Therefore, there's a high risk of offering > suggestions and getting told to "RTFM" > > > "Where are the easy bugs?" > [solved] > > > "wow, big code base" > Is there any documentation on how to project is laid out? Stepping > into a new project is always a little daunting. > > > "Apache project?" > As someone outside of the ASF, I don't really know what contributing > on an Apache project means. >
