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