On 20/04/12 18:26, Max Thayer wrote:
> Luke, maybe I don't understand something about Trac, but some of the
> issues raised by you or those you quoted seem easily fixed. Consider:
>
> "- there isn't a notion of "component", so there's no way to ask
> "give me
> the list of all contrib.auth tickets, so I can find the duplicate
> quickly";"
>
>
> Why not tag all relevant issues "contrib.auth"?
>
...
>
> "- we can't put customized flags on tickets (easy, ui/ux) -- there are
> tags, but the result of the "Keywords" field in Trac shows the limits of
> unstructured tags;"
>
>
> Could you explain this more? "customized flag" sounds exactly like a tag.
They are very different things in reality.
With tags, it is up to people to decide which kind of tagging they think
is relevant. With flags, we've already decided, it's there in the UI,
and every time you create or update a ticket you scroll past the
questions we've decided are important and that you may need to update.
Without this, tagging quickly becomes next to useless for querying.
Also, tags are unstructured, so if you use it for more than one purpose,
everything lives in the same namespace. Sure, there are things you could
do to help matters, like colours and prefixes, but there are no
constraints to stop multiple assignments in the same category etc.
Also, the tracking on these things is basically non-existant in GitHub.
When I read a ticket, it tells me explicitly that such and such user set
such and such flag. For tags like "Ready for checkin", the flag is
*massively* less useful without this information (I will assess the
accuracy of the flag by the person who set it, and also as a core
developer looking for reliable triagers and potential developers, I'm
assessing the accuracy of the person by the flags they set).
It also seems that only managers can set tags in GitHub Issues, which
would kill the community triage process we have.
> "- it's hard to navigate when there are more than 200 open tickets
on a
> project."
>
>
> There are easily that many open tickets on Trac (a quick look seems to
> indicate there are about 2k open tickets). What about Trac makes the
> number of open tickets a non-issue?
For one thing, the Trac UI just makes much better use of screen space.
There is no comparison between these two in terms of easily finding the
information you want:
https://code.djangoproject.com/query
https://github.com/divio/django-cms/issues
Trac also has pretty nice reporting abilities, and report building
abilities:
https://code.djangoproject.com/wiki/Reports
No-one thinks Trac is ideal, it's just much better than GitHub Issues
which, in its own words, is a "lightweight" issue management system.
Luke
--
"My capacity for happiness you could fit into a matchbox without
taking out the matches first." (Marvin the paranoid android)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
