[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Issue tracker proceedure and protocol ideas for distributed workload
|
On Mar 8, 2009, at 8:12 PM, Jody Garnett wrote:
Hi Eric - since you started your idea as a reply to a thread on
getting organized for this weekends code sprint we are getting
people a little confused. The question I was answering was about the
existing workings of Jira. Silvia was asking how to help; and if a
priority had been set fo issues needing testing.
oops.
I do not feel I effectively answered her question; there are a lot
of issues that need testing; and we will not be able to take stock
of the answer until we have completed reviewing all the issues.
Eric Jarvies wrote:
Yes, these all make sense to me, but are not what I am referring to.
Understood; I was answering Silvia's question - we can return to
your email thread about organizing our issue workflow if you like
(but right now the two email threads are getting confused; and
making organization for this weekend difficult).
I also note that this page is really good and describes a few new
issue states that may be of interest to Eric:
- http://jira.codehaus.org/secure/ShowConstantsHelp.jspa
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.
Understood my general feedback still stands:
- we can document our rule system in Jira (so the tool will help us
once we know what we want). I have two examples where projects have
added a workflow with additional steps similar to what you described.
- testing on multiple platforms may be beyond our abilities except
on a case by case basis - the open source "relesae early release
often" may have to act as a substitute for lack of dedicated testers.
- the difference between fixing a bug and fixing a bug and making a
build is around 1/2 day (and a lot of waiting for files to upload)
while all developers (and indeed anyone) can make a release
following the procedure in our wiki I am not sure this is an
effective way to roll out a single change. I would rather make a
uDig release every month (or every two weeks) than expect this of
our developer community
If we had a working development version, wherein each time a bug is
addressed, the app is built, would provide uDig with a clear point of
filtration. The idea is to be current on current events, in a
collaborative fashion.
What I am missing here is not your individual suggestions; but what
you are wanting to accomplish with them (right now the amount of
work you document would preclude me from working on uDig). So I feel
I am missing something ...
Sorry. I've been trying to put my finger on it, really :) I just
want to be able to 'help' in a way that does not require concurrent
dependancy on you, or others, but rather in a concurrent manner, like
a 'hot potato' being passed around in such a way that when time and
energy permits for each of us, we can dedicate ourselves accordingly.
When the hot potato has been throw by you, you know you do need need
to mess with it until it happens to be thrown back at you. So, if you
have time to fix one/somemany bugs, and you create a build, and toss
it back at me/us, then you need not pay attention to it until such a
time I have spent time checking/testing it, and putting it through
it's rounds, either finding additional fault, and passing it back to
you, or finding resolve, and proceeding to administrate the closing of
the ticket, not having to involve you in the process.
For example;
JIRA > uDig > tools and editing:
UDIG-186: zoom speeds should be set as a preference
UDIG-255: Info Area Tool Requested
UDIG-332: Magnifying Glass Tool
(add many more here).
Let's assume Jesse Eichar just filed the 'zoom speeds should be set as
a preference' ticket. instead of you, or other active programmers
spending your valuable time with this ticket at this point, it should
be handed off to someone like myself, who would first make sense of
the ticket. I read this ticket as having adjustable settings under
File > Preferences > . I would contact Jesse and clarify if what I
interpreted is what he was referring to(or not). Upon clarification I
would then create any visuals(if needed), and add any descriptions or
instructions(if needed), and then I would pass it to each of the uDig
active programmers, explaining to each/all what the ticket(in this
case, a feature request) is asking, and would ask the uDig programmers
to confirm their understanding of such, and to provide me with
feedback as it relates to time involved, if there are conditions or
contingencies based on other features/functions, and so on.
So the above ticket becomes: 'New Preference Menu called Zoom
Settings' and it should look like this:
