My personal technical and community goals for this year : - give more visibility of what's going on. ANd for me it is just about to let you know what do each others (and specifically the devs) on the ml or on the media I am. This isn't marketing. I just want do do it because I also miss that these days and I'm partially responsible.
- having couchdb full OTP: my rcouch branch should land later today or tomorrow, i have been sidetracked by a thing yesterday. - having a real couchapp engine around. But something new. that should use the full power of OTP and can be embedded easily: message passing, node distributions, websockets, ... - improve the view protocol to make it more efficient. And if possible fully embedded in couchdb with only some line of C if really needed. Some code experimentations last week gave me the convinction we could use v8 without having to embed a bloated nodejs. Also we can propose an alternative and innovate rather than embrace the world and do like others. I also think we should distinct views from the couchapp engine by itself. They require distinct features. Hopefully I will be able to push some code at the end of the month. - improve the HTTP layer which goes imo by revisiting our internal API to only use HTTP as a transport. Today we are mixing some core db code in the HTTP api - revisit auth handling. remove all users references in the core and only handle auth at upper level (ie remove ddoc load, embedded authz, security doc...) but propose some callbacks or events to allows transport on top to manage authentication. Ie only having authz done at HTTP level for the HTTP api. I've started to experiment that here: https://github.com/benoitc/libcouch - improve the replicator code: handle partial replications, speed (maybe use websockets) and improve a lot the way you can track a replication task activity. - improve the user & dev documentation. and collect all the experiments around to give a full panorama of the couchdb usage. I have other things in view, but these above are enough for me. For the rest , the more we will make couchdb interresting for the users at a technical level but also as a concept, the more we will gain traction. But it doesn't go necessarily by doing like others (ex take nodejs because most are using it, if we do that should be for real technical reason) or having more "marketing". The best evangelism is when you don't have to do it. And we didn't have to do it until we pushed new features and interesting concepts in Apache CouchDB. We should however improve the user experiment and that could be done by addressing each concerns: users of couchdb "just as a db" and couchapp users at a technical level but also documentation. Just some quick notes about these 2 concerns: - couchapp. there is a trend among some users to say that couchapps are useless or not enough by themselves and then either remove them or use them just as a way to replicate your app and handle most of the logic either on the browser or by using external code on top (proxy, ...) and behind (workers...) . Both are partials responses and mostly hack that doesn't really address the concern. And i'm quite annoyed to hear people talking about it like a thing written in stone that can't be changed. I think we can do better today on the couchapp side and use the power of replication, html5 to propose a new framework designed for the coming web (webrtc, websockets, ...) with new routing possibilities. All embedded. External scripts should be used when erlang isn't enough by itself or you need to use specific library for the work (like in machine learning or image processing). - db level: for those who are using couchdb "just" as a database. bigcouch, rcouch will give more feature on that part but there are a lot of improvements around that can be made. also really wish that the core of couchdb can be still used as a single db without cluster need. I don't want to use couchdb only for big dataset.s I also want it to use on my small device or my mobile. And sorry no I don't want to use pouchdb, touchdb for that. I want to use the same core code in most places. Voilà. Hopefully, I will be able to help on that topics, if not in apache couchdb at least in rcouch as new addons. And of course others are welcome to help! - benoît On Wed, Mar 6, 2013 at 7:14 PM, Noah Slater <[email protected]> wrote: > Hello community, > > I'd like to start a thread and collect a list of goals for 2013. > > We have a few exciting things in the pipeline. BigCouch is about to land. > Benoit's rcouch is also going to land. We're probably going to be moving to > V8. And if Jan has anything to do with it, we'll be getting a plugin system. > > These are roadmap items. (Which are very important to have!) But I am > thinking about other things which we might want to make a commitment to. > Things to do with the community, and marketing, and docs, etc. > > Some of the things I think we could aim for: > > * Increase month over month commits. Current activity is slowing down > month over month. Let's re-energize the project. How do we do this though? > I think by accepting more patches, closing more tickets, getting more > committers, and generating excitement. > > I actually think the rest of the goals I want to propose all feed into > that... > > * Get a JIRA triage team and Github/patch team up and running. Stay on top > of this stuff. Bring the JIRA queue down. Anyone want to put forward a > number or a metric we can actually work towards here? > > * Increase the size of the committership. Perhaps we could aim to double > it? I think we should go into mass recruitment mode. To the point even > where we might want to suggest handing out a commit bit to anyone who asks > for it. I'm talking about lowering the barrier to entry as much as is > possible. > > * Release monthly. Activity already around getting this process > bootstrapped. > > * Increase marketing activity. Social media, blogs, etc. What can we do > here? Weekly news is one great idea that's already been mentioned this > week. What other metrics can we use? > > Think of this like a set of personal development goals you might get at a > job, except we generate it for the community as a whole. And we can all > work towards them. > > Things which are * measurable* are ideal. It's hard to measure "excitement" > but it's easy to measure social media mentions, and blog subscribers, > releases, committers, patches, tickets, etc. > > We could break these down into quarters. If we manage to agree on some > metrics this month, we could set quarter by quarter goals for Q2, Q3, and > Q4. > > Thoughts? > > -- > NS
