Hi Linus,
I suppose when I see 1000s of issues to be verified, I mentally calculate
20mins per issue * 1000, which is equivalent to approx 2 months of a full
time job. Anyone can get a lot done in 2 months.
My suggestions are:
1) Update the cookbook to say that issues can be optionally verified and
closed after being resolved, but that this is not a requirement.
2) Remove the texts (cookbook/website) which encourage new developers to
verify issues.
3) Send an automatic message out to every resolved issue when we do a major
stable release, stating something like "This issue has been marked as
resolved in time for release X. If nobody objects by reopenning this issue,
is will be automatically closed [in 2 days' time / in 2 months' time /
shortly before the next stable release]."
4) Close resolved issues that have not been re-openned after the period
stated in 3).
Regards,
Dave
Linus Tolke wrote:
Hello Dave!
There were two reasons for setting up the process as it is. The first
one is that the Tigris infrastructure doesn't allow us to remove the
states in the lifecycle. The second one is that I had the idea that
verifying issues would be a good way for non-java persons and persons
that are new to the project to understand how we work with issues.
The first reason is still valid. It won't be possible after the Tigris
upgrade either.
The second reason, I must admit that the idea never really caught on.
On the other hand, I don't think that changing this would immediately
increase the amount of useful work considerably since there isn't that
much work that goes into verifying issues.
What is the concrete suggestion? What of the following should we do?
* Remove the process of verifying and closing issues to make
RESOLVED, VERIFIED, and CLOSED equivalent.
* Stop mentioning the option of verifying issues when joining the
project.
* Close all issues currently RESOLVED or VERIFIED and the close them
regularly, probably connected to the release work. Something like
a couple of days after a stable release or something simpler.
/Linus
2008/9/11 Dave Thompson <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
On Wed, 10 Sep 2008 23:21:31 +0100, "Luis Sergio Oliveira"
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> said:
> Currently, when an issue is resolved, you have the developer's
opinion
> it is fixed. It is already good, but, why not allow it to be verified
> afterwards and have a supporting issue life cycle that is capable of
> registering that?
The reason is to reduce non-useful work, allowing that time to be spent
on other things.
If verifying an issue is something that is optional (it sounds like it
is), then we should have that as a policy clearly stated in the
cookbook. In my opinion, verifying issues should be a lower priority
than most of our P5 defects. If a person feels strongly about an issue
he reported (or cc'd himself on), he will check it when it is marked as
resolved. If no-one feels strongly about an issue any longer (e.g.
original reporter left the scene and no-one else was cc'd), then what is
the problem with accepting the developer's opinion that it was fixed?
There is a difference between an idealistic workflow and a realistic
one. The problem is that idealistic workflows often depend on ideal
amounts of resource, and are often unnecessarily complex.
Regards,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
