- Project tools
-
-
- Using ArgoUML
-
- The ArgoUML Project
-
- Nightly builds of docs
-
- The Stats Project
-
- How do I...
-
| Category |
Featured projects |
| scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
| issuetrack |
Scarab |
| requirements |
xmlbasedsrs |
| design |
ArgoUML |
| techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
| construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
| testing |
maxq,
aut
|
| deployment |
current |
| process |
ReadySET |
| libraries |
GEF,
Axion,
Style,
SSTree
|
| Over 500 more tools... |
|
9.3. Roles Of The Workers
The roles described below are per issue, i.e. for every issue, there
is at least a reporter and a resolver.
Hence, each person involved in issues for the ArgoUML project can -
at the same time - have different roles, and consequently, has
issues to report,
issues to close,
issues to resolve, and
issues to verify.
The Reporter is the person who enters the issue in Issuezilla.
Skills:
The reporter is an ArgoUML user, should not need any knowledge of what the
ArgoUML project is actually doing.
Responsibilities:
Report an issue
The address to enter new issues is:
http://argouml.tigris.org/issues/enter_bug.cgi
.
To enter new issues, you will need to sign up for a Tigris
account. For some operations in the issue database you
may also need to apply for Observer status to the ArgoUML project.
Answer clarification requests
Occasionally, the developers of ArgoUML need to request
the Reporter more information, to be able to solve the issue correctly.
Another way of putting it is to say that
if the issue was reported without some vital information
the Reporter has some more work to do.
Close the issue
This applies to an issue that is in the resolved or verified state.
At the end of processing the issue,
the reporter has the final word:
he can check the result,
and if he agrees with the solution,
close the issue himself.
Closing an issue requires at least "observer" role
in the ArgoUML project.
Reopen the issue
This applies to an issue that is in
the resolved,
verified, or
closed state.
The reporter has the final word:
he can check the result,
and when he does not agree that the solution is correct,
he can reopen the issue himself.
Reopening an issue requires at least "observer" role
in the ArgoUML project.
The Resolver is the software developer who attempts to resolve the issue.
Doing so requires at least "observer" role.
The "developer" role is only needed to commit things into the repository
(e.g. submit changed Java code, scripts or documentation).
Remark: Someone who does not have the developer role,
but solves the issue and convinces someone else to commit the solution,
is still the Resolver even though he cannot commit things into the repository.
The goal of the Resolver is to progress the issue to the status of
"Resolved".
The resolver may be the same person as the reporter.
Responsibilities:
Decide usefulness
(if this issue is really a bug or enhancement and if it is worth solving)
The Resolver has to decide if solving the issue is
really a useful improvement for ArgoUML.
The Reporter of the issue may very well be mistaken
in entering a bug-issue for what is in fact a feature,
or entering an enhancement-issue which is not really an enhancement.
Another thing that could be is a bug that appears in
very exceptional circumstances and that
may have large impact on ArgoUML architecture.
If the Resolver decides after the investigation that this bug
is really not that important or that he is not the right person
to solve it he enters his findings as a comment and
assigns the issue back to anyone (issues@argouml) and
moves along to work on another issue instead.
If applicable, program and test a solution
As this might take considerable time it might be a good idea
of the Resolver to assign the issue to himself to reserve the issue.
He can also signal progress by setting the issue to the state Started.
If applicable, write test cases
Set the issue in the end to "RESOLVED".
When the resolver is finished with the issue,
he puts it in "RESOLVED" status, and indicates the
"resolution" is FIXED, WORKSFORME, INVALID, WONTFIX, or DUPLICATE.
Skills:
The resolver needs to know a lot of the insides of the ArgoUML code, Java,
coding standards, and also the current status of the project with goals,
requirements and release plans.
The Verifier may be neither the Reporter, nor the Resolver of the issue.
The task of the Verifier is to check the quality of the solution by
confirming that the solution is complete, to the point, bug-free, etc.
This is an important part of the quality assurance work we do
in the ArgoUML project and the objective is to make sure that a resolved
issue is in fact resolved.
The test must be done on the "Target Milestone" version of the issue,
or any later version released to the public.
Responsibilities:
Check that the issue is solved in the stated version of ArgoUML
Verify the issue.
If the Verifier can conclude that the problem does not exist or
the feature/enhancement is now present.
Close the issue.
If someone else has already verified the issue then
the issue can be closed.
Reopen the issue if the solution is not fully correct
If the solution is not correct or the feature/enhancement does not work,
it is the duty of the Verifier to reopen the issue.
Skills:
The verifier needs only to focus on that issue, how the problem in it
is formulated.
He doesn't need to know how it is actually solved.
|
