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