"Ronald" wrote :
| Just like with a release cycle people can rely upon, the should be able to rely on
what will be in that release. In many projects I worked on, knowing 6 weeks before a
release that certain functionality that was scheduled to be in that release will not be in
it is not something I can work with.
Agreed. The release cycle was introduced exactly for this, to make releases more
predictable (as stated by Tom in the wiki) and thus to allow end-users to plan, too.
"Ronald" wrote :
| Looking at the past releases, each time issues were slipping to the next release, it
did not happen often that there was a plethora of time. So I'd like to propose two
| - Try to define (as good as possible, taking the above into account) plan at the
beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half
way as happened now) of 4.4
| - Take a little more time, so plan less 'issues'
Agreed. When you take a look at the great number of issues originally scheduled for a
release it's alsmost clear that not all of them can be taken into account. But the
decision which of them are needs to be made earlier (spoken from an enduser's point of
view). This would help a lot.
The second thing which comes to my mind are priorities. I think bug fixes and basic
features should have priority over completely new features. New features are great but
from my point of view they don't have a great value for real world use unless basic
process engine things were taken care of, especially a complete history and a fully
functional variable logging.
Just my 2 cents. Have a nice day. :)
View the original post :
Reply to the post :