[Zope3-dev] Roadmap for Zope 3.4

[Lennart Regebro]

On 9/12/06, Jim Fulton <jim at zope.com> wrote:
> FWIW, I use the following approach:
>
> - Early in the process, I mark every real reproducable bug as blocking.
>    In this last go around, this included a number of bugs that had been
>    around for months or years.
>
> - Later in the process I downgraded lots of bugs because I didn't
> want to    block the release.

Ah. Well, that procedure definitely can get improved on. :)
I think it is imperative that we mark bugs according to the
seriousness so that you know which bug should be worked on first.

I note that the Zope3 collector has the categories medium, low,
critical, 3.3 release and 3.4 alpha 1. I don't think that's a good
idea, but I understand that the Zope collector has no field for
planned release, and those options make sense for features. :-)

Anyway, for me it's like this:

A blocking/critical bug is a bug that means the system or part of the
system gets unusable. It has no workarounds, and affects most users of
the system. Say, PUT_factory suddenly stops working, meaning that FTP
and WebDAV no longer works.

A serious/medium bug is a bug that is a big problem for many users and
has no workaround, or affects everybody, but has a workaround. For
example, that XML import/export didn't work: Workaround, use the non
XML-import/export.

A minor bug is a bug that affects few users and has a workaround, or
has no workaround but only is a problem in very extreme edge
usercases. For example...euhm, ehhh, I can't think of one right now.

(and a trivial bug is not an actual problem for anybody. Could be
spelling errors or ugly design.)

A bug should be assigned a category and stay there. It should not get
it's category changed so not block a release, because if you can do
that, well, then it wasn't blocking in the first case.