couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Focus
Date Fri, 09 Nov 2012 15:18:55 GMT
I'm fine with punting this, but I do want to express my concern about
getting this written down. We've never had a roadmap, of any sort. And I
think we need one. Documenting our current focus, and possible future
focuses seems like a good step in that direction. If we don't want to
document this right now, I will come back to this post-1.3.

On 8 November 2012 14:13, Jan Lehnardt <jan@apache.org> wrote:

>
> On Nov 6, 2012, at 17:03 , Noah Slater <nslater@apache.org> wrote:
>
> > I think this is a great initiative Jan.
> >
> > I am sure there are a few people right now who are thinking "Hey, but I
> am
> > working on X, and Jan didn't mention X, so is X important? Or is Jan
> > telling me I shouldn't be working on X?" Well, I understand that. As it
> > happens, I am working on the docs, and Jan didn't mention them.
> >
> > But I don't think the idea is that anything not on the list is
> unimportant,
> > or that if you're working on something else, then you should stop. Just
> > that we need to have a regularly updated list of our current PROJECT
> LEVEL
> > focus.
> >
> > And so, with that caveat out of the way...
> >
> > Jan, as this is your initiative, can I ask you to start a page on the
> wiki?
> > We should document this.
> >
> > I think the wiki page should probably have three things on it. A list of
> > our current focus areas. An archived list of previous focus areas. And a
> > list of areas to focus on in the future.
> >
> > I think we should also review this monthly. Each month, review the
> current
> > focus areas, see what has been done and what has not. Archive the list.
> > Create a new one for the current month. And decide on whether we want to
> > add any other items. This should be a dev-level decision making process,
> > perhaps in the first IRC meeting of the month.
> >
> > A monthly email to both user and dev, along with general project status,
> > might be a good thing to come out of this too.
> >
> > Thoughts?
>
>
> My intention with this thread is to try to create a “culture of ship”.
> (I’ll be sending out t-shirts, when we succeed). I don’t think making
> this a more formal thing isn’t going to do much.
>
> I think the weekly status meetings are great way to formally keep
> track of the progress we make through our collective roadmap (which
> we also need to work on a little bit more structured, but one thing
> at a time.
>
> Let’s ship 1.3.0.
>
> Jan
> --
>
>
> >
> >
> > On 6 November 2012 15:47, Jan Lehnardt <jan@apache.org> wrote:
> >
> >> Hey all,
> >>
> >> I’m trying something new here. Please send any feedback you might have.
> >>
> >> DISCLAIMER: I won’t keep anyone working on or discussing anything. All I
> >> want is find a way to make us all more productive.
> >>
> >> * * *
> >>
> >>
> >> With that out of the way:
> >>
> >>
> >> Let’s Focus!
> >>
> >>
> >> My hypothesis is this:
> >>
> >>  This group, dev@, has a limited amount of time and attention to move
> >> CouchDB forward. We have so many important things to do that it is very
> >> hard for us to say “no” to any one thing that is brought up.
> Historically,
> >> whenever there is a surge of activity, we (myself definitely included)
> tend
> >> to bring up more issues than we can work on at a time and as a result we
> >> end up doing less than we could.
> >>
> >>
> >> My proposal to solve this:
> >>
> >> Say “no”.
> >>
> >> More specifically, we need to learn to say “no” to things that, while
> they
> >> are definitely important, are not important enough “right now” and
> should
> >> be deferred to a later time.
> >>
> >> For example, currently I think our most important topics are:
> >>
> >> - Get CORS and docs into shape that we can merge them to master/1.3.x
> >> - Ship 1.3.0
> >> - Help the Futon.Next folks out as much as we can to build & deliver
> >> Futon.Next.
> >>
> >> At the same time, there are many more discussions going on that are
> >> distracting us from the points above done.
> >> (This includes my Plugins Proposal, I am clearly guilty of this.)
> >>
> >> Note that the list above is a strong “in my opinion”, your shortlist is
> >> likely to differ and that’s great. We as a group need to figure out
> >> together what the things are that we care about *and* that we can care
> >> about at any one time.
> >>
> >> This includes things we discuss on dev@, in the weekly meetings,
> patches
> >> we request reviews & comments on.
> >>
> >> I strongly believe that when we can agree on a short list of things we
> >> care about, and get them done, and *then* move on to the next few
> things,
> >> we’ll get more accomplished than we do right now.
> >>
> >> * * *
> >>
> >> It would be illusionary to imagine a fully sequential workflow, so I
> won’t
> >> pretend we should try to achieve that, we’ll always have things going
> on at
> >> the same time, some by different group members, some by the same
> people. I
> >> also don’t suggest to add a layer of classical project management. Some
> >> discussions are broader (BigCouch merge, source reorg) and need more
> time,
> >> others should be resolved quickly. And to reiterate the disclaimer, I
> won’t
> >> keep anyone from working on or discussing anything at any time.
> >>
> >> All I suggest is that we, as a group, are a little more mindful about
> the
> >> things we can handle at any one point. This will change depending on how
> >> much time each of us can spend in a given week or month. I hope over
> time
> >> the list of things we can do at a time grows, as we add more members to
> the
> >> dev team (hello Futon.Next folks! :)
> >>
> >> * * *
> >>
> >> In practical terms, I’ll be asking the questions “is this relevant right
> >> now?” and “should this be on our short list of things to care about?”
a
> lot
> >> more often, and I hope, given you agree with the broad strokes above,
> can
> >> do the same.
> >>
> >> Thanks for your time and attention!
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > NS
>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message