Nicola Ken Barozzi wrote:
> Noel J. Bergman wrote:
> > To a certain extent, the incubator is evolving, too. If evolving
procedures
> > that are not being disseminated, that's one problem.
>
> > I propose that a good way to address this situation will be to make
active
> > use of the new JIRA install, Serge and I have scheduled for next
Thursday.
> IMO it will just obfuscate tasks more. What we need is more simplicity,
> not complexity. IMO just keeping STATUS files in the Incubator is simple
> enough.
I had thought of that, and ended up removing the paragraph discussing the
STATUS file because of the differences. I am not trying to complicate the
process. I am proposing what I believe is at least as easy a process, and
which better facilitates active oversight through a more appropriate tool.
The STATUS file is passive. Jira is active. The STATUS file requires the
submitter to have CVS commit access to that module, and CVS knowledge. Jira
has its own access control, and a built-in UI. The STATUS file requires
human parsing to understand the priorities. Jira has a prioritization
model. Updating the STATUS file requires a checkout/update, edit, commit.
Jira would be simply filing an issue via the webapp.
There was a study long ago related to auto-pilots. The initial idea was
that the computer would fly the plane, and the human would monitor its
actions. Turns out that we are particularly poor at monitoring something
that is usually fine; we get bored, and inattentive. It works much better
when the computer is monitoring us, rather than the other way around.
Hence, the active nature of the issue tracker seems a key. It is like the
question of "If a tree falls in a forest, and no one is there to hear, does
it make a sound?" ** If an issue is added to STATUS, and action is not
immediate, will anyone remember? Will the change even be noticed? The
STATUS files are in a common module; to which list are the commit notices
posted? Lastly, I don't think that an inbox makes a good issue tracker.
With high e-mail volumes, if a message isn't acted upon and deleted, once it
scrolls off the screen, there is a tendency for it to be out of sight, out
of mind until the person has time to address the backlog. The issue
tracker, on the other hand, will continue to remind until the task is marked
as completed.
These all contribute to why I suggest that issue tracking is better done
with an issue tracker. So although I had not mentioned the STATUS file in
this context, I had given it thought. I'm interested in your response, and
those of others, to this assessment.
As for the titular topic, I have no problem with the two modules merging.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
