couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [DISCUSS] Goals for 2013
Date Fri, 08 Mar 2013 08:17:39 GMT
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 <nslater@apache.org> 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

Mime
View raw message