Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of nslater@tumbolia.org designates
 74.125.82.180 as permitted sender)
References: 
 <CA+Y+445CgtW7Ftx+hgvVnc4Cv-=7uRSwLFL6Q=J0kgKM2xourA@mail.gmail.com>
 <CABvT1DFKaDnCa8mbiS0E36ae+HVCPVB42v2Xfsxodw0oEy41xQ@mail.gmail.com>
 <CA+Y+445DLF=HeWWAm6np0MpfDKy7rz7SAYnD3PE3AauH1eMEkg@mail.gmail.com>
 <0BB4F003-4C8B-441A-9CEF-08782AF170BB@dionne-associates.com>
 <CA+Y+446EzWOveYYHs3HZnrtZrUJ5VcVuk63QOtJ3p4yBbN54uw@mail.gmail.com>
 <AA97DC79-7D23-4681-9FA5-0A7901B013EC@dionne-associates.com>
 <-4709298919342606669@unknownmsgid>
 <CAJNb-9regswTwBE4Frh2X-m=eopN1TqGzd7wBSxx2Xqvjd6EQA@mail.gmail.com>
 <CAJ_m3YDxiXPCnhGOJwMJrZH8WRuW_bx+RiV0Mi1FvZ-DesOLOA@mail.gmail.com>
 <CA+Y+446AJD=vyFOMVeR3tF=kPCZNzzwd0aDnLLjU2EgLJYYn=g@mail.gmail.com>
 <CAHZBNKbqKB-jq0tjYoLfXBEGp8O8ZL-ZmiFu8_UfqwX_-grXiw@mail.gmail.com>
 <CA+Y+446zHtdQCyEyXNN1vva_g680u8MzqLNPtyF2mSzeHcu0dA@mail.gmail.com>
 <CAJ_m3YCb4DHxD-fJ3dHqd9Cfwih=px+e-+-iG4LJJtHcyZMmGw@mail.gmail.com>
 <CAN-3CBKNH2Deo+PuL84C6mXqSHFBiUTvejUJJnLewNOj_rqAJg@mail.gmail.com>
 <CAJNb-9rxNdm5JWApTgF8L0cYK5ouJJYk+XYzUuc0dfaf=rLPPA@mail.gmail.com>
 <4F60C606.5060409@83864.com>
 <CA+Y+446D9rbYcZbra=JJdoo_kzkLsBqqDKE-OY8JPUC5F8-7vw@mail.gmail.com>
 <CAJ_m3YAZs6-yNi1awiLmwYqcXUo2ewfAeagjbBmtrc=Ojz_3cw@mail.gmail.com>
 <CA+Y+446LAjYGD33m2y=HApL3EbOtDgi_uQCBHrbHONOvgOV8NA@mail.gmail.com>
 <CAJ_m3YBfTEMBYXgr=RriU3D8NPFGcwVZS-kBU-KZD_G+GYxjGA@mail.gmail.com>
 <CA+Y+444KcgH2fgWmX2RLqeNjZUHHZdUTO_B+LH46cz2GNrK34g@mail.gmail.com>
 <CAJ_m3YA5r-DGvgFRJEfe9a9dwmY=NgK5+7d0TMs0ao5=Ri79Xw@mail.gmail.com>
 <CA+Y+444Vuj1-MCrkNbLt9HgjWq0OdhcnaWN69Kde3YEZTWNV6w@mail.gmail.com>
 <302B50A4-B2EE-4B01-9EA7-CD46B187C356@dionne-associates.com>
In-Reply-To: <302B50A4-B2EE-4B01-9EA7-CD46B187C356@dionne-associates.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <4AD31852-DF2F-4682-8E27-2F1911EBE5FD@tumbolia.org>
Cc: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
From: Noah Slater <nslater@tumbolia.org>
Subject: Re: 1.2.0 status update
Date: Thu, 15 Mar 2012 18:28:23 +0000
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>

Bob,

Can you explain your remarks?

Thanks,


On 15 Mar 2012, at 17:28, Bob Dionne <dionne@dionne-associates.com> wrote:

> Noah,
>=20
> Sorry, but I disagree. I don't think your experiment worked well at all an=
d I think the approach you are taking is going to alienate people.
>=20
> Best regards,
>=20
> Bob
>=20
> On Mar 15, 2012, at 11:52 AM, Noah Slater wrote:
>=20
>> Paul,
>>=20
>> How long before we can land COUCHDB-1426?
>>=20
>> On Thu, Mar 15, 2012 at 8:48 AM, Paul Davis <paul.joseph.davis@gmail.com>=
wrote:
>>>=20
>>> Nope. Though that was a bit silly of us.
>>=20
>>=20
>> Why?
>>=20
>> It was something of an experiment. And one that turned out quite well, I
>> think. I figured that if one person was enabled to drive each issue, and
>> had the say in what was done, etc, then we might see quicker progress on
>> them. There is a certain amount of pride that comes with having your name=

>> attached to something, and being deputised to make something happen.
>>=20
>> Out of four issues, we saw three of them get fixed very quickly. One of
>> them had looked almost insurmountable before this organisations. I
>> think Bob, Bob, and Jan, and everyone who helped then, did a fantastic jo=
b,
>> and I was proud to see the community come together in the way that it did=
.
>> We dropped the ball on COUCHDB-1426, but it's not a big deal. All I am
>> trying to do is be an annoying gadfly who won't shut up about it. And I
>> will continue to annoy and pester people until we can ship. Lighting fire=
s
>> under people's arses. If that costs me some browny points in the process,=

>> then so be it. We need to ship. We HAVE to ship.
>>=20
>> Why?
>>=20
>> Because we haven't made a major version release for almost a year. As a
>> project, we have slowed down a lot in recent years. Some of this is
>> completely fine. We're a database, after-all, and one that has a fetish f=
or
>> correctness. But on the other hand, there have been a number of times whe=
re
>> tickets are debated back and forth in JIRA, loose steam, and then languis=
h.
>> There is a fine line between being cautious, and allowing permission
>> culture to let tickets atrophy.
>>=20
>> I think we all know the misfortunes that have befallen the project
>> recently. We've had Ubuntu dropping CouchDB, we've had Damien dropping
>> CouchDB, we've had Couchbase confusing our users, we've had Mikeal public=
ly
>> deriding us, and more recently we've had NPM's security boo boo cast a
>> spotlight on us. Most of these things are not our fault. (The only one I
>> think that says anything about the project is Mikeal's posts, which I hav=
e
>> taken to heart a little bit.) But regardless, from the outside perspectiv=
e,
>> people have been looking in and asking themselves, is it all over for
>> CouchDB? This is, perhaps, the most important moment in CouchDB's history=
.
>> It's do or die, and getting 1.2.0 out is the first step on a long, and
>> hopefully enjoyable, path towards a better, stronger, project.
>>=20
>> How long before we can land COUCHDB-1426? :)
>>=20
>> I do understand your passion and I'm glad to have you as part of the
>>> community. My peevishness here is that we're being more reactive
>>> rather than proactive in our approach to addressing the issues at
>>> hand. For instance, what takes us so long to release? Mostly the fact
>>> that master/trunk/maintenance-branches are never in a consistent state
>>> ready for release.
>>=20
>>=20
>> Well, in this instance, I have been trying to release for two weeks, and
>> what is slowing me down is slow progress on release blockers. This is Thi=
s
>> has nothing to do with branch maintenance. COUCHDB-1426 is slowing us dow=
n.
>>=20
>> How long before we can land COUCHDB-1426? :P
>>=20
>> But maybe you meant in general. As an ongoing thing. I do not agree that
>> our problems are entirely technical in nature. I like that you're
>> approaching it from a technical angle, and I actually agree with everythi=
ng
>> you say from hereon in. But I am approaching from another angle myself.
>> Which is good, really. Because there are many things we could be doing to=

>> fix the project.
>>=20
>> So, after this release, there are three major community things that I wan=
t
>> to try out. I have been collecting my ideas on them, and the occasional b=
it
>> of private feedback for the best part of a month.
>>=20
>> The first the concept of teams. A team is like a bigger, more formal
>> version of what we did for the 1.2.0 blockers. The teams I have thought o=
f
>> so far are Community, JIRA, Wiki, Documentation, QA, Packaging, Core,
>> Mobile, Platform, and Release. The idea being that you don't have to be a=

>> committer to be on a team. Anyone could be on the JIRA
>> Team, triaging tickets. You, Paul, would almost certainly be on the QA,
>> Packaging, Release, and Development teams. Each team would have a lead, a=
nd
>> the lead would be responsible for driving and communicating progress.
>>=20
>> The second is the concept of a heartbeat. This would be a weekly and
>> monthly checklist of items, and activities, much like the release procedu=
re
>> or the test procedure. Think of it like a set of cron jobs for the projec=
t.
>> The PMC would be responsible for carrying out these tasks. The main purpo=
se
>> of the heartbeat will be to keep momentum, sort out any issues before the=
y
>> stagnate, provide steerage, and collect feedback from all of the team
>> leads, and to communicate progress to the community and the board.
>>=20
>> The third is a more well defined roadmap process. Now, more than ever,
>> CouchDB needs some product management. Which in my view, is about enablin=
g
>> and documenting a unified vision of the product, being a user advocate, a=
s
>> well as working with the release team to enable faster,
>> more iterative releases. Like a meta-release procedure. What do we want i=
n
>> our next major revision? What should we leave out? When should we aim for=
?
>> What should we do about our maintenance versions. That sort of stuff.
>>=20
>> These are the main ideas I have at the moment. I welcome the community's
>> feedback on them, though this thread, or this moment, is not the best tim=
e
>> for it. I only mention them now to illustrate that while you, Paul, might=

>> be thinking about the engineering challenges in front of you, I am thinki=
ng
>> about the community challenges in front of us. And I think that's just
>> smashing.
>>=20
>>=20
>>> If you really want to get super serious in showing
>>> the world the awesomeness then come join me in a stand for being a
>>> better software project (engineering wise. I personally think our
>>> community is best by lots).
>>>=20
>>=20
>> I won't comment on all of your points, because I agree with them. I have
>> actually made a note to myself to revisit your email after the release, s=
o
>> that we can start to talk about where these items fit in on the roadmap.
>> (See my above note about wanting an actual roadmap process.) Unfortunatel=
y,
>> a lot of the stuff I want to do only makes sense after the 1.2.0 release.=
 I
>> want to focus all my energy on getting this shipped, and I want everyone
>> else to do the same. Once this is out of the door, I think there are a lo=
t
>> of conversations that need to happen, and a lot of things that need to
>> change. But let's get this shipped. This is yet another reason why I feel=
 a
>> fire under my arse, and why I am trying to light fires under other people=
's
>> arses. We have SO much to do, but we need to ship this puppy first.
>>=20
>> How long before we can land COUCHDB-1426? :D
>>=20
>>=20
>>> 7. Fix our fucking website to not suck balls (yes, already in motion
>>> if we accept that a body in motion remains in motion until acted upon
>>> by an outside round house kick to the face).
>>>=20
>>=20
>> I have something up my sleeve here, but I'm not prepared to act on it unt=
il
>> we ship 1.2.0. My intention is to roll out the new version of the site
>> along with the 1.2.0 release announcement. Yet another reason why I have
>> such a sense of urgency. You have no idea how freaking awesome our new si=
te
>> looks. But I am waiting on 1.2.0 before I'm prepared to land it. (I am
>> purposefully not sharing it, because that will kill it, like it has kille=
d
>> every other re-design attempt. I am being bold, and I will ask for
>> forgiveness if I've made a mistake. But trust me it is awesome, and if yo=
u
>> completely hate it, you can veto and roll it back afterwards.)
>>=20
>> How long before we can land COUCHDB-1426? ^__^
>>=20
>> But above all else, lets be true to us. This project has prided itself
>>> on correctness above all else since I've been involved.
>>=20
>>=20
>> Agreed. But let's light some fires up some people's arses. I want us all t=
o
>> have the same sense of urgency.
>>=20
>>=20
>>> I can't resist the Zen of CouchDB:
>>>=20
>>> 1. Relax
>>> 2. Everyone is welcome
>>> 3. Your data is safe with us
>>> 4. Its simpler than you think
>>> 5. Fast is good
>>> 6. But safe and correct are best
>>> 7. Advanced uses should be supported
>>> 8. But not at the expense of core simplicity
>>> 9. Always respect existing standards
>>> 10. Unless those standards are absurd
>>>=20
>>=20
>> I like this. I may put it on the wiki later.
>>=20
>>=20
>>> So in closing, I know your fever, but chill, Winston. They know its us.
>>>=20
>>=20
>> I'll chill when 1.2.0 is shipped.
>>=20
>> How long before we can land COUCHDB-1426? ;)
>=20