Looking at some currently closed issues, it looks like it should be possible to add comments and links to closed issues. It provides the comment button anyway. I haven't tried to push it. We could test on the test SOLR issue.
Looking at the Jira docs, it looks like you can configure closed issues to be editable or not, your choice. Other than the edit operation, it doesn't look like you can configure the set of available operations on a per-status (state) basis. (Again, that's from looking at the docs, so I could have missed something.) As to the issue of "rough patches", I guess I'm thinking about bounded lists vs. unbounded lists. As mentioned, it would be nice if the number of issues in "patch available" (the polished kind) was kept small. I think on Derby, they mail that list of issues to the dev list periodically (attention by annoyance). To keep other states from growing without bound, we would either have to have a state which was meant to be that way (for those hair-brain-stormed kinda of patch), or age them out after a while, maybe closing them for lack of interest. My main concern is that things get lost in lists that grow without bound. With the Hadoop workflow, it's not really an issue for things with patches and active contributors. 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? 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? 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? If no one objects and we have some consensus on how to go forward, I'm happy to contribute to implementing it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
