[core-workflow] Tracker workflow proposal

[Ezio Melotti]

Hi,

On Mon, May 5, 2014 at 6:24 PM, R. David Murray <rdmurray at 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.

A few questions:
1) should we merge the keywords into components, do the opposite, or
create a brand new "tags" field?
2) how are we going to migrate metadata from the old format to the new one?
3) with "all the labels from the experts index" you mean every single
entry?  There are quite a lot of entries (all the modules, platforms,
interest areas: https://docs.python.org/devguide/experts.html );
4) how should this look without js? similar to the nosy list (input
box, without autocomplete), or select/option like the one we currently
have for components/keywords (entries can be grouped, but they are
still a lot);

And a few comments:
1) tags/labels should be color-coded so that each group has a
different color (module, platform, component, general, release,
etc..), if they are not too many they could be showed in the issue
list too (think about gmail labels);
2) the autonosy should be revised once we do this.  One idea is to
suggest people to add (Something along the lines of 'You selected the
module tag "html", suggested dev: [ezio.melotti]').  The other idea is
to handle this automatically -- on the expert index with have a * to
allow assignment, we might do something for nosy too and use this to
handle autonosy/autoassign.  Otherwise we can just edit
autonosy/autoassign like we currently do (manually from roundup), but
with more available tags;


> 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).
>

+1 for fixed set.  Free tags might lead to redundant or misspelled
tags (and possibly things like #ibrokepython #lolsegfault #yolo).  We
could add tags if we think they are useful, but if we want to add free
tags they should be in a separate category with their own color code
and an easy way to moderate them.

> 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.
>

My latest experiment is:
http://wolfprojects.altervista.org/patches.html (requires js).
This includes a few ideas:
1) detecting if the patch has tests/docs/news/acks (see last column on
the right);
2) detecting the files it affects (second last column on the right;
could be used for module auto-tagging);
3) having a simple way to filter/inspect patches in real time with js;

1 and 2 should be integrated on the issue page, 3 could be done on a
separate page.

Since 3 looked like an interesting idea (it makes search a lot easier
-- you can just filter/group for user name, files, issue, etc on the
fly), I also put together a proof of concept for a similar interface
that could replace the main issue list (and/or be used in the
dashboard):
http://wolfprojects.altervista.org/issue.index.html

To implement this we just need a fixed page and feed issues to it via
ajax/json.  With a bit of caching we can make the whole thing very
efficient (no need to build the page server-side every time, less data
moving on the network, real-time client-side
filtering/grouping/searching, no need to go back and forth from the
search page to refine queries) so the idea has lot of potential.
While this is not too difficult to implement, it still requires some
work, so for now it's low priority.


> Although this wasn't discussed directly, I also removed 'committer
> decision needed' from the list of states, leaving just 'decision needed'.

Are there limitations on who can change the stage from "decision
needed" to something else?
ISTM that if a user provides information he can move the stage to
"decision needed" or if he provides a patch he can move the stage to
"review needed", but do we want them to add their opinion and move it
from "decision needed" to something else?
Also is it expected that we move back to previous stages (e.g. going
back to "decision needed" after a few different patches have been
proposed) or you were thinking about a more linear evolution?

> 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'.
>
> If this is deemed acceptable, then I would propose that we (a) go
> ahead and make that change,

that == the list of stages you suggested?

> (b) make the change to the 'assigned to'
> field, (which we are currently not using much at all),

So make it possible to assign the issue to everyone and then start
using it like this?

> (c) add code to the existing UI to allow regular users to make the state (stage)
> transitions as outlined in my proposal,

For this we need to change the schema too, since currently users are
not allowed to change the stage.
Regarding the UI changes, what exactly do you want to change?

> and (d) add the dashboard UI
> for getting optimal access to the resulting queues.

Adding a new page for this can be done quite easily, getting the
queries right might be a bit more complicated (I think we shouldn't
use sql directly, and not all the values are easily accessible from
the Roundup API).

> These changes are
> really the heart of my proposal, and would get us a lot of the benefit,
> even before we optimize the UI.
>

It would be good to set up an online test tracker where we can
push/test changes live, get some feedback, and then apply the change
that works best to the real tracker.  This would make things much
easier, so I would give higher priority to this.
Having some tentative mockups for the new interface would also help
get a better idea, especially if we can get some designer to help us
out (that could be done later once we decided the fields we want
though).

> --David