- 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, and
issues to resolve.
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.
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.
|
