lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Parkes" <>
Subject RE: jira workflow
Date Tue, 17 Oct 2006 21:06:27 GMT
The cases I'm thinking of are those issues, be they bug fixes or
critical functionality, that are submitted by non-contributors, people
that aren't going to do the coding themselves. I might be very
interested in some of those, probably the bugs in particular. I'm just
trying to figure out how I'll track those without them getting lost (in
the universe). Some I might decide to work on right away. Others I'll
want to circle back on later. It's remembering which I want to circle
back on that I'm thinking most about.

There's always a private watch list, but I'm thinking about the
community side. (Potentially) for patches, we have patch available.
Maybe voting is adequate for open issues. Hmmm ... wish I could easily
filter by issues I'd voted for, but that doesn't seem an option, at
least not from the web page.

	Put another way, who would be the consumer of the list of all
	issues that need clarification?

It wasn't really about having a list of needs clarification. It was more
about bounding open. I suppose it's my product development side showing.
Generally we tried not to leave issues open indefinitely, for fear of
not getting back to a customer. Perhaps there's nothing comparable in
the ASF model.

	A reviewer is someone whose opinion influences a committer.

Mostly thinking about Jira state issues. If Jira state can be affected
by more than committers (for example assigning to oneself, as a member
of lucene-developers), should reviewers still just provide comments on
other issues and leave it to a committer to bounce patches? Don't mean
to make too much of this; perhaps it's obvious what one should and
shouldn't do. Only trying to figure out how reviewers can contribute
without going too far.

	What next steps do you propose?

Well, if patch available is added, there's always the issue of moving
issues into that state but I suppose contributors, if they're still
around, will do that themselves.

Perhaps nothing needs doing ... except get a comfortable with a fair
number of opens and remembering to vote.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message