- 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.4. How to resolve an Issue
This can be performed by any member of the project (any role).
Persons without the Developer role need a person
with the Developer role to actually commit the work if the resolution
involves changing some artifact.
There might be special skills involved but it differs widely depending
on the nature of the Issue.
Do the following:
Pick any Issue that is NEW or REOPENED
that you from the description think that you are able to solve.
Best results are often obtained if you find an Issue that you really feel
needs to be solved.
The list of all of them.
Look at your personal schedule and how much time you have during the
next couple of weeks and compare that to the amount of time you think
you will need to spend for solving the issue.
Compare this to the release plan to see what release your contribution
will fit in.
Accept the Issue and reserve it by assigning it to yourself.
Set the Target Milestone to the release you have chosen.
Make sure you have a checked out copy of ArgoUML or else check out
a new one.
How this is done is described in
Chapter 2, Building from source.
Mark the issue as Started (this could be done while assigning also).
Change the code to solve the problem.
Compile and test your new code.
This should include developing a JUnit test case to
verify that the problem is solved.
You could also develop the JUnit test case before actually solving
the problem.
If your solution did not work as intended, continue changing it
until it does.
If you feel that your estimation of the complexity of the problem
and your own abilities and time available was incorrect,
then change the Target Milestone of the Issue to another one
that fits your new estimation.
This is just a change of plan.
If you, at this point, feel that your personal plans have changed
so that you won't have time to pursue the work,
change the Issue back to "NEW" with your experiences so far
stated in the comment.
This means that you are giving up and giving the Issue back to
anyone.
You should also assign it back to issues@argouml or if you know
someone else in the ArgoUML team that will continue the work,
assign it to him.
Remember not to commit your changes in the main branch but please
commit your changes (if any) into a work branch and state the name
of the branch in the issue.
That will make it possible for someone to make use of your work so far.
Commit your changes and the JUnit test cases stating
the number of the Issue in the comment.
If you don't have a developer role in the project,
this involves sending your changes to someone who has
and then convincing him to commit them for you.
"Resolve" the Issue with the resolution "FIXED".
Also set the target milestone of the upcoming release
that will include the fix.
Sit back and feel the personal satisfaction of having completed
something that will be part of the ArgoUML product.
If you during this, have discovered other problems,
create new Issues stating those new problems
according to the rule for creating Issues.
|