[Numpy-discussion] Issue Tracking

[Jason Grout]

On 5/1/12 1:52 AM, Travis Oliphant wrote:

>> 1. No key:value pairs for labels (Fernando brought this up a long time
>> ago, I think). This is brilliant in Google code's tracker, and allows
>> for custom fields that help in tracking workflow (like status, priority,
>> etc.). Sure, you can do what the IPython folks are doing and just
>> create labels for every possible status, but that's unwieldy and takes a
>> lot of discipline to maintain. Which means it takes a lot of developer
>> time or it becomes inconsistent and not very useful.
>
> I'm not sure how much of an issue this is. A lot of tools use single
> tags for categorization and it works pretty well. A simple "key:value"
> label communicates about the same information together with good query
> tools.

Sure, it is possible, but it takes the hierarchal information out of the 
picture, so we lose semantic meaning.  It is possible to add two 
different conflicting priorities, for example, and you can't enforce a 
certain workflow like you can with trac states, for example.

Not to mention that the only filtering you can do on labels is by 
clicking the labels on the left, which is an "AND" filter.  How do you 
search for tickets that are labeled priority-critical OR priority-high?

>
>>
>> 2. The disjointed relationship between pull requests and issues. They
>> share numberings, for example, and both support discussions, etc. If
>> you use the API, you can submit code to an issue, but then the issue
>> becomes a pull request, which means that all labels on the issue
>> disappear from the web interface (but you can still manage to set labels
>> using the list view of the issue tracker, if I recall correctly). If
>> you don't attach code to issues, it means that every issue is duplicated
>> in a pull request, which splits the conversation up between an issue
>> ticket and a pull request ticket.
>
> Hmm.. So pull requests *are* issues. This sounds like it might actually
> be a feature and also means that we *are* using the Github issue tracker
> (just only those issues that have a pull-request attached). Losing
> labels seems like a real problem (are they really lost or do they just
> not appear in the pull-request view?)

I just double-checked.  This issue started out as an issue, then I 
"attached" code by using the API to attach a branch to the issue [1]. 
The result is:

https://github.com/sagemath/sagecell/pull/300

You'll notice that there are no tags on the right side, and as a project 
admin, I don't see any way to add them either.  If you go to the list view:

https://github.com/sagemath/sagecell/issues?milestone=6&sort=updated&state=closed

you actually *do* see two tags attached.  I *can* change labels in the 
list view, if it's the list view for *issues*.  If I view the same 
"issue turned pull request" in the pull request list view:

https://github.com/sagemath/sagecell/pulls (you have to click 
"closed"---apparently clicking "closed" doesn't change the URL, so I 
can't give you a link to that listing view...)

then I see at the top (right now) "pull request 300" (though in the pull 
request view, you don't see the 300 to the side, like you see in the 
issue view).  Of course, like other pull requests, you can't attach 
labels in the pull request list view.

 From the above, I get the idea that github does not really support 
attaching code to issues, though it is technically possible through the 
API.  To me, that means that every problem has at least two tickets (an 
issue and a pull request), and you have to make sure to manually close 
and sync one with the other, and the discussion is split up between the 
two tickets.

[1] One of my students has a short script to encapsulate doing this via 
the API: https://gist.github.com/2156799


>
>>
>> 3. No attachments for issues (screenshots, supporting documents, etc.).
>> Having API access to data won't help you here.
>
> Using gists and references to gists can overcome this. Also using an
> attachment service like http://uploading.com/ or dropbox makes this
> problem less of an issue really.

Sure, it's possible, but like you said, it splits up the conversation to 
have parts of it hosted elsewhere.

>
>>
>> 4. No custom queries. We love these in the Sage trac instance; since we
>> have full access to the database, we can run any sort of query we want.
>> With API data access, you can build your own queries, so maybe this
>> isn't insurmountable.
>
> yes, you can build your own queries. This seems like an area where
> github can improve (and tools can be written which improve the experience).

Yep, so the question is: how much of a bug tracker and common reports 
are you willing to rebuild on the github infrastructure, or is it easier 
to use something with all of this built in that also has git/github 
connections.


>
>>
>> 5. Stylistically, the webpage is not very dense on information. I get
>> frustrated when trying to see the issues because they only come 25 at a
>> time, and never grouped into any sort of groupings, and there are only 3
>> options for sorting issues. Compare the very nice, dense layout of
>> Google Code issues or bitbucket. Google Code issues also lets you
>> cross-tabulate the issues so you can quickly triage them. Compare also
>> the pretty comprehensive options for sorting and grouping things in trac.
>
> Yes, it looks like you can group via labels, milestones, and "your"
> issues. This is also something that can be over-come with tools that use
> the github API.

You can filter on those, but I don't see how to group on those (i.e., 
have a big listing of everything, but group the results together based 
on their labels or their milestones, etc.  It makes it much harder to 
get a big-picture view of lots of issues and how they are related. 
Again, of course you can write tools to do this with the github API, but 
again, how much existing bug-tracker functionality do you want to 
reimplement?

By the way: are people keeping a backup of the issues, etc.?  You can 
get a data dump of, for example, the full issue database.  It seems like 
it would make sense for a project, like IPython, to periodically 
download all of its data to make an off-site backup not tied to a 
commercial company.


>
>
> It would be good to hear from users of the IPython github issue tracker
> to see how they like it "in the wild". How problematic are these issues
> in practice. Does it reduce or increase the participation in issue
> tracking both by users and by developers.

I agree; it would be good to hear from someone with wider and broader 
experience with the github tracker on these issues.

Thanks,

Jason