On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
wrote:
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
That's good to know. But can you estimate _when_ it will be
implemented or with which version? That would be very
informative.
Things generally just don't work that way around here. They get
done when they
get done. And often some of the more important stuff takes a
while, because it
takes a while to get the design sorted out and implemented
(especially if
Walter is the one to implement it). So, much as it might be
nice to have a
roadmap saying when something is expected to be done, that
pretty much never
happens.
- Jonathan M Davis
I would suggest that it should work this way, and that maybe this
should be part of the new process focus.
This isn't intended to be demanding -- it could be fairly simple
to provide SOME guide to timeframes. For example, with redmine,
you can attach issues to milestones/releases, and give an
estimate of time involved. Redmine will then project time to
finish that milestone, drawing a nice chart of issues closed vs.
open vs. total time. If that milestone is three releases away,
not being actively worked on, and you have two milestones
between, with time estimates for each, then users can STILL see a
reasonable timeframe for things, even if it's still updating.
