On Nov 10, 2012, at 08:30 , Benoit Chesneau <[email protected]> wrote:
> On Fri, Nov 9, 2012 at 4:34 PM, Jan Lehnardt <[email protected]> wrote: >> I consider making a roadmap orthogonal to the idea of Focus. >> >> We absolutely must communicate our roadmap clearly. >> >> Then we can pick the top few things to focus on when we're done with the >> previous set of things >> > > > While focus is a good thing I do consider it shouldn't stop us to have > normal activities during a release process. While a release is > important in term of distribution not all of us are based on it or > want to wait the end of it to work on next features. Some of us manage > their time differently. Some of us depending of their schedule and > will, can dedicace more time to couchdb than others. > > Having a roadmap would help them to know if what they are working on > is part of the big plan or not. It also helps them if they need > directions for the feature they are thinking of since it can be > impacted by the big plan or have impact on it. > > And speaking of it, focus shouldn't make us ignore or schedule > questions not related to a release for later. Thing is that life > continue during a release process and some still want to continue to > improve their applications while contributing to upstream (ie the > couchdb project) . And some are able to do both, working on the > release and next feature anyway. It's important to answer to questions > as fast as we can. Even more important than releasing. Releasing is a > matter of taking a snapshot of our current code at some point, so it > shouldn't ask us more than "are we ready to release ?". Some who are > working on blocking issue then will work on them and maybe on the next > feature too. Because they can. I agree with all of the above. For me, personally, it is just a question of where I spend the amount of time I have. Currently, I have two options: 1. Look at the otp branch, discuss modularisation, do more armchair architecting, which is definitely fun. 2. Review & comment on the CORS patch, help out with commenting the code, which is currently a blocking item. All of which is slightly more tedious, but gets us closer to shipping 1.3. I choose 2. Once 2. is out of my head, I am happy to think about 1. If I try to do both, I won’t do either very well. And while the above observation is about me, I think it safely applies to the rest of dev@. History has shown that we all work better if we can focus on a few things and knock them out of the park instead of keeping any important discussion in the air and then get frustrated because there is no progress and start yet another side thing and perpetualy move towards total inactivity. And, just to make sure this doesn’t get lost from the original mail, we *always* will have multiple things going on, this is *not* to impose any artificial linearity on the project. The whole goal here is to get more things out faster. We can only do this if we are mindful about our collective time & attention. Back to CORS, for me. Cheers Jan --
