Steven Parkes wrote:
My main concern is that things get lost in lists that grow without bound.
I've never been to concerned about the size of the open bug list. It can be searched, if one wishes to find whether there's already an issue before filing a new one. The lists I try to keep small are those that are assigned to a contributor and those that are scheduled for a release. The list of open issues forms the universe of possible directions the project might take, and hence reasonably might be quite large. Assigned and scheduled issues are the direction it's taking right now.
That leaves, among other things, concrete bugs, irreproducible bugs, feature requests, and this blue-sky-y kinda stuff w/ or w/o patches. The Issue Type might handle some of this. Do we want to classify the half-baked stuff as a feature request? (And is the reporting good enough to make it easy to ignore those and focus on the hopefully bounded steps.) Or maybe add an issue type for blue sky / only half baked things?
Sure, feature requests probably account for most of such things. But there could also be bugs that won't be fixed for years. These should remain open, gathering comments. For example, one might reasonably complain that document deletion should not be permitted on an IndexReader that's being used for search, since the general contract of an IndexReader is that it presents an unchanging view of an index. In practice, this is not a big problem, but it is arguably a bug. I'd be hesitant to resolve it as "Won't Fix", but neither am I going to rush to fix it. So it could remain open until someone both felt it was important to fix and has a palatable solution.
I was thinking about Chris's comments on clarity. I'm still thinking of that big "open" bucket. What about a "needs clarification" status? A reviewer could bounce "open" back to "needs clarification" analogously to "patch available" and "open". There's an "incomplete" resolution state but that means (I think) the issue is closed which you'd only want to do after the reporter had a chance to clarify. Would that succeed in keeping "open" to a reasonable size?
A comment from a committer or contributor should be sufficient to explain why something has not been committed, fixed or whatever, and what action might next be needed. The scarcest resource is committers. So we want to be able to focus their activities. "Patch Available" is a call to action. If something "needs clarification", then the reporter of the issue should be able to determine that from the comments and care enough to do so.
Put another way, who would be the consumer of the list of all open issues that need clarification? Rather, one should be interested in the list of issues that one has submitted which are still "Open", and try to minimize that list by contributing patches.
This, and a couple of Doug's comments, raise the issue of contributor vs. committer vs. reviewer vs. other. I'm not clear on how Hadoop does this, either mechanistically or by convention. Is reviewer (my term) equivalent to contributor or committer?
A reviewer is someone whose opinion influences a committer. In the end, a committer must decide that a patch is ready-to-commit. If others review it positively, especially others who the committer has learned to trust, that can influence the committer. For example, Paul Elschot is a contributor (but not committer) whose opinion is typically highly valued.
If things become contentious, then, technically, any change is subject to a vote by the project PMC. But, in practice, committers are trusted by the PMC to make changes on their own. If they are not, they should not be committers.
If no one objects and we have some consensus on how to go forward, I'm happy to contribute to implementing it.
What next steps do you propose? Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
