| Re: [udig-devel] Re: issue list review for 10 min code sprint |
On Mar 8, 2009, at 6:19 PM, Jody Garnett wrote: To answer another one of your questions:
Yes, these all make sense to me, but are not what I am referring to.
I understand the JIRA and it's intended functionality. What i have been referring to is the human element/side of things. I have suggested that we create a human rule system that specifically handles tickets... both bugs and feature requests. Whilst also suggesting we get rid of the complex clutter. I suggest: 1. clean up the uDig JIRA entirely. 2. create a ticket filtering process wherein it is passed to a individual checker/tester, whom a. checks for duplicates b. checks category is correct, and description/explanation is correct/understandable c. tests the bug on OS X, Windows, and Linux, and provides additional description/explanation if needed. d. submits the ticket to the developer mailing list, and ask uDiggers for any/all feedback(experience, understanding, etc. of the bug). the purpose of this is to establish a dialog amongst everyone so that it is clear what the new ticket is addressing, and any and all ideas may be entertained during this disclosure/dialog. Or, we have this dialog amongst just a handful of us who are actively addressing the ticket(s). Either way, I think having conversation about any given ticket helps more then just one person understand the ticket, it affords a collective sum the common knowledge of the ticket, and if discussed on the list, then at a future date it is easier for more people to remember and recall. 3. once ticket is filtered by checker/tester(and discussed on the list), it is then ready for a programmer to address, or for other uDiggers to vote it's priority, follow it, etc. 4. if programmer works on the bug, and feels s/he has fixed it, programmer should make builds for Windows, OS X, and Linux. Thus, this is important... we need to make sure that all primary uDig programmers are able to make version builds, and this should be uniform across/for all programers who are building development versions. 5. then the build/version should go back to the checker/tester who filtered/cleared it in the first place, so s/he may test/check it once again, and verify if it has indeed been fixed or not, or if it has been fixed, but something else has been broken. Keeping the thread opened and going back and forth between checker/tester and programmer until ticket is resolved/closed/fixed/whatever. Eric
_______________________________________________ |