On Thu, 2008-02-07 at 17:39 -0800, Jerome Peace wrote:
> Part of the problem is that mantis is a new tool for
> most of the sqeuak community.
> We are still learning how to use it effectively.

Which, while perhaps true, is really rather sad since it has been in use
now for over 3 years.

> Managing it well will take several steps and a few
> more iterations.
> 
> What would help:
> 
> 1) clearly STATED roles and expectations.
>   What updating of status is the responsibility of the
> harvesters?

Huh?  I'm afraid I can't parse that.

>   What status should a report be in before a harvester
> looks at it?

I'm going to assume for the moment that by 'harvesters' you mean the
release team, as that terminology has been largely dropped for regular
usage.

I'm afraid that in practice the harvesters can't assume anything about
status.  If someone creates a new report and even attaches a fix, it may
well be the case that this issue is ready for 'harvesting' even though
no one else has looked at the issue.   It would be nice to have another
step in the process before that, but there do not seem to be enough
eyeballs available.  In the end the release team has to answer this for
themselves.

>   What is expected of reporters?

To just fill out the report form as best they can.  The details of that
can be found in the project documentation at

http://bugs.squeak.org/proj_doc_page.php

(Unfortunately at least in some browsers you may be expected to start
another application to view what is in fact an HTML page.  Of course you
can do that or even simply save it and open it as a local file.  I guess
this is next on my todo list after having completed passphrase resetting
support on Squeak People.)

>   What is expected of updaters?

Who?

>   What is expected of developers?

Again who?

> When should an issue be marked resolved?

If it is decided that the issue is not to be fixed for whatever reason
then immediately.  Otherwise assuming a fix is supplied then the release
team should mark the issue resolved once the fix is placed within the
current version of the update stream and they should annotate the report
with some sort of identifier for the fix as it appears in the update
stream, currently the update stream number would be sufficient.

> When should it be marked closed?

If the issue has been marked as resolved because there is to be no fix
and the release team either made that decision themselves or are
satisfied with that decision then they can go ahead and close the issue.
If a fix has been supplied and is accepted then when the release team
issues an image that includes the fix or possibly after the entire
alpha/beta/gamma process for a version where that version contains the
fix.  Either would be fine by me.

> 2)Mantis allows customizing the names and number of
> statuses. Our workflow and the way we use the current
> ones probably requires a few more.
> Who can we give the role of deciding and implementing
> those additions. (Hi Ken :-)

This has been discussed before and I've already said that I'm more or
less happy with them but that I would welcome suggestions.  I don't
remember ever receiving any.

> 3) How do we group issues together so that someone
> fixing one can be aware of the others it might impact?

Each Mantis report can have a relationship to one or more other issues,
this is on the report page in a section entitled Relationships just
under the main details section and above the upload section and
comments.

> 
> I started doing what I thought should be done. Matthew
> Fulmer caught on and ran with it.
> 
> The thing is we can get a lot more work out of mantis
> if give a little thought as to how it can assist our
> work flow. We have right now accepted the defaults as
> our limitations. This is not ideal.
> 
> 4) Where do we discuss issues of how to use mantis
> better?

Is there something wrong with this mailing list?

> 5) OPLC Etoys has an etoys-notify list where their bug
> tracker can send email about bug issues.
> (auto-mail is much to boring for a converstational
> list like squeak-dev) 
> Would it would be useful to have such a list?
> Would their be folks who would follow it?

I'll have to leave these to others to answer.

> 
> Yours in curiosity and service, --Jeorme Peace

Ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080207/5b9511ab/attachment.pgp