On 20/04/12 18:26, Max Thayer wrote:
...

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.

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/