<br><br><div>On Mon May 05 2014 at 11:54:18 AM, R. David Murray <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm a week later than I expected, but I've added my notes to the<br>
discussion summary started by Ezio at:<br>
<br>
<a href="https://wiki.python.org/moin/TrackerDevelopmentPlanning" target="_blank">https://wiki.python.org/moin/<u></u>TrackerDevelopmentPlanning</a><br>
<br>
Based on the feedback, I propose two major changes compared to my<br>
initial proposal.<br>
<br>
The first is to combine 'keywords' and 'component' into a single<br>
tags field, which will include all the labels from the experts index.<br>
Types is reduced to *just* documentation/bug/enhancement, everything<br>
else is a tag. Likewise priority is reduced to just high/normal/low,<br>
and release-blocker and deferred-blocker become per-release tags.<br>
<br>
I think the tags should at least initially be a fixed set (that is,<br>
normal users can't add tags).<br></blockquote><div><br></div><div>SGTM. I know Ezio pointed out the list will be long, but since triagers will be the ones typically setting the field it shouldn't be an issue.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The second major change is that I think we should defer the decision about<br>
how to manage patches until we can experiment with some possibilities.<br>
In particular, Ezio has some preliminary code to do content analysis<br>
on patches, and I think we should experiment with incorporating that,<br>
and try out a couple of different ways of managing patches once we have<br>
that automated analysis working. Ezio made some notes about this on<br>
the document.<br>
<br>
Although this wasn't discussed directly, I also removed 'committer<br>
decision needed' from the list of states, leaving just 'decision needed'.<br>
The various 'closed/xxx' items can at least for now (and probably forever)<br>
continue to be a 'closed' state plus the (simplified) 'resolution'.<br>
Given this, it would be quite practical to simply change 'stage' list<br>
from its current value to what I propose for the new state. That means<br>
it would look like this:<br>
<br>
- no selection - (that is: new)<br>
information needed<br>
decision needed<br>
patch needed<br>
review needed<br>
patch update needed<br>
commit review needed<br>
resolved<br>
<br>
We can then add reactors (and javascript) such that changing an issue<br>
stage to 'resolved' also closes it, and that changing an issue status to<br>
'closed' resolves it, and vice versa (re-opening an issue goes to, say,<br>
'patch needed' if no specific stage is set; changing the stage reopens<br>
the issue). This will make it easy to implement the new state scheme<br>
and build the UI for the queues &c, and when we are ready to cut over<br>
to the new UI, we can retire 'status'.<br></blockquote><div><br></div><div>Also SGTM.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If this is deemed acceptable, then I would propose that we (a) go<br>
ahead and make that change, (b) make the change to the 'assigned to'<br>
field, (which we are currently not using much at all), (c) add code<br>
to the existing UI to allow regular users to make the state (stage)<br>
transitions as outlined in my proposal, and (d) add the dashboard UI<br>
for getting optimal access to the resulting queues. These changes are<br>
really the heart of my proposal, and would get us a lot of the benefit,<br>
even before we optimize the UI.<br>
<br>
--David<br>
______________________________<u></u>_________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org" target="_blank">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" target="_blank">https://www.python.org/psf/<u></u>codeofconduct</a><br>
</blockquote>