[Tracker-discuss] bugs.python.org schema redesign

[R. David Murray]

On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
> Submitted Bug/Patch
>
> For reported bugs, they need to eventually turn into patches if they happen 
> to be valid bugs. Since the verification is usually very quick this does not 
> need to be explicitly covered by the schema. Plus it should be fairly obvious 
> upfront whether an issue still has yet to be verified a bug.
>
> For people who submit new code, the proposed checkboxes make it clear what is 
> lacking from a patch in terms of core parts (test, solution, and docs). It 
> also lets them know that there is something to be addressed (previously 
> mentioned boxes plus "patch needs work"). Plus they can know when they are 
> the hold-up (status set to "feedback pending"). And the person knows that the 
> issue has been triaged once the status switched off of "- no selection -" to 
> something else.

"Feedback pending" reminds me of the "customer pending" status in our
trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
Whose feedback is pending?  I think you want it to be the submitter, in
which case it should say that, I think.

I think there is some value in the 'stages' workflow: that tests come
first, then the patch, then the review.  So I'm not sure I like the idea
of converting those to checkboxes.

> Looking to Contribute
>
> For those looking to contribute in a generic fashion, there are multiple ways 
> to query for open issues. First off, they can look at the type to decide if 
> they only want to deal with problems in the documentation or go all the way 
> up to a crasher. They can also look at the component it affects to figure out 
> if they want to work on just Python code or dive into C (Lib vs. extension 
> modules vs. interpreter core). If they want to work on just tests, they can 
> look at issues that have the "needs unit test" checkbox selected. Same 
> applies to other checkboxes. And they also have the "easy" keyword.

I'm not sure why you suggest removing so many of the components,
especially '2to3'.  'Macintosh' and 'Windows' should go, I think, or be
moved into an optional 'platform' dropdown and renamed appropriately.
But the others seem useful, and in fact I'd like to generalize the list
into a way to identify any particular library module.  Perhaps that's
a separate dropdown?

> Triaging
>
> If the status of an issue is "- no selection -" then it needs to be triaged 
> before it is considered an "open" issue.
>
> Core Developers
>
> For core developers there is what stage an issue is at. If something requires 
> the attention of a core developer then it will have the keyword "Decision 
> Needed" set by someone in order to get the attention of the developers. That 
> way anyone can try to mark an issue as needing attention without having 
> Developer privileges on the issue tracker.

I like this idea, though if we had enough triage people it would be
better to have the flag alert triage, and triage alert the core
developers if they agree.

> If an issue has one of the two review stages set then they know that someone 
> with Developer privileges has flagged a patch as ready to be reviewed for 
> checkin. And if something gets committed and needs a backport that just can't 
> be done that instant, that can be flagged as well. And with the "patch" 
> keyword is there if a developer wants to help find issues that have code to 
> look at but might not be ready to be checked in.

I may have other thoughts as well later, but these are what occurred to
me today.

--
R. David Murray           http://www.bitdance.com