confusing things in Trac UI (was: Design decision for #1625...)
Carl Meyer
Hash: SHA1
On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
> Well, I meant to mark accepted as endorsement of the patch, but that
> made me owner.
Yeah, this is confusing in our Trac UI. The "accept" radio button at the
bottom assigns the ticket to you, it doesn't actually do anything with
the triage state. To change the ticket from DDN to Accepted you'd use
the dropdown next to "Triage Stage" up in the box above.
I'd be in favor of just removing that "accept" radio button if it isn't
hard to do; doesn't do anything you can't do with the "reassign" option,
just gets confused with the triage state.
> I can't own it since I'm not a core committer.
Hmm, I wasn't aware of this policy. We don't seem to make real
consistent use of the "owned by" field, but as far as I was aware it was
just a way to signal that you were working on this ticket so someone
else with interest would check with you before diving in and doing a
bunch of work. I thought anybody could make use of this field if they
planned to push the ticket forward and wanted to signal that.
> Setting it back to nobody set the status to "new".
The "new" vs "assigned" in big letters up top is another thing in our
Trac UI that I think is at best useless, at worst confusing. AFAICT all
it depends on is whether the ticket is owned by someone, and I don't
consider that nearly important enough data (or well-maintained enough)
to put in big letters right up in the header. Triage state is something
we pay a lot more attention to, would seem to make more sense up there.
But I think Trac considers new/assigned to be the same piece of state as
e.g. "fixed" or "wontfix", and that is something that ought to be right
up top. So there may be no simple way to address this.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk55AqEACgkQ8W4rlRKtE2dxGwCgxuubCeRLq69F39wlRJjD8p0m
e8UAoOlXrFESAZCdwT89VzHYQGjLD4gC
=Ivsh
-----END PGP SIGNATURE-----
Paul McMillan
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.
This is a good idea. I made the same mistakes as a new contributor.
>
>> I can't own it since I'm not a core committer.
Unless this has changed very recently, this isn't the case. I've
definitely owned tickets long before I got into core.
> The "new" vs "assigned" in big letters up top is another thing in our
> Trac UI that I think is at best useless, at worst confusing.
Yes! Let's get rid of that. It still confuses me now even when I know
exactly what it means!
Jeremy Dunck
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
>> Well, I meant to mark accepted as endorsement of the patch, but that
>> made me owner.
>
>> I can't own it since I'm not a core committer.
>
> Hmm, I wasn't aware of this policy. We don't seem to make real
> consistent use of the "owned by" field, but as far as I was aware it was
> just a way to signal that you were working on this ticket so someone
> else with interest would check with you before diving in and doing a
> bunch of work. I thought anybody could make use of this field if they
> planned to push the ticket forward and wanted to signal that.
Well, I mostly meant that I think it's RFC (pending running the full
suite) and because of that, I shouldn't be the owner. I think the OP
hoped I'd check it in, and I was trying to make my intentions clear in
the thread.
Julien Phalip
On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote:
> Well, I meant to mark accepted as endorsement of the patch, but that
> made me owner.
Yeah, this is confusing in our Trac UI. The "accept" radio button at the
bottom assigns the ticket to you, it doesn't actually do anything with
the triage state. To change the ticket from DDN to Accepted you'd use
the dropdown next to "Triage Stage" up in the box above.
I'd be in favor of just removing that "accept" radio button if it isn't
hard to do; doesn't do anything you can't do with the "reassign" option,
just gets confused with the triage state.
> I can't own it since I'm not a core committer.
Hmm, I wasn't aware of this policy. We don't seem to make real
consistent use of the "owned by" field, but as far as I was aware it was
just a way to signal that you were working on this ticket so someone
else with interest would check with you before diving in and doing a
bunch of work. I thought anybody could make use of this field if they
planned to push the ticket forward and wanted to signal that.
Stephen Burrows
ticketeer is coming along nicely. (For those who don't know, django-
ticketeer is a django front-end for trac installations which was
spawned during the djangocon sprints). It now supports viewing &
editing tickets, adding tickets, and searching tickets, though a lot
of specific aspects of those actions are not yet supported.
If anyone is interested in contributing, that would be great -
especially people who love front-end work. The project was started
because Trac... doesn't provide the best user experience. Ticketeer
should.
https://github.com/melinath/django-ticketeer
Best,
Stephen Burrows
Luke Plant
> Just thought it might be worth mentioning in this thread that django-
> ticketeer is coming along nicely. (For those who don't know, django-
> ticketeer is a django front-end for trac installations which was
> spawned during the djangocon sprints). It now supports viewing &
> editing tickets, adding tickets, and searching tickets, though a lot
> of specific aspects of those actions are not yet supported.
>
> If anyone is interested in contributing, that would be great -
> especially people who love front-end work. The project was started
> because Trac... doesn't provide the best user experience. Ticketeer
> should.
This isn't really my business, and possibly not on topic, apart from the
fact that Django really ought to be a well-behaved Python citizen, so I
thought I'd voice my concern:
> The project was started
> because Trac... doesn't provide the best user experience.
I really cannot understand this as a rationale. If Trac doesn't provide
the best user experience, surely the obvious thing would be to fix Trac
with some well written patches - it is an open source software after
all. Has this been tried? (Genuine question). Have they said "we are not
interested in improving user experience" or something? I do genuinely
hope I'm wrong, and perfectly willing to be corrected, but to me, this
sounds like thinly veiled Not Invented Here syndrome, and I don't think
that is good for the Django community.
Yes, Trac is not written in Django. But Django isn't perfect, it isn't
the best for every job, and I don't want us to antagonise other Python
communities by suggesting it is, and by doing our own thing instead of
contributing work back to the original project. The latter is much
harder in many ways than the former, but I would suggest it is much more
profitable in the long run, and a good opportunity to learn from another
project, which will surely have significant strengths of its own.
Regards,
Luke
--
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor)
Luke Plant || http://lukeplant.me.uk/
Russell Keith-Magee
I completely agree that rebuilding Trac just to have a Django version
of Trac isn't a particularly attractive idea to me. If there's some
contribution we can make back to Trac, we should certainly do that
rather than try and build our own version of Trac that will inevitably
have it's own flaws.
That said...
David Eaves' opening keynote at DjangoCon certainly gave me some food
for thought about directions that this sort of project could lead.
http://blip.tv/djangocon/keynote-david-eaves-5571777
David spoke about community management, and about how the tools that
we use for community management are a key part in coordinating our
volunteer user base. In particular, it got me thinking that while Trac
may well be a perfectly serviceable tool for managing the internal bug
tracking lifecycle, it may *not* be the best public facing tool for
interacting with our community.
David made the valid point that when someone contributes -- in any way
-- having their first experience being "You've posted in the wrong
place" or "don't post that here" or "that's a duplicate" isn't very
productive -- in fact, it can be counterproductive, as it turns
someone who *might* turn into a valuable contributor into someone who
has had a negative experience with the project.
There may be some space here for a tool that is focussed on this sort
of user experience. "Replacing Trac" isn't an interesting goal in
itself, but improving the interface to Trac *is* an interesting goal
-- and that may mean wrapping Trac in a set of tools that aren't
appropriate for inclusion in Trac itself.
Yours,
Russ Magee %-)
Brian Neal
>
> Yeah, this is confusing in our Trac UI. The "accept" radio button at the
> bottom assigns the ticket to you, it doesn't actually do anything with
> the triage state. To change the ticket from DDN to Accepted you'd use
> the dropdown next to "Triage Stage" up in the box above.
>
> I'd be in favor of just removing that "accept" radio button if it isn't
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.
>
assigned to the ticket hit "accepted" when he/she actually starts
working on the ticket. It is used to indicate that the assigned person
is actively working on the ticket. I'm not arguing it one way or
another with respect to Django usage, I'm just explaining what I think
the purpose of that state is in an out-of-the-box Trac install.
BN
Florian Apolloner
On Monday, September 26, 2011 9:06:47 PM UTC+2, Brian Neal wrote:
I'm not arguing it one way or
another with respect to Django usage, I'm just explaining what I think
the purpose of that state is in an out-of-the-box Trac install.
Jupp, that's the state now -- sadly code.djangoproject.com uses trac for ages already and as such we do have the old workflow as described here: http://trac.edgewall.org/wiki/TracWorkflow
The new work flow of trac 0.11 separates accepting from assigning; see the second image on the linked page above. We could also modify that workflow and add all our Triage states completely into this work flow (see http://trac.edgewall.org/wiki/WorkFlow/Examples for some examples of work flows).
Cheers,
Florian
Jacob Kaplan-Moss
> Yes! Let's get rid of [the "accept" button]. It still confuses me now even when I
> know exactly what it means!
If anyone knows how to do this, let me know and I'll make it happen.
Jacob
Daniel Moisset
If you ping my on IRC (Darni on freenode) I can give a hand, it should be 5-10 mins if you have your install handy
D.