jME is getting to be fairly large, with a decent user base and more than just a couple developers. Therefore, I think we need to control how things are done a little bit more. This will document what is occuring in the system.
First of all, we must start using the Issue Tracker on https://jme.dev.java.net/servlets/ProjectIssues
I have already added the 0.10 feature/enhancement list. But the bugs will follow the same critieria. I will make a public post about folks making use of it for bug reports.
Here are the "rules" that we should follow (and please comment, I'm not setting this in stone).
1. Only work on tasks that are in the Issue Tracker - No code should be checked against items that are not in the Issue Tracker. This includes bug fixes, features, enhancements, anything. If there is something that you wish to work on that is NOT currently in the Issue Tracker, then add it. Wait for it to be approved by other devs (this goes for all of us), and then get started. If you have a minor (and I mean very minor) fix (comments, typos, etc), those may be checked in without referencing an Issue. Irrisor and Renanse I've put in the InputSystem and ThirdPersonHandler issues already, so just accept those tasks and mark them as
2. When committing make comments descriptive and reference the Issue Number - First line of commits should be: ISSUE: 173 or whatever issue number the commit is against. In the case of minor updates use ISSUE: MINOR. Again, try to keep those to a minimum. The comments should also be as descriptive as possible.
3. After committing against an Issue immediately update the issue - Add relevant comments to the Issue in the Issue Tracker. Update its status if necessary. These comments can be the same CVS comments if appropriate.
4. The Owner of the Issue CAN NOT close the Issue - This must be done by another developer who verifies that the Issue is closed. The Owner of the issue should just set to FIXED, and other developers should periodically check RESOLVED to test and close issues.
5. If questions were asked, corrections made, thoughts clarified on an Issue in forums, IM, etc update the Issue with the new information. - Keep the Issue up-to-date.
These shouldn't really make anything more difficult, but allow for tracability and tracking of problems.
Sounds good for me 
mojomonk said:
4. The Owner of the Issue CAN NOT close the Issue - This must be done by another developer who verifies that the Issue is closed.
Do you mean after committing the status should not be set to 'fixed'? What about setting it to fixed and other developers (or users) test it and set status back if they encounter problems? (reduces the amount of work done in normal workflow).
That's what he means. No setting issues you have done the work for to fixed.
What we can do is allow the developer to mark as fixed, but require someone else to change status to CLOSED.
The reason I wasn't too keen on doing this is when you mark as FIXED status changes to RESOLVED and the issue is not visible unless you remember to query on the RESOLVED status. I wanted a way to keep the issue on the front until someone else marked it as good.
I'm open to suggestions.
I don't see any reason we can't "mark" it fixed in our notes. We can always have a cleaning out every week or so of checking through the list and testing/closing out issues commented as fixed. It's not like we have 100's of such issues.
I would prefer to set to RESOLVED and the reviewer set it to CLOSED as you can query all RESOLVED issues then and test those, searching by comments takes much more time (or you had to remember it from the emails)…
(but just commenting is ok for me, too)
If you do a current search on resolved there is a lot to clean up from long long ago.
Well, I'll start cleaning up the RESOLVED, and then we can talk about it again (with all the old ones open, it takes away from the usefulness of the idea)
Ok, cleaned up. We'll give Irrisor's idea a shot. Basically, change to FIXED when you are done. We'll periodically query RESOLVED and verify and set to CLOSED when appropriate. Then we will NOT put out a new release until every FIXED to moved to CLOSED (with proper verification).
Most of the "fixed" issues seem really done to me - should I close those that do not belong to me with a short comment? Or what should the procedure for closing be like?
Yes, feel free to close any FIXED issues that you feel are verified.
That committing only with an Issue was somewhat abandoned, right?
I guess they have a different policy at NCSoft 
Yeah, I've kind of blown that… it should still be kept up. I'll start doing a better job of it, sorry.