Re: Features, releases and team work

On 3/28/07, Karl Fogel <kfogel@red-bean.com> wrote:
>
> "Mark Phippard" <markphip@gmail.com> writes:
> > Short answer ... absolutely.
> >
> > Longer answer, and I tried to say this in the original reply, was that
> > we could decide we were going to define roadmap releases based on time
> > frame, as opposed to features, and we would then have to define what
> > would go in each release based on the timeframe. So maybe it would be
> > smaller features like SASL support, WC improvements, maybe it would be
> > part of a larger feature such as the repository backend support for
> > true renames.
> >
> > The second part of this answer, is that I think we always have the
> > option as a community to change our mind. Suppose we had agreed merge
> > tracking was one of the defining features for 1.5 on this hypothetical
> > roadmap, and we had slated that release for 1Q 2007. As we got closer
> > to the release time Daniel could have said "sorry guys, but I do not
> > think this can be ready until late 2Q." We could then decide to push
> > merge tracking to the next release, or try to provide more effort so
> > that it was ready for early 2Q. Having agreed to our goals ahead of
> > time, the conversation that needs to happen would just be easier to
> > have because we could eliminate the discussion of whether we agreed to
> > this in the first place.
> >
> > I do have some concerns about basing the roadmap on timeframes. I
> > think that sort of concept only works well if the timeframes are short
> > (6 months max). The problem we might have with that approach is
> > having too many releases. Do our downstream users want them that
> > frequently? I think the client tools and packagers might have the
> > toughest time with this, although I am sure both would benefit from
> > the predictability. I think with a "major" release every 6 months,
> > and then assuming there are also fix releases happening in between,
> > that is a lot of releases to be producing and a lot of work related to
> > that. I am not against doing it this way, I just think if we are
> > going to make time the main factor, then the time ought to be
> > relatively short. It would really suck if a major feature like true
> > renames missed a release by a month and then had to be held for
> > another 8 months before we do another release.
> >
> > I actually think the first thing we should do is start compiling the
> > roadmap wishlist of what features we want to provide. That might help
> > us decide what we actually want to do in terms of scheduling. I have
> > to say that this has felt like "rename" week for me. I have seen the
> > issue come up several times on the lists as well as internally from
> > CollabNet customers. I have always thought this was a major hole in
> > the product because the only workaround that works is to not do
> > renames. I'd like to see that developers are interested in making
> > this a priority item on the post 1.5 roadmap. I know it is a big
> > task.
>
> I guess I can see people rallying around a particular feature, but not
> around a roadmap. (Or, they might rally around the roadmap, but that
> won't have much effect in the long run.)
>
> When I said I could see myself reorganizing my personal priorities to
> be in line with a team effort, I meant more around a particular
> release or feature. I'm not sure a roadmap would make things better
> faster; there are advantages to the controlled chaos we've got going
> on here, after all.

FWIW, I would only view the roadmap as being "solid" for the release
currently being developed. The rest would evolve. Maybe the roadmap calls
for true renames phase 1 in 1.6 and phase 2 in 1.7, but other than
that, 1.7might not have much else committed to it at this point. This
was my point
about not putting things on the roadmap unless someone has taken some effort
to show commitment. It does not do any good to put true renames on the
roadmap, as an example, if the feature does not have some kind of basic
proposed design and also some people that say they want to work on it. I
would say features in this state belong on some kind of feature wishlist.
Maybe new developers coming to the project can take that list and do the
steps needed to get a feature committed to the roadmap.

I am sure there are some people that use Subversion that would love to see
some detailed long term roadmap covering several releases, but that is not
what I was proposing. I just meant we should have a process for defining
what is going to be in our next release and what the time goal should be.
Part of that process would naturally also involve doing the ground work for
future releases, as we get closer to the cycle for those releases, the plan
would become more defined.

Finally, a lot has been talked about devs scratching their itches. There is
nothing wrong with that and a lot of great features come out of it. This
does not stop that. We can always include more features/fixes in a release
than was planned. I think that having goals has the possibility to help
create "itches". For example, people want to get a 1.5 release out the
door. Suddenly merge tracking and sparse-directories are getting broader
attention and this has been helpful. If it has been clear to everyone that
we were not going to ship 1.5 until those features were done, then maybe
this attention would have started a couple of months ago instead of now and
we would be that much closer to a release. I do not know that this "effect"
will happen, but I do not think it is crazy to think it might.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/