Part1: What's up dev? About energy.

[Benoit Chesneau <bc...@gmail.com>]

What's up devs?

Following our last discussion with @nslater on twitter, I wanted to say
a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
time really. These days I miss what make me enjoy CouchDB at the
beginning. The energy you could feel on the chan and sometimes IRL. The
time when anyone was aware of who was working on a feature. Which
feature was in progress. Today IRC is more like a support channel where
sometimes ideas emerge but you don't feel they are very supported. There
are private discussion somewhere.  But well they are... private. Same
for tickets. We see tickets but more often no real incentive from each
others (and I am to blame too) to fix them.

Today to be honnest, this lack of energy annoys me a lot. This is quite
more important than the rest. At least for me. I don't have 4 devs on
the projects working with me in my office where I can speak with each
other about possible fixes and such .. Communication inside the project
is  really important. Apache CouchDB is an opensource project
distributed around the world (at least 2 continents).

Anyway I still keep my confidence in the project. I know there have been
lot of codes developped around. Today if we don't count the couchbase
fork (wich is still named couchdb and all...) there are 2 friendly forks I'm
aware of couchdb: bigcouch, refuge.

Bigcouch was announced to be merged in. But since then we don't know as
couchdb devs how it will be. How can we keep couchdb working standalone
and on a cluster. It blocks everything else today for me since I don't
know if I will work on a cluster or still can continue to think I can
use couchdb standalone on one node (and possiblit migrate to the
cluster thing easily). I didn't see anything about in
bigcouch recently as well. . As a CouchDB developper I would like to see
a branch in couchdb so we can hack on all together or just review or
document.

Rcouch my own fork which has the following features:

- OTP compliant (build an erlang release, support hot upgrades), bigcouch
is as well. Today couchdb isn't really erlangish and is based on
autotools
- static build support. Packages for deb, rpm, macosx, arm platforms
- View changes: get changes in an ndex in real time
- Replication using view changes
- couch_randomdoc : pick a random document inside a db or a view
- dnssd : discover couchdb over bonjour in your lan
- upnp : make couchdb easily accessible on the net
- refuge_spatial: fork of geocouch adapted to use latest couch_index.
  (note that a version also exists for bigcouch)
- HTTP api based on ranch and cowboy (using mochicow for the
  transition). more stable and efficient HTTP handlers
- doc read validation (like update validation)
- dropbox features (anyone can upload only readers or admins can read
  doc uploaded)
- some replication fixes.
- no refcount db , using a patch from @davisp similar to the one in
  bigcouch
- ..

And coming this week: view merge & cors.

I would like to merge it in couchdb as well. But I don't know how. And
each time I asked for having a discussion on it it fails because some
were busy or anything (but never came back). Can we put a roadmap for
that and start to put the code online?


Second part about couchapps in next mail.

- benoît

Re: Part1: What's up dev? About energy.

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Sep 27, 2012 at 5:33 PM, Bob Dionne
<di...@dionne-associates.com> wrote:
> Hi Benoit,
>
> I can understand your view and to some extent share your concerns.
>
> I took a look at the refuge project and things like couch_core are interesting. I'm impressed how prolific you are.

thanks :)

>
> I'd definitely love to see simpler internals and a better separation of concerns, especially with respect to couchapps. I've always been enamored of the idea and wonder why the implementation seems to get so mired in the mud, but I'm not a web programmer, I'm sure there's issues I'm missing.

Not sure as well. Actually a more efficient js evaluation would solve
most of the problem we have and open new possibilities...

>
> My hobby interest in couchdb is primarily as a document store. I'd still like to see a native full text indexer and I'm also interested in a simple triple store whose tuples are doc ids, mainly to enable algorithms over graphs. Not large social graphs such as "who likes who", but rather graphs that are used in description logics and proof theory, of order a million nodes with high connectivity. I toyed with pulling out the essentials into a couch_store (not to be confused with the one from Couchbase) that would give me something like a bitcask API, if that makes sense. For me something like that with the ability to load other gen_servers as needed would be really useful. CouchDB is kind of there now in that regard, but the internals still need a lot of work. Anyway I recognize this is a niche use case, though a native FTI might be of general interest.

That would be awesome indeed. It doesn't need to solve all the
problems imo. I also have a look on bindings like the xapian one:

https://github.com/arcusfelis/xapian-erlang-bindings

unfortunately xapian is under GPL...

>
> Anyway, sorry to be so vague. I'm definitely +1 on better OTP/rebar use and so forth and happy to help as I can on the internals.

cool :)
>
> With respect to BigCouch, do you think Fabric is the best way to provide a unified API for both the single instance and clustered cases?

Can be yes :) I think we may need a way to merge couchbeam/fabric so
it can be used for the replication and other remote needs as well. I
am working on such thing. I am trying to understand these days how
rexi usage could also be done on top of http/

> It seems to me a single instance is just the special case of R=W=Q=N=1. I know PaulD, BobN, and others have lots of good ideas here and I think we'll all soon be in the middle of it.

Can be yes. Not sure how it would be optimized or to rebalance to a
new node after . But indeed ....

>
> Regards,
>
> Bob
>
> On Sep 24, 2012, at 5:20 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> What's up devs?
>>
>> Following our last discussion with @nslater on twitter, I wanted to say
>> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
>> time really. These days I miss what make me enjoy CouchDB at the
>> beginning. The energy you could feel on the chan and sometimes IRL. The
>> time when anyone was aware of who was working on a feature. Which
>> feature was in progress. Today IRC is more like a support channel where
>> sometimes ideas emerge but you don't feel they are very supported. There
>> are private discussion somewhere.  But well they are... private. Same
>> for tickets. We see tickets but more often no real incentive from each
>> others (and I am to blame too) to fix them.
>>
>> Today to be honnest, this lack of energy annoys me a lot. This is quite
>> more important than the rest. At least for me. I don't have 4 devs on
>> the projects working with me in my office where I can speak with each
>> other about possible fixes and such .. Communication inside the project
>> is  really important. Apache CouchDB is an opensource project
>> distributed around the world (at least 2 continents).
>>
>> Anyway I still keep my confidence in the project. I know there have been
>> lot of codes developped around. Today if we don't count the couchbase
>> fork (wich is still named couchdb and all...) there are 2 friendly forks I'm
>> aware of couchdb: bigcouch, refuge.
>>
>> Bigcouch was announced to be merged in. But since then we don't know as
>> couchdb devs how it will be. How can we keep couchdb working standalone
>> and on a cluster. It blocks everything else today for me since I don't
>> know if I will work on a cluster or still can continue to think I can
>> use couchdb standalone on one node (and possiblit migrate to the
>> cluster thing easily). I didn't see anything about in
>> bigcouch recently as well. . As a CouchDB developper I would like to see
>> a branch in couchdb so we can hack on all together or just review or
>> document.
>>
>> Rcouch my own fork which has the following features:
>>
>> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
>> is as well. Today couchdb isn't really erlangish and is based on
>> autotools
>> - static build support. Packages for deb, rpm, macosx, arm platforms
>> - View changes: get changes in an ndex in real time
>> - Replication using view changes
>> - couch_randomdoc : pick a random document inside a db or a view
>> - dnssd : discover couchdb over bonjour in your lan
>> - upnp : make couchdb easily accessible on the net
>> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>>  (note that a version also exists for bigcouch)
>> - HTTP api based on ranch and cowboy (using mochicow for the
>>  transition). more stable and efficient HTTP handlers
>> - doc read validation (like update validation)
>> - dropbox features (anyone can upload only readers or admins can read
>>  doc uploaded)
>> - some replication fixes.
>> - no refcount db , using a patch from @davisp similar to the one in
>>  bigcouch
>> - ..
>>
>> And coming this week: view merge & cors.
>>
>> I would like to merge it in couchdb as well. But I don't know how. And
>> each time I asked for having a discussion on it it fails because some
>> were busy or anything (but never came back). Can we put a roadmap for
>> that and start to put the code online?
>>
>>
>> Second part about couchapps in next mail.
>>
>> - benoît
>

Re: Part1: What's up dev? About energy.

[Bob Dionne <di...@dionne-associates.com>]

Hi Benoit,

I can understand your view and to some extent share your concerns. 

I took a look at the refuge project and things like couch_core are interesting. I'm impressed how prolific you are. 

I'd definitely love to see simpler internals and a better separation of concerns, especially with respect to couchapps. I've always been enamored of the idea and wonder why the implementation seems to get so mired in the mud, but I'm not a web programmer, I'm sure there's issues I'm missing.

My hobby interest in couchdb is primarily as a document store. I'd still like to see a native full text indexer and I'm also interested in a simple triple store whose tuples are doc ids, mainly to enable algorithms over graphs. Not large social graphs such as "who likes who", but rather graphs that are used in description logics and proof theory, of order a million nodes with high connectivity. I toyed with pulling out the essentials into a couch_store (not to be confused with the one from Couchbase) that would give me something like a bitcask API, if that makes sense. For me something like that with the ability to load other gen_servers as needed would be really useful. CouchDB is kind of there now in that regard, but the internals still need a lot of work. Anyway I recognize this is a niche use case, though a native FTI might be of general interest.

Anyway, sorry to be so vague. I'm definitely +1 on better OTP/rebar use and so forth and happy to help as I can on the internals.

With respect to BigCouch, do you think Fabric is the best way to provide a unified API for both the single instance and clustered cases? It seems to me a single instance is just the special case of R=W=Q=N=1. I know PaulD, BobN, and others have lots of good ideas here and I think we'll all soon be in the middle of it.

Regards,

Bob

On Sep 24, 2012, at 5:20 AM, Benoit Chesneau <bc...@gmail.com> wrote:

> What's up devs?
> 
> Following our last discussion with @nslater on twitter, I wanted to say
> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
> time really. These days I miss what make me enjoy CouchDB at the
> beginning. The energy you could feel on the chan and sometimes IRL. The
> time when anyone was aware of who was working on a feature. Which
> feature was in progress. Today IRC is more like a support channel where
> sometimes ideas emerge but you don't feel they are very supported. There
> are private discussion somewhere.  But well they are... private. Same
> for tickets. We see tickets but more often no real incentive from each
> others (and I am to blame too) to fix them.
> 
> Today to be honnest, this lack of energy annoys me a lot. This is quite
> more important than the rest. At least for me. I don't have 4 devs on
> the projects working with me in my office where I can speak with each
> other about possible fixes and such .. Communication inside the project
> is  really important. Apache CouchDB is an opensource project
> distributed around the world (at least 2 continents).
> 
> Anyway I still keep my confidence in the project. I know there have been
> lot of codes developped around. Today if we don't count the couchbase
> fork (wich is still named couchdb and all...) there are 2 friendly forks I'm
> aware of couchdb: bigcouch, refuge.
> 
> Bigcouch was announced to be merged in. But since then we don't know as
> couchdb devs how it will be. How can we keep couchdb working standalone
> and on a cluster. It blocks everything else today for me since I don't
> know if I will work on a cluster or still can continue to think I can
> use couchdb standalone on one node (and possiblit migrate to the
> cluster thing easily). I didn't see anything about in
> bigcouch recently as well. . As a CouchDB developper I would like to see
> a branch in couchdb so we can hack on all together or just review or
> document.
> 
> Rcouch my own fork which has the following features:
> 
> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
> is as well. Today couchdb isn't really erlangish and is based on
> autotools
> - static build support. Packages for deb, rpm, macosx, arm platforms
> - View changes: get changes in an ndex in real time
> - Replication using view changes
> - couch_randomdoc : pick a random document inside a db or a view
> - dnssd : discover couchdb over bonjour in your lan
> - upnp : make couchdb easily accessible on the net
> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>  (note that a version also exists for bigcouch)
> - HTTP api based on ranch and cowboy (using mochicow for the
>  transition). more stable and efficient HTTP handlers
> - doc read validation (like update validation)
> - dropbox features (anyone can upload only readers or admins can read
>  doc uploaded)
> - some replication fixes.
> - no refcount db , using a patch from @davisp similar to the one in
>  bigcouch
> - ..
> 
> And coming this week: view merge & cors.
> 
> I would like to merge it in couchdb as well. But I don't know how. And
> each time I asked for having a discussion on it it fails because some
> were busy or anything (but never came back). Can we put a roadmap for
> that and start to put the code online?
> 
> 
> Second part about couchapps in next mail.
> 
> - benoît

Re: Part1: What's up dev? About energy.

[Benoit Chesneau <bc...@gmail.com>]

On Mon, Sep 24, 2012 at 12:41 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Some good stuff in this Benoit.
>
> I think we need to kick some life back into the team as well.
>
> Here are my ideas:
>
> * Set up a weekly team meeting on IRC. Attendance strictly non-compulsory.
> Minutes archived on wiki and sent to list afterwards. Get everyone to speak
> up and report on status, and any items for discussion. This mirrors a
> short-lived, but very useful, "CouchDB heartbeat" that me and Jan were
> doing in private during our darkest hour this year.
>
> * Set up informal teams, or work groups. No team leaders.
> No hierarchy or bureaucracy. Just promote the idea that people should get
> organised around specific areas. Each "team" get's a wiki space. People can
> elect to be in the team. Again, no team leaders. Just groups of people. For
> example, me, Paul, and Bob are the release team at the moment. This team
> has existed for years, but we've not documented it anywhere. Let's do that.
> And ask other people to do the same around areas they give a shit about.
>
> * Kick of product management and marketing activities. I'm talking feature
> lifecycle stuff. Collecting requests and use cases. Maintaining a roadmap.
> Maintaining docs. Setting up a release cadence. Working with PR, bloggers,
> etc, ever time we launch. Open up blog itself to the community. We need to
> blog about non-release stuff. Demonstrate that we're thought leaders.
>
> * Start to recognise 3rd party projects by either merging them in directly
> (BigCouch), creating ASF sub-projects, or learning from them, and blessing
> certain ideas. CouchApps is, apparently controversial. One option might be
> to re-implement CouchApps in core, taking lessons from 3rd party projects,
> but not merging any in directly. The goal being to say that CouchDB core is
> both a clustered database and an app platform. No need to depend on forks
> or external projects. This shit is important enough to the community that
> we're making that functionality core.
>
> Benoit, I know you're going to have some concerns about what exactly I mean
> by some of these points. I would like to say, for now, let's put the
> discussion on hold. And work through these one by one. Or at
> least, separately. I'm trying to devote more hours in the week to CouchDB.
> And I only have time to think about and work on one of these things at a
> time. I am sure other people feel the same. So, let's be aware that there
> are things to sort out here, and different perspectives to unite, and just
> put it on the back burner, and pick one of them for now.
>
> I think the first thing we need to look at is setting up a weekly IRC
> meeting. I will send out a separate email for that now.

@nslater thanks for the answer.

The irc meeting is a good idea imo let start with it. I will address
later the other topics. Would be good to have reactions from others
too :)

- benoît


>
> On Mon, Sep 24, 2012 at 10:20 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> What's up devs?
>>
>> Following our last discussion with @nslater on twitter, I wanted to say
>> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
>> time really. These days I miss what make me enjoy CouchDB at the
>> beginning. The energy you could feel on the chan and sometimes IRL. The
>> time when anyone was aware of who was working on a feature. Which
>> feature was in progress. Today IRC is more like a support channel where
>> sometimes ideas emerge but you don't feel they are very supported. There
>> are private discussion somewhere.  But well they are... private. Same
>> for tickets. We see tickets but more often no real incentive from each
>> others (and I am to blame too) to fix them.
>>
>> Today to be honnest, this lack of energy annoys me a lot. This is quite
>> more important than the rest. At least for me. I don't have 4 devs on
>> the projects working with me in my office where I can speak with each
>> other about possible fixes and such .. Communication inside the project
>> is  really important. Apache CouchDB is an opensource project
>> distributed around the world (at least 2 continents).
>>
>> Anyway I still keep my confidence in the project. I know there have been
>> lot of codes developped around. Today if we don't count the couchbase
>> fork (wich is still named couchdb and all...) there are 2 friendly forks
>> I'm
>> aware of couchdb: bigcouch, refuge.
>>
>> Bigcouch was announced to be merged in. But since then we don't know as
>> couchdb devs how it will be. How can we keep couchdb working standalone
>> and on a cluster. It blocks everything else today for me since I don't
>> know if I will work on a cluster or still can continue to think I can
>> use couchdb standalone on one node (and possiblit migrate to the
>> cluster thing easily). I didn't see anything about in
>> bigcouch recently as well. . As a CouchDB developper I would like to see
>> a branch in couchdb so we can hack on all together or just review or
>> document.
>>
>> Rcouch my own fork which has the following features:
>>
>> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
>> is as well. Today couchdb isn't really erlangish and is based on
>> autotools
>> - static build support. Packages for deb, rpm, macosx, arm platforms
>> - View changes: get changes in an ndex in real time
>> - Replication using view changes
>> - couch_randomdoc : pick a random document inside a db or a view
>> - dnssd : discover couchdb over bonjour in your lan
>> - upnp : make couchdb easily accessible on the net
>> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>>   (note that a version also exists for bigcouch)
>> - HTTP api based on ranch and cowboy (using mochicow for the
>>   transition). more stable and efficient HTTP handlers
>> - doc read validation (like update validation)
>> - dropbox features (anyone can upload only readers or admins can read
>>   doc uploaded)
>> - some replication fixes.
>> - no refcount db , using a patch from @davisp similar to the one in
>>   bigcouch
>> - ..
>>
>> And coming this week: view merge & cors.
>>
>> I would like to merge it in couchdb as well. But I don't know how. And
>> each time I asked for having a discussion on it it fails because some
>> were busy or anything (but never came back). Can we put a roadmap for
>> that and start to put the code online?
>>
>>
>> Second part about couchapps in next mail.
>>
>> - benoît
>>
>
>
>
> --
> NS

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

Everything involves copious amounts of beer, no?  I will put together a
more detailed post as to what I think we need to do.  The post should not
be construed as orders or anything of the such, just a starting point to
get conversation started.

-bryan

On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com> wrote:

> On 26 September 2012 13:03, Bryan Green <db...@gmail.com> wrote:
> > Hello everyone,
> >     I would be more than happy to help with the product management area.
> >  Just let me know who else is really interested in helping in that area
> and
> > we can start talking.  I have extensive experience in product
> management--
> > doing and mentoring.
> >
> > - bryan
>
> Given I have no experience in that I'll put my hand up. Here's a good
> place to start on that. With whatever product mgmt is. I assume it
> involves copious quantities of beer.
>
> A+
> Dave
>

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

Noah, shevek if it is not taken.

On Fri, Sep 28, 2012 at 2:10 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Bryan, I preferred your original framing! (i.e. I can help you, as you seem
> to know what you're doing! Not the other way around.) Like I said, I'm
> still learning this PM business. I have a bunch of thoughts about what we
> need to do, scattered about the place.
>
> A wiki page would be a good place to collect our ideas.
>
> Give me your wiki username and I will add you to the contributors group.
>
> On Fri, Sep 28, 2012 at 7:59 PM, Bryan Green <db...@gmail.com>
> wrote:
>
> > Noah,
> >    I would be more than happy to help you out in anyway I can.  I am new
> to
> > this project,
> > so just let me know how I can help you in your PM role.  I would love to
> > have access
> > to the wiki to start a page.
> >
> > - bryan
> >
> > On Fri, Sep 28, 2012 at 1:41 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> > > Brian, wow! It's great to see you so excited about this.
> > >
> > > For what it's worth, I had expected that I would be doing the PM
> stuff. I
> > > am a PM in my day job, though I am still learning. I think we should
> form
> > > an informal (heh!) PM team and take things from there. Perhaps a wiki
> > page
> > > would be a good start.
> > >
> > > Anyone else interested in joining this PM team? I'm looking at you, PMC
> > > members.
> > >
> > > Your action items sound great. I would just caution though that we
> have a
> > > lot of stuff to catch up on at the moment. And I think we should focus
> > our
> > > efforts on the big items in our pipeline before we start introducing PM
> > > activities. (I only have so many hours per week to devote to CouchDB,
> > and I
> > > need to make sure I'm spending them wisely.)
> > >
> > > Let's focus on getting the docs integrated, and then chasing up
> BigCouch.
> > > And then I think we should focus on the stuff you mention. Though, my
> > next
> > > biggest priority is actually implementing a release cadence.
> > >
> > > Also, I think we should be doing content marketing. Getting people to
> > > contribute to our blog. Establish ourselves as thought leaders in this
> > > space. J. Chris used to do a lot of this, but he doesn't blog about
> > CouchDB
> > > so much any more.
> > >
> > > And FWIW, we're not just a scratch our itch project. ;)
> > >
> > > On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com>
> > > wrote:
> > >
> > > > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dch@jsonified.com
> >
> > > > wrote:
> > > >
> > > > > On 26 September 2012 13:03, Bryan Green <db...@gmail.com>
> > > wrote:
> > > > > > Hello everyone,
> > > > > >     I would be more than happy to help with the product
> management
> > > > area.
> > > > > >  Just let me know who else is really interested in helping in
> that
> > > area
> > > > > and
> > > > > > we can start talking.  I have extensive experience in product
> > > > > management--
> > > > > > doing and mentoring.
> > > > > >
> > > > > > - bryan
> > > > >
> > > > > Given I have no experience in that I'll put my hand up. Here's a
> good
> > > > > place to start on that. With whatever product mgmt is. I assume it
> > > > > involves copious quantities of beer.
> > > > >
> > > > > A+
> > > > > Dave
> > > > >
> > > > *Product management is focused on finding, documenting, and
> > prioritizing
> > > > what users of the product need and/or want the product to accomplish
> > for
> > > > them.*
> > > >
> > > >
> > > > All of us have our own reasons to work on and use couchdb, and we
> > > probably
> > > > know what couchdb does, but what is our goal as a product team?  What
> > is
> > > > the mission of the Couchdb project?  Is it only a "scratch an itch"
> > > project
> > > > for the developers who donate their time to it, or is it a project
> > that,
> > > > also, actively listens to non-contributor users.  There is no right
> or
> > > > wrong answer in my opinion, but we do need to establish the
> > expectations
> > > of
> > > > the user before they download couchdb.  If we are mainly a "scratch
> an
> > > > itch" project it will make some of what follows in this e-mail moot.
> >  Our
> > > > marketing on the web-site needs to make it explicit that we are not
> > > overly
> > > > interested in supporting non-contributing users and their problems,
> if
> > > that
> > > > is our position.  This will save a bitter taste in the mouth of the
> > user
> > > > when they don't get the support they think they should.
> > > >
> > > >
> > > > It would also help if we could be more proactive in communicating the
> > > > status of known bugs, and their impact, in existing releases and
> > planned
> > > > new features.  We could accomplish this by sending an alert e-mail
> sent
> > > to
> > > > the users mailing list, or on a page of the web-site. I think once a
> > > month
> > > > would be acceptable.  The key would be that it would be a summary of
> > the
> > > > bug, or feature, and it's impact.
> > > >
> > > >
> > > > When it comes to identifying what we should be working on next, I
> think
> > > it
> > > > is great that we have really good minds within the project that are
> > > capable
> > > > of idea generation for the product, but we need to expand this out
> more
> > > to
> > > > the community.  We need to develop user personas, use cases, and what
> > the
> > > > "competition" is doing.
> > > >
> > > >
> > > > A starting point for all of this could be to catalog the branches of
> > > > couchdb and analyze why the branch was created and how successful it
> > has
> > > > been.  We need to get feedback from our users about what they are
> using
> > > > couchdb for, and what work-arounds they feel like they had to do to
> use
> > > > it-- especially work-arounds that they feel like should not have been
> > > > needed.
> > > >
> > > >
> > > > We should brainstorm what user classes/roles we have.  This can be
> done
> > > > through irc or e-mail.  Basically, you just free flow all the
> different
> > > > types of users that you can think of that use couchdb, or should be
> > using
> > > > it.  Then after we have that big list, we will collapse some down
> > (there
> > > > will be duplicates), and finally we will have a smaller list of user
> > > > classes.  We can build personas for each user class.  This eventually
> > > helps
> > > > you understand and identify with your user base.  It also helps
> develop
> > > use
> > > > cases.
> > > >
> > > >
> > > > We should keep up to date on the main NoSQL products out there and
> know
> > > how
> > > > we are different.  We should publicize this information on our
> > web-site.
> > >  I
> > > > think transparency is desirable in all relationships, but especially
> > > with a
> > > > user-base.  It would be excellent for users to be able to look at a
> > chart
> > > > that compares features across the main NoSQL products before they
> > > download
> > > > couchdb.  I don't think it should be explicit marketing, but just as
> > fair
> > > > and objective as we can be.  If there is a better fit for a user, I
> > think
> > > > it is in our best interest to help them find the other product.
> > > >
> > > >
> > > > In short, if we are not a project just for a small set of people to
> > work
> > > on
> > > > to "scratch an itch" we need to collect into a usable document what
> are
> > > our
> > > > product challenges right now, what features are really needed and
> > wanted
> > > by
> > > > the user-base, and set expectations appropriately as early in the
> > > > relationship as possible.
> > > >
> > > >
> > > > Proposed action items:
> > > >
> > > >    1. Decide what kind of open source project we are.  Hopefully this
> > > >    e-mail will get this resolved.  Explicitly set expectations about
> > > > support
> > > >    and priority of non-contributing user requested features/bugs.
> > > >    2. Start brainstorming session on IRC about user
> > > classes/roles/personas.
> > > >    3. Capture what are the other nosql solutions and the feature
> > > >    differences.
> > > >    4. Identify  the innovation branches of couchdb (example is
> RCouch),
> > > and
> > > >    why it was branched, as well as how successful was it?
> > > >    5. Analyze the mailing lists to build a list of common complaints
> > and
> > > >    requests.
> > > >    6. Communicate new features status monthly in user mailing list.
> > > >    7. Communicate top bug status and impact monthly in the user
> mailing
> > > >    list.
> > > >    8. Go out of our way to solicit feed-back on a regular basis from
> > > >    people/companies we know are using couchdb.  Do not wait for them
> to
> > > > tell
> > > >    you something is wrong.  They may abandon the product without ever
> > > > saying
> > > >    anything.
> > > >
> > > >
> > > > I list these as things that I am willing to start doing or help with
> if
> > > the
> > > > community decides we should do any of them.
> > > >
> > >
> > >
> > >
> > > --
> > > NS
> > >
> >
>
>
>
> --
> NS
>

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

Done.

On Fri, Sep 28, 2012 at 8:20 PM, Bryan Green <db...@gmail.com> wrote:

> Bryan Green




-- 
NS

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

Actually my user name is Bryan Green

On Fri, Sep 28, 2012 at 2:10 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Bryan, I preferred your original framing! (i.e. I can help you, as you seem
> to know what you're doing! Not the other way around.) Like I said, I'm
> still learning this PM business. I have a bunch of thoughts about what we
> need to do, scattered about the place.
>
> A wiki page would be a good place to collect our ideas.
>
> Give me your wiki username and I will add you to the contributors group.
>
> On Fri, Sep 28, 2012 at 7:59 PM, Bryan Green <db...@gmail.com>
> wrote:
>
> > Noah,
> >    I would be more than happy to help you out in anyway I can.  I am new
> to
> > this project,
> > so just let me know how I can help you in your PM role.  I would love to
> > have access
> > to the wiki to start a page.
> >
> > - bryan
> >
> > On Fri, Sep 28, 2012 at 1:41 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> > > Brian, wow! It's great to see you so excited about this.
> > >
> > > For what it's worth, I had expected that I would be doing the PM
> stuff. I
> > > am a PM in my day job, though I am still learning. I think we should
> form
> > > an informal (heh!) PM team and take things from there. Perhaps a wiki
> > page
> > > would be a good start.
> > >
> > > Anyone else interested in joining this PM team? I'm looking at you, PMC
> > > members.
> > >
> > > Your action items sound great. I would just caution though that we
> have a
> > > lot of stuff to catch up on at the moment. And I think we should focus
> > our
> > > efforts on the big items in our pipeline before we start introducing PM
> > > activities. (I only have so many hours per week to devote to CouchDB,
> > and I
> > > need to make sure I'm spending them wisely.)
> > >
> > > Let's focus on getting the docs integrated, and then chasing up
> BigCouch.
> > > And then I think we should focus on the stuff you mention. Though, my
> > next
> > > biggest priority is actually implementing a release cadence.
> > >
> > > Also, I think we should be doing content marketing. Getting people to
> > > contribute to our blog. Establish ourselves as thought leaders in this
> > > space. J. Chris used to do a lot of this, but he doesn't blog about
> > CouchDB
> > > so much any more.
> > >
> > > And FWIW, we're not just a scratch our itch project. ;)
> > >
> > > On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com>
> > > wrote:
> > >
> > > > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dch@jsonified.com
> >
> > > > wrote:
> > > >
> > > > > On 26 September 2012 13:03, Bryan Green <db...@gmail.com>
> > > wrote:
> > > > > > Hello everyone,
> > > > > >     I would be more than happy to help with the product
> management
> > > > area.
> > > > > >  Just let me know who else is really interested in helping in
> that
> > > area
> > > > > and
> > > > > > we can start talking.  I have extensive experience in product
> > > > > management--
> > > > > > doing and mentoring.
> > > > > >
> > > > > > - bryan
> > > > >
> > > > > Given I have no experience in that I'll put my hand up. Here's a
> good
> > > > > place to start on that. With whatever product mgmt is. I assume it
> > > > > involves copious quantities of beer.
> > > > >
> > > > > A+
> > > > > Dave
> > > > >
> > > > *Product management is focused on finding, documenting, and
> > prioritizing
> > > > what users of the product need and/or want the product to accomplish
> > for
> > > > them.*
> > > >
> > > >
> > > > All of us have our own reasons to work on and use couchdb, and we
> > > probably
> > > > know what couchdb does, but what is our goal as a product team?  What
> > is
> > > > the mission of the Couchdb project?  Is it only a "scratch an itch"
> > > project
> > > > for the developers who donate their time to it, or is it a project
> > that,
> > > > also, actively listens to non-contributor users.  There is no right
> or
> > > > wrong answer in my opinion, but we do need to establish the
> > expectations
> > > of
> > > > the user before they download couchdb.  If we are mainly a "scratch
> an
> > > > itch" project it will make some of what follows in this e-mail moot.
> >  Our
> > > > marketing on the web-site needs to make it explicit that we are not
> > > overly
> > > > interested in supporting non-contributing users and their problems,
> if
> > > that
> > > > is our position.  This will save a bitter taste in the mouth of the
> > user
> > > > when they don't get the support they think they should.
> > > >
> > > >
> > > > It would also help if we could be more proactive in communicating the
> > > > status of known bugs, and their impact, in existing releases and
> > planned
> > > > new features.  We could accomplish this by sending an alert e-mail
> sent
> > > to
> > > > the users mailing list, or on a page of the web-site. I think once a
> > > month
> > > > would be acceptable.  The key would be that it would be a summary of
> > the
> > > > bug, or feature, and it's impact.
> > > >
> > > >
> > > > When it comes to identifying what we should be working on next, I
> think
> > > it
> > > > is great that we have really good minds within the project that are
> > > capable
> > > > of idea generation for the product, but we need to expand this out
> more
> > > to
> > > > the community.  We need to develop user personas, use cases, and what
> > the
> > > > "competition" is doing.
> > > >
> > > >
> > > > A starting point for all of this could be to catalog the branches of
> > > > couchdb and analyze why the branch was created and how successful it
> > has
> > > > been.  We need to get feedback from our users about what they are
> using
> > > > couchdb for, and what work-arounds they feel like they had to do to
> use
> > > > it-- especially work-arounds that they feel like should not have been
> > > > needed.
> > > >
> > > >
> > > > We should brainstorm what user classes/roles we have.  This can be
> done
> > > > through irc or e-mail.  Basically, you just free flow all the
> different
> > > > types of users that you can think of that use couchdb, or should be
> > using
> > > > it.  Then after we have that big list, we will collapse some down
> > (there
> > > > will be duplicates), and finally we will have a smaller list of user
> > > > classes.  We can build personas for each user class.  This eventually
> > > helps
> > > > you understand and identify with your user base.  It also helps
> develop
> > > use
> > > > cases.
> > > >
> > > >
> > > > We should keep up to date on the main NoSQL products out there and
> know
> > > how
> > > > we are different.  We should publicize this information on our
> > web-site.
> > >  I
> > > > think transparency is desirable in all relationships, but especially
> > > with a
> > > > user-base.  It would be excellent for users to be able to look at a
> > chart
> > > > that compares features across the main NoSQL products before they
> > > download
> > > > couchdb.  I don't think it should be explicit marketing, but just as
> > fair
> > > > and objective as we can be.  If there is a better fit for a user, I
> > think
> > > > it is in our best interest to help them find the other product.
> > > >
> > > >
> > > > In short, if we are not a project just for a small set of people to
> > work
> > > on
> > > > to "scratch an itch" we need to collect into a usable document what
> are
> > > our
> > > > product challenges right now, what features are really needed and
> > wanted
> > > by
> > > > the user-base, and set expectations appropriately as early in the
> > > > relationship as possible.
> > > >
> > > >
> > > > Proposed action items:
> > > >
> > > >    1. Decide what kind of open source project we are.  Hopefully this
> > > >    e-mail will get this resolved.  Explicitly set expectations about
> > > > support
> > > >    and priority of non-contributing user requested features/bugs.
> > > >    2. Start brainstorming session on IRC about user
> > > classes/roles/personas.
> > > >    3. Capture what are the other nosql solutions and the feature
> > > >    differences.
> > > >    4. Identify  the innovation branches of couchdb (example is
> RCouch),
> > > and
> > > >    why it was branched, as well as how successful was it?
> > > >    5. Analyze the mailing lists to build a list of common complaints
> > and
> > > >    requests.
> > > >    6. Communicate new features status monthly in user mailing list.
> > > >    7. Communicate top bug status and impact monthly in the user
> mailing
> > > >    list.
> > > >    8. Go out of our way to solicit feed-back on a regular basis from
> > > >    people/companies we know are using couchdb.  Do not wait for them
> to
> > > > tell
> > > >    you something is wrong.  They may abandon the product without ever
> > > > saying
> > > >    anything.
> > > >
> > > >
> > > > I list these as things that I am willing to start doing or help with
> if
> > > the
> > > > community decides we should do any of them.
> > > >
> > >
> > >
> > >
> > > --
> > > NS
> > >
> >
>
>
>
> --
> NS
>

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

Bryan, I preferred your original framing! (i.e. I can help you, as you seem
to know what you're doing! Not the other way around.) Like I said, I'm
still learning this PM business. I have a bunch of thoughts about what we
need to do, scattered about the place.

A wiki page would be a good place to collect our ideas.

Give me your wiki username and I will add you to the contributors group.

On Fri, Sep 28, 2012 at 7:59 PM, Bryan Green <db...@gmail.com> wrote:

> Noah,
>    I would be more than happy to help you out in anyway I can.  I am new to
> this project,
> so just let me know how I can help you in your PM role.  I would love to
> have access
> to the wiki to start a page.
>
> - bryan
>
> On Fri, Sep 28, 2012 at 1:41 PM, Noah Slater <ns...@tumbolia.org> wrote:
>
> > Brian, wow! It's great to see you so excited about this.
> >
> > For what it's worth, I had expected that I would be doing the PM stuff. I
> > am a PM in my day job, though I am still learning. I think we should form
> > an informal (heh!) PM team and take things from there. Perhaps a wiki
> page
> > would be a good start.
> >
> > Anyone else interested in joining this PM team? I'm looking at you, PMC
> > members.
> >
> > Your action items sound great. I would just caution though that we have a
> > lot of stuff to catch up on at the moment. And I think we should focus
> our
> > efforts on the big items in our pipeline before we start introducing PM
> > activities. (I only have so many hours per week to devote to CouchDB,
> and I
> > need to make sure I'm spending them wisely.)
> >
> > Let's focus on getting the docs integrated, and then chasing up BigCouch.
> > And then I think we should focus on the stuff you mention. Though, my
> next
> > biggest priority is actually implementing a release cadence.
> >
> > Also, I think we should be doing content marketing. Getting people to
> > contribute to our blog. Establish ourselves as thought leaders in this
> > space. J. Chris used to do a lot of this, but he doesn't blog about
> CouchDB
> > so much any more.
> >
> > And FWIW, we're not just a scratch our itch project. ;)
> >
> > On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com>
> > wrote:
> >
> > > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com>
> > > wrote:
> > >
> > > > On 26 September 2012 13:03, Bryan Green <db...@gmail.com>
> > wrote:
> > > > > Hello everyone,
> > > > >     I would be more than happy to help with the product management
> > > area.
> > > > >  Just let me know who else is really interested in helping in that
> > area
> > > > and
> > > > > we can start talking.  I have extensive experience in product
> > > > management--
> > > > > doing and mentoring.
> > > > >
> > > > > - bryan
> > > >
> > > > Given I have no experience in that I'll put my hand up. Here's a good
> > > > place to start on that. With whatever product mgmt is. I assume it
> > > > involves copious quantities of beer.
> > > >
> > > > A+
> > > > Dave
> > > >
> > > *Product management is focused on finding, documenting, and
> prioritizing
> > > what users of the product need and/or want the product to accomplish
> for
> > > them.*
> > >
> > >
> > > All of us have our own reasons to work on and use couchdb, and we
> > probably
> > > know what couchdb does, but what is our goal as a product team?  What
> is
> > > the mission of the Couchdb project?  Is it only a "scratch an itch"
> > project
> > > for the developers who donate their time to it, or is it a project
> that,
> > > also, actively listens to non-contributor users.  There is no right or
> > > wrong answer in my opinion, but we do need to establish the
> expectations
> > of
> > > the user before they download couchdb.  If we are mainly a "scratch an
> > > itch" project it will make some of what follows in this e-mail moot.
>  Our
> > > marketing on the web-site needs to make it explicit that we are not
> > overly
> > > interested in supporting non-contributing users and their problems, if
> > that
> > > is our position.  This will save a bitter taste in the mouth of the
> user
> > > when they don't get the support they think they should.
> > >
> > >
> > > It would also help if we could be more proactive in communicating the
> > > status of known bugs, and their impact, in existing releases and
> planned
> > > new features.  We could accomplish this by sending an alert e-mail sent
> > to
> > > the users mailing list, or on a page of the web-site. I think once a
> > month
> > > would be acceptable.  The key would be that it would be a summary of
> the
> > > bug, or feature, and it's impact.
> > >
> > >
> > > When it comes to identifying what we should be working on next, I think
> > it
> > > is great that we have really good minds within the project that are
> > capable
> > > of idea generation for the product, but we need to expand this out more
> > to
> > > the community.  We need to develop user personas, use cases, and what
> the
> > > "competition" is doing.
> > >
> > >
> > > A starting point for all of this could be to catalog the branches of
> > > couchdb and analyze why the branch was created and how successful it
> has
> > > been.  We need to get feedback from our users about what they are using
> > > couchdb for, and what work-arounds they feel like they had to do to use
> > > it-- especially work-arounds that they feel like should not have been
> > > needed.
> > >
> > >
> > > We should brainstorm what user classes/roles we have.  This can be done
> > > through irc or e-mail.  Basically, you just free flow all the different
> > > types of users that you can think of that use couchdb, or should be
> using
> > > it.  Then after we have that big list, we will collapse some down
> (there
> > > will be duplicates), and finally we will have a smaller list of user
> > > classes.  We can build personas for each user class.  This eventually
> > helps
> > > you understand and identify with your user base.  It also helps develop
> > use
> > > cases.
> > >
> > >
> > > We should keep up to date on the main NoSQL products out there and know
> > how
> > > we are different.  We should publicize this information on our
> web-site.
> >  I
> > > think transparency is desirable in all relationships, but especially
> > with a
> > > user-base.  It would be excellent for users to be able to look at a
> chart
> > > that compares features across the main NoSQL products before they
> > download
> > > couchdb.  I don't think it should be explicit marketing, but just as
> fair
> > > and objective as we can be.  If there is a better fit for a user, I
> think
> > > it is in our best interest to help them find the other product.
> > >
> > >
> > > In short, if we are not a project just for a small set of people to
> work
> > on
> > > to "scratch an itch" we need to collect into a usable document what are
> > our
> > > product challenges right now, what features are really needed and
> wanted
> > by
> > > the user-base, and set expectations appropriately as early in the
> > > relationship as possible.
> > >
> > >
> > > Proposed action items:
> > >
> > >    1. Decide what kind of open source project we are.  Hopefully this
> > >    e-mail will get this resolved.  Explicitly set expectations about
> > > support
> > >    and priority of non-contributing user requested features/bugs.
> > >    2. Start brainstorming session on IRC about user
> > classes/roles/personas.
> > >    3. Capture what are the other nosql solutions and the feature
> > >    differences.
> > >    4. Identify  the innovation branches of couchdb (example is RCouch),
> > and
> > >    why it was branched, as well as how successful was it?
> > >    5. Analyze the mailing lists to build a list of common complaints
> and
> > >    requests.
> > >    6. Communicate new features status monthly in user mailing list.
> > >    7. Communicate top bug status and impact monthly in the user mailing
> > >    list.
> > >    8. Go out of our way to solicit feed-back on a regular basis from
> > >    people/companies we know are using couchdb.  Do not wait for them to
> > > tell
> > >    you something is wrong.  They may abandon the product without ever
> > > saying
> > >    anything.
> > >
> > >
> > > I list these as things that I am willing to start doing or help with if
> > the
> > > community decides we should do any of them.
> > >
> >
> >
> >
> > --
> > NS
> >
>



-- 
NS

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

Noah,
   I would be more than happy to help you out in anyway I can.  I am new to
this project,
so just let me know how I can help you in your PM role.  I would love to
have access
to the wiki to start a page.

- bryan

On Fri, Sep 28, 2012 at 1:41 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Brian, wow! It's great to see you so excited about this.
>
> For what it's worth, I had expected that I would be doing the PM stuff. I
> am a PM in my day job, though I am still learning. I think we should form
> an informal (heh!) PM team and take things from there. Perhaps a wiki page
> would be a good start.
>
> Anyone else interested in joining this PM team? I'm looking at you, PMC
> members.
>
> Your action items sound great. I would just caution though that we have a
> lot of stuff to catch up on at the moment. And I think we should focus our
> efforts on the big items in our pipeline before we start introducing PM
> activities. (I only have so many hours per week to devote to CouchDB, and I
> need to make sure I'm spending them wisely.)
>
> Let's focus on getting the docs integrated, and then chasing up BigCouch.
> And then I think we should focus on the stuff you mention. Though, my next
> biggest priority is actually implementing a release cadence.
>
> Also, I think we should be doing content marketing. Getting people to
> contribute to our blog. Establish ourselves as thought leaders in this
> space. J. Chris used to do a lot of this, but he doesn't blog about CouchDB
> so much any more.
>
> And FWIW, we're not just a scratch our itch project. ;)
>
> On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com>
> wrote:
>
> > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com>
> > wrote:
> >
> > > On 26 September 2012 13:03, Bryan Green <db...@gmail.com>
> wrote:
> > > > Hello everyone,
> > > >     I would be more than happy to help with the product management
> > area.
> > > >  Just let me know who else is really interested in helping in that
> area
> > > and
> > > > we can start talking.  I have extensive experience in product
> > > management--
> > > > doing and mentoring.
> > > >
> > > > - bryan
> > >
> > > Given I have no experience in that I'll put my hand up. Here's a good
> > > place to start on that. With whatever product mgmt is. I assume it
> > > involves copious quantities of beer.
> > >
> > > A+
> > > Dave
> > >
> > *Product management is focused on finding, documenting, and prioritizing
> > what users of the product need and/or want the product to accomplish for
> > them.*
> >
> >
> > All of us have our own reasons to work on and use couchdb, and we
> probably
> > know what couchdb does, but what is our goal as a product team?  What is
> > the mission of the Couchdb project?  Is it only a "scratch an itch"
> project
> > for the developers who donate their time to it, or is it a project that,
> > also, actively listens to non-contributor users.  There is no right or
> > wrong answer in my opinion, but we do need to establish the expectations
> of
> > the user before they download couchdb.  If we are mainly a "scratch an
> > itch" project it will make some of what follows in this e-mail moot.  Our
> > marketing on the web-site needs to make it explicit that we are not
> overly
> > interested in supporting non-contributing users and their problems, if
> that
> > is our position.  This will save a bitter taste in the mouth of the user
> > when they don't get the support they think they should.
> >
> >
> > It would also help if we could be more proactive in communicating the
> > status of known bugs, and their impact, in existing releases and planned
> > new features.  We could accomplish this by sending an alert e-mail sent
> to
> > the users mailing list, or on a page of the web-site. I think once a
> month
> > would be acceptable.  The key would be that it would be a summary of the
> > bug, or feature, and it's impact.
> >
> >
> > When it comes to identifying what we should be working on next, I think
> it
> > is great that we have really good minds within the project that are
> capable
> > of idea generation for the product, but we need to expand this out more
> to
> > the community.  We need to develop user personas, use cases, and what the
> > "competition" is doing.
> >
> >
> > A starting point for all of this could be to catalog the branches of
> > couchdb and analyze why the branch was created and how successful it has
> > been.  We need to get feedback from our users about what they are using
> > couchdb for, and what work-arounds they feel like they had to do to use
> > it-- especially work-arounds that they feel like should not have been
> > needed.
> >
> >
> > We should brainstorm what user classes/roles we have.  This can be done
> > through irc or e-mail.  Basically, you just free flow all the different
> > types of users that you can think of that use couchdb, or should be using
> > it.  Then after we have that big list, we will collapse some down (there
> > will be duplicates), and finally we will have a smaller list of user
> > classes.  We can build personas for each user class.  This eventually
> helps
> > you understand and identify with your user base.  It also helps develop
> use
> > cases.
> >
> >
> > We should keep up to date on the main NoSQL products out there and know
> how
> > we are different.  We should publicize this information on our web-site.
>  I
> > think transparency is desirable in all relationships, but especially
> with a
> > user-base.  It would be excellent for users to be able to look at a chart
> > that compares features across the main NoSQL products before they
> download
> > couchdb.  I don't think it should be explicit marketing, but just as fair
> > and objective as we can be.  If there is a better fit for a user, I think
> > it is in our best interest to help them find the other product.
> >
> >
> > In short, if we are not a project just for a small set of people to work
> on
> > to "scratch an itch" we need to collect into a usable document what are
> our
> > product challenges right now, what features are really needed and wanted
> by
> > the user-base, and set expectations appropriately as early in the
> > relationship as possible.
> >
> >
> > Proposed action items:
> >
> >    1. Decide what kind of open source project we are.  Hopefully this
> >    e-mail will get this resolved.  Explicitly set expectations about
> > support
> >    and priority of non-contributing user requested features/bugs.
> >    2. Start brainstorming session on IRC about user
> classes/roles/personas.
> >    3. Capture what are the other nosql solutions and the feature
> >    differences.
> >    4. Identify  the innovation branches of couchdb (example is RCouch),
> and
> >    why it was branched, as well as how successful was it?
> >    5. Analyze the mailing lists to build a list of common complaints and
> >    requests.
> >    6. Communicate new features status monthly in user mailing list.
> >    7. Communicate top bug status and impact monthly in the user mailing
> >    list.
> >    8. Go out of our way to solicit feed-back on a regular basis from
> >    people/companies we know are using couchdb.  Do not wait for them to
> > tell
> >    you something is wrong.  They may abandon the product without ever
> > saying
> >    anything.
> >
> >
> > I list these as things that I am willing to start doing or help with if
> the
> > community decides we should do any of them.
> >
>
>
>
> --
> NS
>

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

P.S. Don't let me block you though, if you want to forge ahead, I will help
you out. For deffo!

On Fri, Sep 28, 2012 at 7:41 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Brian, wow! It's great to see you so excited about this.
>
> For what it's worth, I had expected that I would be doing the PM stuff. I
> am a PM in my day job, though I am still learning. I think we should form
> an informal (heh!) PM team and take things from there. Perhaps a wiki page
> would be a good start.
>
> Anyone else interested in joining this PM team? I'm looking at you, PMC
> members.
>
> Your action items sound great. I would just caution though that we have a
> lot of stuff to catch up on at the moment. And I think we should focus our
> efforts on the big items in our pipeline before we start introducing PM
> activities. (I only have so many hours per week to devote to CouchDB, and I
> need to make sure I'm spending them wisely.)
>
> Let's focus on getting the docs integrated, and then chasing up BigCouch.
> And then I think we should focus on the stuff you mention. Though, my next
> biggest priority is actually implementing a release cadence.
>
> Also, I think we should be doing content marketing. Getting people to
> contribute to our blog. Establish ourselves as thought leaders in this
> space. J. Chris used to do a lot of this, but he doesn't blog about CouchDB
> so much any more.
>
> And FWIW, we're not just a scratch our itch project. ;)
>
>
> On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com>wrote:
>
>> On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com>
>> wrote:
>>
>> > On 26 September 2012 13:03, Bryan Green <db...@gmail.com> wrote:
>> > > Hello everyone,
>> > >     I would be more than happy to help with the product management
>> area.
>> > >  Just let me know who else is really interested in helping in that
>> area
>> > and
>> > > we can start talking.  I have extensive experience in product
>> > management--
>> > > doing and mentoring.
>> > >
>> > > - bryan
>> >
>> > Given I have no experience in that I'll put my hand up. Here's a good
>> > place to start on that. With whatever product mgmt is. I assume it
>> > involves copious quantities of beer.
>> >
>> > A+
>> > Dave
>> >
>> *Product management is focused on finding, documenting, and prioritizing
>> what users of the product need and/or want the product to accomplish for
>> them.*
>>
>>
>> All of us have our own reasons to work on and use couchdb, and we probably
>> know what couchdb does, but what is our goal as a product team?  What is
>> the mission of the Couchdb project?  Is it only a "scratch an itch"
>> project
>> for the developers who donate their time to it, or is it a project that,
>> also, actively listens to non-contributor users.  There is no right or
>> wrong answer in my opinion, but we do need to establish the expectations
>> of
>> the user before they download couchdb.  If we are mainly a "scratch an
>> itch" project it will make some of what follows in this e-mail moot.  Our
>> marketing on the web-site needs to make it explicit that we are not overly
>> interested in supporting non-contributing users and their problems, if
>> that
>> is our position.  This will save a bitter taste in the mouth of the user
>> when they don't get the support they think they should.
>>
>>
>> It would also help if we could be more proactive in communicating the
>> status of known bugs, and their impact, in existing releases and planned
>> new features.  We could accomplish this by sending an alert e-mail sent to
>> the users mailing list, or on a page of the web-site. I think once a month
>> would be acceptable.  The key would be that it would be a summary of the
>> bug, or feature, and it's impact.
>>
>>
>> When it comes to identifying what we should be working on next, I think it
>> is great that we have really good minds within the project that are
>> capable
>> of idea generation for the product, but we need to expand this out more to
>> the community.  We need to develop user personas, use cases, and what the
>> "competition" is doing.
>>
>>
>> A starting point for all of this could be to catalog the branches of
>> couchdb and analyze why the branch was created and how successful it has
>> been.  We need to get feedback from our users about what they are using
>> couchdb for, and what work-arounds they feel like they had to do to use
>> it-- especially work-arounds that they feel like should not have been
>> needed.
>>
>>
>> We should brainstorm what user classes/roles we have.  This can be done
>> through irc or e-mail.  Basically, you just free flow all the different
>> types of users that you can think of that use couchdb, or should be using
>> it.  Then after we have that big list, we will collapse some down (there
>> will be duplicates), and finally we will have a smaller list of user
>> classes.  We can build personas for each user class.  This eventually
>> helps
>> you understand and identify with your user base.  It also helps develop
>> use
>> cases.
>>
>>
>> We should keep up to date on the main NoSQL products out there and know
>> how
>> we are different.  We should publicize this information on our web-site.
>>  I
>> think transparency is desirable in all relationships, but especially with
>> a
>> user-base.  It would be excellent for users to be able to look at a chart
>> that compares features across the main NoSQL products before they download
>> couchdb.  I don't think it should be explicit marketing, but just as fair
>> and objective as we can be.  If there is a better fit for a user, I think
>> it is in our best interest to help them find the other product.
>>
>>
>> In short, if we are not a project just for a small set of people to work
>> on
>> to "scratch an itch" we need to collect into a usable document what are
>> our
>> product challenges right now, what features are really needed and wanted
>> by
>> the user-base, and set expectations appropriately as early in the
>> relationship as possible.
>>
>>
>> Proposed action items:
>>
>>    1. Decide what kind of open source project we are.  Hopefully this
>>    e-mail will get this resolved.  Explicitly set expectations about
>> support
>>    and priority of non-contributing user requested features/bugs.
>>    2. Start brainstorming session on IRC about user
>> classes/roles/personas.
>>    3. Capture what are the other nosql solutions and the feature
>>    differences.
>>    4. Identify  the innovation branches of couchdb (example is RCouch),
>> and
>>    why it was branched, as well as how successful was it?
>>    5. Analyze the mailing lists to build a list of common complaints and
>>    requests.
>>    6. Communicate new features status monthly in user mailing list.
>>    7. Communicate top bug status and impact monthly in the user mailing
>>    list.
>>    8. Go out of our way to solicit feed-back on a regular basis from
>>    people/companies we know are using couchdb.  Do not wait for them to
>> tell
>>    you something is wrong.  They may abandon the product without ever
>> saying
>>    anything.
>>
>>
>> I list these as things that I am willing to start doing or help with if
>> the
>> community decides we should do any of them.
>>
>
>
>
> --
> NS
>



-- 
NS

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

Okie dokie.

On Sat, Sep 29, 2012 at 10:17 AM, Dirkjan Ochtman <di...@ochtman.nl>wrote:

> On Fri, Sep 28, 2012 at 8:41 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Let's focus on getting the docs integrated, and then chasing up BigCouch.
> > And then I think we should focus on the stuff you mention. Though, my
> next
> > biggest priority is actually implementing a release cadence.
>
> Can I suggest that the 1.3 release is prioritized over the BigCouch stuff?
>
> Cheers,
>
> Dirkjan
>



-- 
NS

Re: Part1: What's up dev? About energy.

[Dirkjan Ochtman <di...@ochtman.nl>]

On Fri, Sep 28, 2012 at 8:41 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Let's focus on getting the docs integrated, and then chasing up BigCouch.
> And then I think we should focus on the stuff you mention. Though, my next
> biggest priority is actually implementing a release cadence.

Can I suggest that the 1.3 release is prioritized over the BigCouch stuff?

Cheers,

Dirkjan

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

Brian, wow! It's great to see you so excited about this.

For what it's worth, I had expected that I would be doing the PM stuff. I
am a PM in my day job, though I am still learning. I think we should form
an informal (heh!) PM team and take things from there. Perhaps a wiki page
would be a good start.

Anyone else interested in joining this PM team? I'm looking at you, PMC
members.

Your action items sound great. I would just caution though that we have a
lot of stuff to catch up on at the moment. And I think we should focus our
efforts on the big items in our pipeline before we start introducing PM
activities. (I only have so many hours per week to devote to CouchDB, and I
need to make sure I'm spending them wisely.)

Let's focus on getting the docs integrated, and then chasing up BigCouch.
And then I think we should focus on the stuff you mention. Though, my next
biggest priority is actually implementing a release cadence.

Also, I think we should be doing content marketing. Getting people to
contribute to our blog. Establish ourselves as thought leaders in this
space. J. Chris used to do a lot of this, but he doesn't blog about CouchDB
so much any more.

And FWIW, we're not just a scratch our itch project. ;)

On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <db...@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com>
> wrote:
>
> > On 26 September 2012 13:03, Bryan Green <db...@gmail.com> wrote:
> > > Hello everyone,
> > >     I would be more than happy to help with the product management
> area.
> > >  Just let me know who else is really interested in helping in that area
> > and
> > > we can start talking.  I have extensive experience in product
> > management--
> > > doing and mentoring.
> > >
> > > - bryan
> >
> > Given I have no experience in that I'll put my hand up. Here's a good
> > place to start on that. With whatever product mgmt is. I assume it
> > involves copious quantities of beer.
> >
> > A+
> > Dave
> >
> *Product management is focused on finding, documenting, and prioritizing
> what users of the product need and/or want the product to accomplish for
> them.*
>
>
> All of us have our own reasons to work on and use couchdb, and we probably
> know what couchdb does, but what is our goal as a product team?  What is
> the mission of the Couchdb project?  Is it only a "scratch an itch" project
> for the developers who donate their time to it, or is it a project that,
> also, actively listens to non-contributor users.  There is no right or
> wrong answer in my opinion, but we do need to establish the expectations of
> the user before they download couchdb.  If we are mainly a "scratch an
> itch" project it will make some of what follows in this e-mail moot.  Our
> marketing on the web-site needs to make it explicit that we are not overly
> interested in supporting non-contributing users and their problems, if that
> is our position.  This will save a bitter taste in the mouth of the user
> when they don't get the support they think they should.
>
>
> It would also help if we could be more proactive in communicating the
> status of known bugs, and their impact, in existing releases and planned
> new features.  We could accomplish this by sending an alert e-mail sent to
> the users mailing list, or on a page of the web-site. I think once a month
> would be acceptable.  The key would be that it would be a summary of the
> bug, or feature, and it's impact.
>
>
> When it comes to identifying what we should be working on next, I think it
> is great that we have really good minds within the project that are capable
> of idea generation for the product, but we need to expand this out more to
> the community.  We need to develop user personas, use cases, and what the
> "competition" is doing.
>
>
> A starting point for all of this could be to catalog the branches of
> couchdb and analyze why the branch was created and how successful it has
> been.  We need to get feedback from our users about what they are using
> couchdb for, and what work-arounds they feel like they had to do to use
> it-- especially work-arounds that they feel like should not have been
> needed.
>
>
> We should brainstorm what user classes/roles we have.  This can be done
> through irc or e-mail.  Basically, you just free flow all the different
> types of users that you can think of that use couchdb, or should be using
> it.  Then after we have that big list, we will collapse some down (there
> will be duplicates), and finally we will have a smaller list of user
> classes.  We can build personas for each user class.  This eventually helps
> you understand and identify with your user base.  It also helps develop use
> cases.
>
>
> We should keep up to date on the main NoSQL products out there and know how
> we are different.  We should publicize this information on our web-site.  I
> think transparency is desirable in all relationships, but especially with a
> user-base.  It would be excellent for users to be able to look at a chart
> that compares features across the main NoSQL products before they download
> couchdb.  I don't think it should be explicit marketing, but just as fair
> and objective as we can be.  If there is a better fit for a user, I think
> it is in our best interest to help them find the other product.
>
>
> In short, if we are not a project just for a small set of people to work on
> to "scratch an itch" we need to collect into a usable document what are our
> product challenges right now, what features are really needed and wanted by
> the user-base, and set expectations appropriately as early in the
> relationship as possible.
>
>
> Proposed action items:
>
>    1. Decide what kind of open source project we are.  Hopefully this
>    e-mail will get this resolved.  Explicitly set expectations about
> support
>    and priority of non-contributing user requested features/bugs.
>    2. Start brainstorming session on IRC about user classes/roles/personas.
>    3. Capture what are the other nosql solutions and the feature
>    differences.
>    4. Identify  the innovation branches of couchdb (example is RCouch), and
>    why it was branched, as well as how successful was it?
>    5. Analyze the mailing lists to build a list of common complaints and
>    requests.
>    6. Communicate new features status monthly in user mailing list.
>    7. Communicate top bug status and impact monthly in the user mailing
>    list.
>    8. Go out of our way to solicit feed-back on a regular basis from
>    people/companies we know are using couchdb.  Do not wait for them to
> tell
>    you something is wrong.  They may abandon the product without ever
> saying
>    anything.
>
>
> I list these as things that I am willing to start doing or help with if the
> community decides we should do any of them.
>



-- 
NS

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dc...@jsonified.com> wrote:

> On 26 September 2012 13:03, Bryan Green <db...@gmail.com> wrote:
> > Hello everyone,
> >     I would be more than happy to help with the product management area.
> >  Just let me know who else is really interested in helping in that area
> and
> > we can start talking.  I have extensive experience in product
> management--
> > doing and mentoring.
> >
> > - bryan
>
> Given I have no experience in that I'll put my hand up. Here's a good
> place to start on that. With whatever product mgmt is. I assume it
> involves copious quantities of beer.
>
> A+
> Dave
>
*Product management is focused on finding, documenting, and prioritizing
what users of the product need and/or want the product to accomplish for
them.*


All of us have our own reasons to work on and use couchdb, and we probably
know what couchdb does, but what is our goal as a product team?  What is
the mission of the Couchdb project?  Is it only a "scratch an itch" project
for the developers who donate their time to it, or is it a project that,
also, actively listens to non-contributor users.  There is no right or
wrong answer in my opinion, but we do need to establish the expectations of
the user before they download couchdb.  If we are mainly a "scratch an
itch" project it will make some of what follows in this e-mail moot.  Our
marketing on the web-site needs to make it explicit that we are not overly
interested in supporting non-contributing users and their problems, if that
is our position.  This will save a bitter taste in the mouth of the user
when they don't get the support they think they should.


It would also help if we could be more proactive in communicating the
status of known bugs, and their impact, in existing releases and planned
new features.  We could accomplish this by sending an alert e-mail sent to
the users mailing list, or on a page of the web-site. I think once a month
would be acceptable.  The key would be that it would be a summary of the
bug, or feature, and it's impact.


When it comes to identifying what we should be working on next, I think it
is great that we have really good minds within the project that are capable
of idea generation for the product, but we need to expand this out more to
the community.  We need to develop user personas, use cases, and what the
"competition" is doing.


A starting point for all of this could be to catalog the branches of
couchdb and analyze why the branch was created and how successful it has
been.  We need to get feedback from our users about what they are using
couchdb for, and what work-arounds they feel like they had to do to use
it-- especially work-arounds that they feel like should not have been
needed.


We should brainstorm what user classes/roles we have.  This can be done
through irc or e-mail.  Basically, you just free flow all the different
types of users that you can think of that use couchdb, or should be using
it.  Then after we have that big list, we will collapse some down (there
will be duplicates), and finally we will have a smaller list of user
classes.  We can build personas for each user class.  This eventually helps
you understand and identify with your user base.  It also helps develop use
cases.


We should keep up to date on the main NoSQL products out there and know how
we are different.  We should publicize this information on our web-site.  I
think transparency is desirable in all relationships, but especially with a
user-base.  It would be excellent for users to be able to look at a chart
that compares features across the main NoSQL products before they download
couchdb.  I don't think it should be explicit marketing, but just as fair
and objective as we can be.  If there is a better fit for a user, I think
it is in our best interest to help them find the other product.


In short, if we are not a project just for a small set of people to work on
to "scratch an itch" we need to collect into a usable document what are our
product challenges right now, what features are really needed and wanted by
the user-base, and set expectations appropriately as early in the
relationship as possible.


Proposed action items:

   1. Decide what kind of open source project we are.  Hopefully this
   e-mail will get this resolved.  Explicitly set expectations about support
   and priority of non-contributing user requested features/bugs.
   2. Start brainstorming session on IRC about user classes/roles/personas.
   3. Capture what are the other nosql solutions and the feature
   differences.
   4. Identify  the innovation branches of couchdb (example is RCouch), and
   why it was branched, as well as how successful was it?
   5. Analyze the mailing lists to build a list of common complaints and
   requests.
   6. Communicate new features status monthly in user mailing list.
   7. Communicate top bug status and impact monthly in the user mailing
   list.
   8. Go out of our way to solicit feed-back on a regular basis from
   people/companies we know are using couchdb.  Do not wait for them to tell
   you something is wrong.  They may abandon the product without ever saying
   anything.


I list these as things that I am willing to start doing or help with if the
community decides we should do any of them.

Re: Part1: What's up dev? About energy.

[Dave Cottlehuber <dc...@jsonified.com>]

On 26 September 2012 13:03, Bryan Green <db...@gmail.com> wrote:
> Hello everyone,
>     I would be more than happy to help with the product management area.
>  Just let me know who else is really interested in helping in that area and
> we can start talking.  I have extensive experience in product management--
> doing and mentoring.
>
> - bryan

Given I have no experience in that I'll put my hand up. Here's a good
place to start on that. With whatever product mgmt is. I assume it
involves copious quantities of beer.

A+
Dave

Re: Part1: What's up dev? About energy.

[Bryan Green <db...@gmail.com>]

Hello everyone,
    I would be more than happy to help with the product management area.
 Just let me know who else is really interested in helping in that area and
we can start talking.  I have extensive experience in product management--
doing and mentoring.

- bryan

On Mon, Sep 24, 2012 at 5:41 AM, Noah Slater <ns...@tumbolia.org> wrote:

> Some good stuff in this Benoit.
>
> I think we need to kick some life back into the team as well.
>
> Here are my ideas:
>
> * Set up a weekly team meeting on IRC. Attendance strictly non-compulsory.
> Minutes archived on wiki and sent to list afterwards. Get everyone to speak
> up and report on status, and any items for discussion. This mirrors a
> short-lived, but very useful, "CouchDB heartbeat" that me and Jan were
> doing in private during our darkest hour this year.
>
> * Set up informal teams, or work groups. No team leaders.
> No hierarchy or bureaucracy. Just promote the idea that people should get
> organised around specific areas. Each "team" get's a wiki space. People can
> elect to be in the team. Again, no team leaders. Just groups of people. For
> example, me, Paul, and Bob are the release team at the moment. This team
> has existed for years, but we've not documented it anywhere. Let's do that.
> And ask other people to do the same around areas they give a shit about.
>
> * Kick of product management and marketing activities. I'm talking feature
> lifecycle stuff. Collecting requests and use cases. Maintaining a roadmap.
> Maintaining docs. Setting up a release cadence. Working with PR, bloggers,
> etc, ever time we launch. Open up blog itself to the community. We need to
> blog about non-release stuff. Demonstrate that we're thought leaders.
>
> * Start to recognise 3rd party projects by either merging them in directly
> (BigCouch), creating ASF sub-projects, or learning from them, and blessing
> certain ideas. CouchApps is, apparently controversial. One option might be
> to re-implement CouchApps in core, taking lessons from 3rd party projects,
> but not merging any in directly. The goal being to say that CouchDB core is
> both a clustered database and an app platform. No need to depend on forks
> or external projects. This shit is important enough to the community that
> we're making that functionality core.
>
> Benoit, I know you're going to have some concerns about what exactly I mean
> by some of these points. I would like to say, for now, let's put the
> discussion on hold. And work through these one by one. Or at
> least, separately. I'm trying to devote more hours in the week to CouchDB.
> And I only have time to think about and work on one of these things at a
> time. I am sure other people feel the same. So, let's be aware that there
> are things to sort out here, and different perspectives to unite, and just
> put it on the back burner, and pick one of them for now.
>
> I think the first thing we need to look at is setting up a weekly IRC
> meeting. I will send out a separate email for that now.
>
> On Mon, Sep 24, 2012 at 10:20 AM, Benoit Chesneau <bchesneau@gmail.com
> >wrote:
>
> > What's up devs?
> >
> > Following our last discussion with @nslater on twitter, I wanted to say
> > a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
> > time really. These days I miss what make me enjoy CouchDB at the
> > beginning. The energy you could feel on the chan and sometimes IRL. The
> > time when anyone was aware of who was working on a feature. Which
> > feature was in progress. Today IRC is more like a support channel where
> > sometimes ideas emerge but you don't feel they are very supported. There
> > are private discussion somewhere.  But well they are... private. Same
> > for tickets. We see tickets but more often no real incentive from each
> > others (and I am to blame too) to fix them.
> >
> > Today to be honnest, this lack of energy annoys me a lot. This is quite
> > more important than the rest. At least for me. I don't have 4 devs on
> > the projects working with me in my office where I can speak with each
> > other about possible fixes and such .. Communication inside the project
> > is  really important. Apache CouchDB is an opensource project
> > distributed around the world (at least 2 continents).
> >
> > Anyway I still keep my confidence in the project. I know there have been
> > lot of codes developped around. Today if we don't count the couchbase
> > fork (wich is still named couchdb and all...) there are 2 friendly forks
> > I'm
> > aware of couchdb: bigcouch, refuge.
> >
> > Bigcouch was announced to be merged in. But since then we don't know as
> > couchdb devs how it will be. How can we keep couchdb working standalone
> > and on a cluster. It blocks everything else today for me since I don't
> > know if I will work on a cluster or still can continue to think I can
> > use couchdb standalone on one node (and possiblit migrate to the
> > cluster thing easily). I didn't see anything about in
> > bigcouch recently as well. . As a CouchDB developper I would like to see
> > a branch in couchdb so we can hack on all together or just review or
> > document.
> >
> > Rcouch my own fork which has the following features:
> >
> > - OTP compliant (build an erlang release, support hot upgrades), bigcouch
> > is as well. Today couchdb isn't really erlangish and is based on
> > autotools
> > - static build support. Packages for deb, rpm, macosx, arm platforms
> > - View changes: get changes in an ndex in real time
> > - Replication using view changes
> > - couch_randomdoc : pick a random document inside a db or a view
> > - dnssd : discover couchdb over bonjour in your lan
> > - upnp : make couchdb easily accessible on the net
> > - refuge_spatial: fork of geocouch adapted to use latest couch_index.
> >   (note that a version also exists for bigcouch)
> > - HTTP api based on ranch and cowboy (using mochicow for the
> >   transition). more stable and efficient HTTP handlers
> > - doc read validation (like update validation)
> > - dropbox features (anyone can upload only readers or admins can read
> >   doc uploaded)
> > - some replication fixes.
> > - no refcount db , using a patch from @davisp similar to the one in
> >   bigcouch
> > - ..
> >
> > And coming this week: view merge & cors.
> >
> > I would like to merge it in couchdb as well. But I don't know how. And
> > each time I asked for having a discussion on it it fails because some
> > were busy or anything (but never came back). Can we put a roadmap for
> > that and start to put the code online?
> >
> >
> > Second part about couchapps in next mail.
> >
> > - benoît
> >
>
>
>
> --
> NS
>

Re: Part1: What's up dev? About energy.

[Noah Slater <ns...@tumbolia.org>]

Some good stuff in this Benoit.

I think we need to kick some life back into the team as well.

Here are my ideas:

* Set up a weekly team meeting on IRC. Attendance strictly non-compulsory.
Minutes archived on wiki and sent to list afterwards. Get everyone to speak
up and report on status, and any items for discussion. This mirrors a
short-lived, but very useful, "CouchDB heartbeat" that me and Jan were
doing in private during our darkest hour this year.

* Set up informal teams, or work groups. No team leaders.
No hierarchy or bureaucracy. Just promote the idea that people should get
organised around specific areas. Each "team" get's a wiki space. People can
elect to be in the team. Again, no team leaders. Just groups of people. For
example, me, Paul, and Bob are the release team at the moment. This team
has existed for years, but we've not documented it anywhere. Let's do that.
And ask other people to do the same around areas they give a shit about.

* Kick of product management and marketing activities. I'm talking feature
lifecycle stuff. Collecting requests and use cases. Maintaining a roadmap.
Maintaining docs. Setting up a release cadence. Working with PR, bloggers,
etc, ever time we launch. Open up blog itself to the community. We need to
blog about non-release stuff. Demonstrate that we're thought leaders.

* Start to recognise 3rd party projects by either merging them in directly
(BigCouch), creating ASF sub-projects, or learning from them, and blessing
certain ideas. CouchApps is, apparently controversial. One option might be
to re-implement CouchApps in core, taking lessons from 3rd party projects,
but not merging any in directly. The goal being to say that CouchDB core is
both a clustered database and an app platform. No need to depend on forks
or external projects. This shit is important enough to the community that
we're making that functionality core.

Benoit, I know you're going to have some concerns about what exactly I mean
by some of these points. I would like to say, for now, let's put the
discussion on hold. And work through these one by one. Or at
least, separately. I'm trying to devote more hours in the week to CouchDB.
And I only have time to think about and work on one of these things at a
time. I am sure other people feel the same. So, let's be aware that there
are things to sort out here, and different perspectives to unite, and just
put it on the back burner, and pick one of them for now.

I think the first thing we need to look at is setting up a weekly IRC
meeting. I will send out a separate email for that now.

On Mon, Sep 24, 2012 at 10:20 AM, Benoit Chesneau <bc...@gmail.com>wrote:

> What's up devs?
>
> Following our last discussion with @nslater on twitter, I wanted to say
> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
> time really. These days I miss what make me enjoy CouchDB at the
> beginning. The energy you could feel on the chan and sometimes IRL. The
> time when anyone was aware of who was working on a feature. Which
> feature was in progress. Today IRC is more like a support channel where
> sometimes ideas emerge but you don't feel they are very supported. There
> are private discussion somewhere.  But well they are... private. Same
> for tickets. We see tickets but more often no real incentive from each
> others (and I am to blame too) to fix them.
>
> Today to be honnest, this lack of energy annoys me a lot. This is quite
> more important than the rest. At least for me. I don't have 4 devs on
> the projects working with me in my office where I can speak with each
> other about possible fixes and such .. Communication inside the project
> is  really important. Apache CouchDB is an opensource project
> distributed around the world (at least 2 continents).
>
> Anyway I still keep my confidence in the project. I know there have been
> lot of codes developped around. Today if we don't count the couchbase
> fork (wich is still named couchdb and all...) there are 2 friendly forks
> I'm
> aware of couchdb: bigcouch, refuge.
>
> Bigcouch was announced to be merged in. But since then we don't know as
> couchdb devs how it will be. How can we keep couchdb working standalone
> and on a cluster. It blocks everything else today for me since I don't
> know if I will work on a cluster or still can continue to think I can
> use couchdb standalone on one node (and possiblit migrate to the
> cluster thing easily). I didn't see anything about in
> bigcouch recently as well. . As a CouchDB developper I would like to see
> a branch in couchdb so we can hack on all together or just review or
> document.
>
> Rcouch my own fork which has the following features:
>
> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
> is as well. Today couchdb isn't really erlangish and is based on
> autotools
> - static build support. Packages for deb, rpm, macosx, arm platforms
> - View changes: get changes in an ndex in real time
> - Replication using view changes
> - couch_randomdoc : pick a random document inside a db or a view
> - dnssd : discover couchdb over bonjour in your lan
> - upnp : make couchdb easily accessible on the net
> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>   (note that a version also exists for bigcouch)
> - HTTP api based on ranch and cowboy (using mochicow for the
>   transition). more stable and efficient HTTP handlers
> - doc read validation (like update validation)
> - dropbox features (anyone can upload only readers or admins can read
>   doc uploaded)
> - some replication fixes.
> - no refcount db , using a patch from @davisp similar to the one in
>   bigcouch
> - ..
>
> And coming this week: view merge & cors.
>
> I would like to merge it in couchdb as well. But I don't know how. And
> each time I asked for having a discussion on it it fails because some
> were busy or anything (but never came back). Can we put a roadmap for
> that and start to put the code online?
>
>
> Second part about couchapps in next mail.
>
> - benoît
>



-- 
NS

Re: Part1: What's up dev? About energy.

[Dave Cottlehuber <dc...@jsonified.com>]

}On 24 September 2012 11:20, Benoit Chesneau <bc...@gmail.com> wrote:
> What's up devs?
>
> Following our last discussion with @nslater on twitter, I wanted to say
> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
> time really. These days I miss what make me enjoy CouchDB at the
> beginning. The energy you could feel on the chan and sometimes IRL. The
> time when anyone was aware of who was working on a feature. Which
> feature was in progress. Today IRC is more like a support channel where
> sometimes ideas emerge but you don't feel they are very supported. There
> are private discussion somewhere.  But well they are... private. Same
> for tickets. We see tickets but more often no real incentive from each
> others (and I am to blame too) to fix them.
>
> Today to be honnest, this lack of energy annoys me a lot. This is quite
> more important than the rest. At least for me. I don't have 4 devs on
> the projects working with me in my office where I can speak with each
> other about possible fixes and such .. Communication inside the project
> is  really important. Apache CouchDB is an opensource project
> distributed around the world (at least 2 continents).
>
> Anyway I still keep my confidence in the project. I know there have been
> lot of codes developped around. Today if we don't count the couchbase
> fork (wich is still named couchdb and all...) there are 2 friendly forks I'm
> aware of couchdb: bigcouch, refuge.
>
> Bigcouch was announced to be merged in. But since then we don't know as
> couchdb devs how it will be. How can we keep couchdb working standalone
> and on a cluster. It blocks everything else today for me since I don't
> know if I will work on a cluster or still can continue to think I can
> use couchdb standalone on one node (and possiblit migrate to the
> cluster thing easily). I didn't see anything about in
> bigcouch recently as well. . As a CouchDB developper I would like to see
> a branch in couchdb so we can hack on all together or just review or
> document.
>
> Rcouch my own fork which has the following features:
>
> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
> is as well. Today couchdb isn't really erlangish and is based on
> autotools
> - static build support. Packages for deb, rpm, macosx, arm platforms
> - View changes: get changes in an ndex in real time
> - Replication using view changes
> - couch_randomdoc : pick a random document inside a db or a view
> - dnssd : discover couchdb over bonjour in your lan
> - upnp : make couchdb easily accessible on the net
> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>   (note that a version also exists for bigcouch)
> - HTTP api based on ranch and cowboy (using mochicow for the
>   transition). more stable and efficient HTTP handlers
> - doc read validation (like update validation)
> - dropbox features (anyone can upload only readers or admins can read
>   doc uploaded)
> - some replication fixes.
> - no refcount db , using a patch from @davisp similar to the one in
>   bigcouch
> - ..
>
> And coming this week: view merge & cors.
>
> I would like to merge it in couchdb as well. But I don't know how. And
> each time I asked for having a discussion on it it fails because some
> were busy or anything (but never came back). Can we put a roadmap for
> that and start to put the code online?
>
>
> Second part about couchapps in next mail.
>
> - benoît

I second this. I'd like to be able to look back in a couple of years'
time and say "Wow that's when we pulled it all together", put the C
into OuchDB so to speak :-). I replied to Benoit's build system
thread, did I miss a response from the BigCouch folk? I appreciate its
a huge amount of work to merge & there will be mainly sitting /
waiting on the sidelines for many of us, just let us know where we
could help?

A+
Dave