[core-workflow] Tracker workflow proposal

[Ezio Melotti]

On Tue, May 6, 2014 at 5:33 PM, Carol Willing
<willingc at willingconsulting.com> wrote:
> Ezio and Nick,
>
> Thanks for the feedback on the tracker. A couple of more thoughts on
> "personal tags" which hopefully will clarify and save work and time. FWIW, I
> believe the data to determine easily the state of an issue, the next action
> required on the issue, and if the issue is free to work on are most
> important to a new contributor.
>
> A simple "star/favorite" issue toggle was really the extent of what I was
> thinking would have been helpful.
>

For me it would be OK to add it, since I needed it myself more than once.

> For folks with greater Roundup-fu than me: how hard does the "personal tags"
> idea sound? Alternatively, the front end could be more like a personal set
> of "issue lists".
>
> "a way to easily tag issues to return to as
> promising possibilities", then a star/favorite feature might cover
> case 2) and solve the issue,  and even if it's not as fine grained as
> a full personal tags system, it should be simpler to implement.
>
> Ezio's links to his experiments with alternate displays of information
> reminded me of something that I thought about when searching for a suitable
> new contributor issue.
>
> http://wolfprojects.altervista.org/patches.html (requires js)
>
>
> When I was looking for an issue to work on, I tried a number of search
> criteria (easy, new, documentation, testing). It's possible that my
> "search"-fu is lacking, yet I had a difficult time identifying a "bite
> sized" issue related to documentation, testing, or development in either C
> or Python that didn't appear to be actively worked on or very old. I suspect
> there were a number of suitable issues yet it felt like searching for a
> needle in a very large haystack.
>

The haystack is very large (we are approaching 5000 open issues).
hopefully tags (including the "bite sized" one proposed by David) will
make search easier.  My experiment, if properly implemented, will make
search faster (it's possible to search for individual columns too if
we want).  This will allow to refine searches until you find something
interesting.

> At the time I wondered if it just wouldn't be easier to grab the entire
> "csv" file of issues and use ipython notebook with numpy/pandas to run
> interactive searches for issues. Instead, I wound up just randomly reading
> issues from the tracker which was why a "star/tag" would have been helpful.
>

The short answer is probably no.  The main problem is that the csv
only includes ids for the different fields.  So instead of having
"open", "closed", "pending" in the status column you have e.g. "1",
"2", "3".  You can find the corresponding value or each id, but then
you have to replace them and it starts taking more time.  The second
link I posted (http://wolfprojects.altervista.org/issue.index.html) is
generated from the csv (as it was just a proof of concept I put
together in 5 minutes), so it only has the ids and it's not updated
with the latest issues.
The csv might also not contain all the information you need, even
though you can decide which columns should be included by fiddling
with the URL.

> In hindsight, I suspect if I used the entire csv file with appropriate
> search criteria in numpy/pandas that I would have greatly simplified my
> search for an issue. I may do this now so I can see if I can find search
> criteria that would be useful for new contributors to identify suitable
> issues for:
>
> documentation
> increasing test coverage[pulling from the coverage site]
> triaging[identifying specific tasks that someone without developer status
> can do to add value]).
>

If you still want to try, you should be able to see the corresponding
values for each id at the following URLs:
http://bugs.python.org/component ("documentation" is 4)
http://bugs.python.org/stage ("need test" is 2, "need patch" is 3, "no
value" should be -1)

> Thanks,
> Carol
>
>
>
> --
> Carol Willing
> Developer
> Willing Consulting