Updating Mantis status

HI Ken,

Thanks for your prompt response.


***
>Ken Causey ken at kencausey.com 
>Fri Feb 8 02:32:43 UTC 2008 
>
>
>
>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.
>
Ummh. It takes a community longer to learn than an
individual. And it takes some motivation.
I have been using mantis to report 200+ issues and I
comment on those others have posted.

I started with some knowledge and gained bits and
pieces with use.

Few others have used it as much, so it is not
surprising that they have not learned the extent of
mantis's abilities.

The motivation is that if we want an improved base
squeak we need someway to communicate 
1) what is not working,
2) find clues and analyze why it doesn't work,
3) propose fixes,
4) convince others those fixes are correct and
5) will integrate well into squeaks present code base
and future direction.
6) finally that those fixes have been noticed
7) incorperated into a particular release or squeak

8) Once all that is done the issue stays around as
part of the collective history and documentation
and stands ready to provide clues for solutions to
future problems.

The also stands as a description of the work flow.
With the reporter responsible for 1, and optionally 2,
3(in the form of code) and 4,5 (in the form of tests).
When the work gets to 6,7 that must be either a
package steward or a release team member or both.

Between 7 and 8 I have left out the steps that happen
when feedback comes from the test pilots of a release.
The fact is many fixes that get in don't work once
they are in the system. There can be unforseen
integration problems or the fix may not actually work
as advertised. This is especially true because the
stewards or release team may favor a fix even when
tests have not been provided. And because squeak has a
great maintenence debt in the form of a lack of test
coverage for code that already exists. I track bugs.
My job is like shooting fish in a barrel.



>> 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.

 Sorry, I've given this a lot of thought which didn't
fit into the post. This has to do with work flow.
When a stewart or release team harvests a fix then do
they have the responsibility for updating the mantis
reports status to resolved or closed from open or
assigned?
>
>>   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.

Yes. But we haven't had a scheme for dealing with
releases that has lasted long enough for the
terminology to stick.
>
>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.   

The way we do it now, yes. But we could add statuses
that indicate the issue has a fix attached.
And another that it has tests to prove the fix is
necessary and sufficient; has been reviewed by at
least a second person. And has nothing more to do
except wait to be "harvested" into an current image.

It would be nice to have another
>step in the process before that, but there do not
seem to be enough
>eyeballs available.

Partial progress counts. If we make this process as
good as we can there is always the change it would hit
the tipping point.

>In the end the release team has to answer this for
>themselves.

Yes. and it shouldn't be to hard to reach guidelines
that let them know what they are expected and counted
on to do to keep the communications clear. We also owe
it to them to make there job as easy as possible
because we must count on them for a great deal.
>
>>   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?
You have given people either reporter status or
developer status. Mantis provides for a status
inbetween that called updaters. People who have some
abilities to update issues but not as much as
developers.

Since we have no updaters who are not also developers,
updater is just a role for someone with updater
abilities or better.


>
>>   What is expected of developers?
>
>Again who?
I am using the mantis terms for different priveledges
with regard to the system
observer, reporter, updater, developer, administrator
(and I may have missed one.)

>
>> 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.
>
See now you are answering my earlier question about
their roles.

>> 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.
>
I am just about to the point where I can make some. I
didn't want to suggest answers at the same time as I
asked questions. 


>> 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.
>
Yes. My question was more on the order of, having this
ability what is the best way to use it consistently?
Mantis will also allow us to name are own
relationships between reports beyond what they supply.
I can think of a few that might be useful.
>> 
>> 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?

That's a good question.  What do others think?
>
>> 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.
>

Yeah, me too.

Yours in curiosity and service, --Jerome Peace

>
***



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs