[Adium-devl] The evils of Trac (was: Re: [Adium-feedback] Fwd: ContactUs - Adium X - Trac)

[Christopher Forsythe]

On Sep 26, 2006, at 5:52 AM, Peter Hosey wrote:

> (Redirected from feedback thread.)
>
> On Sep 25, 2006, at 22:20:08, Nathan Duran wrote:
>> 4. Knowledge of proprietary markup pseudo-language required to  
>> format text.
>
> This is the biggest problem our users have. *Every* user fails at  
> this. The two biggest examples being failed lists and hugemongous  
> globs of crash log in every ticket.

We could just make a plugin for a markup language that does make  
sense, or submit patches that help there. But any markup language  
that we used, on any system, would be problematic. People even have  
problems with forum [foo] type code.

>
> Maybe it's time for an Adium fork of Trac?

Aren't we busy enough? Plus anything we'd do could be done in plugins  
anyhow. Doesn't really necessitate a fork.

> Or maybe a new support/development system altogether?
>

Well, let's look at the options:

bugzilla - ugh. The macports guys are moving away from this to trac.  
I also believe this requires registration by the user.
simpleticket - too early to use it. Plus it requires registration.
Mantis - Actually wouldn't be too bad. Requires either a user account  
to be made, or usage of anonymantis. Which has no spam protection.
The other 30-40 options: 9/10 require user registration that I have  
found.

Point is though, they all have problems. I don't know of any (doesn't  
mean there aren't any) that integrate as well with svn though.

> Hit list (in no particular order):
>
> - Much better spam protection. Nobody should have to sign up for an  
> account or request the bathroom key to be able to file a ticket.
>

Do the other systems even have spam protection? Or allow anonymous  
ticket posting?

> - Saner and simpler markup. Don't do white-space collapsing, and  
> don't require white-space before list markers (WTF?). Allow many  
> different bullets: •, ⁃, *, -, and any others we can come up with.
>

Have we filed tickets with the trac devs about this?

> - Spray liquid nitrogen into that damned database lock. Then hit  
> with a hammer. Sweep up shards.
>

ugh, ya, we're working on it.

>
> - Abandon InterCapWikiLinks in favor of MediaWiki syntax.  
> InterCapWikiLinks just look weird. A user should never see them.  
> They also make saying words like QuickTime awkward, since you get a  
> redlink for most of them. (Not to mention, MediaWiki also doesn't  
> require the aforementioned white-space in front of list items.)
>

MediaWiki syntax confuses users just as bad as InterWiki. Just in  
different ways. I'm wondering if we can just disable this stuff though.

> - Require a name (fake or not) and email address to submit tickets.  
> State up-front that we will not spam them and we will not show the  
> address. Offer UI to unsubscribe from ticket-update emails. Email  
> address is taken as a sort of loose password to enable uploading  
> files (with some sort of Ajax magic: enter email address, click  
> button, upload form magically appears).

Umm.. isn't requiring a name and email address basically  
registration? I know, you aren't "registering" for an account, but  
you're providing the same things that registering would provide.

>
> - RSS for updates to specific tickets. For example, http:// 
> cart.adiumx.com/ticket/eleventybillion?format=atom.
>

File a ticket with trac devs.

> - Support for special mark-up to hide portions from anybody except  
> developers. I nominate “{~{~{ … }~}~}”. This wouldn't be  
> necessary for email addresses, which can be automatically detected  
> and should be hidden for free.
>

I nominate filing a ticket with the trac devs ;). They're moving from  
clearsilver to genshi, .10 is about to be released, so they're in  
their dev cycle now or in a week or two at most.

> - Also, an editable list in the submit-ticket and comment-on-ticket  
> forms for:
>
>   	Words (e.g. $EXAMPLE) you want hidden from non-developers. You  
> don't need to list email addresses here; they are always hidden  
> from non-developers.
>
>   For us, EXAMPLE would be “specific IM handles and/or ICQ UINs”.
>

So hidden fields for contact info and other types of info? File a  
ticket with trac devs.

> - A feature akin to WordPress' “post slug” for confirmed  
> tickets. For example,
>   	http://trac.adiumx.com/ticket/5585
>   could become
>   	http://cart.adiumx.com/ticket/aixmlappender-crash
>
>   Users don't come up with good enough descriptions, so these  
> should be assigned by developers, and only when a problem is  
> confirmed. Random tickets shouldn't be assigned these. The moment  
> of assigning a milestone is a good time to also assign a post slug.
>
>   Ticket numbers (e.g. http://cart.adiumx.com/ticket/5585) would  
> still work, but would do a temporary redirect to the slug if a slug  
> is present. (Not permanent, since the slug can be changed,  
> especially if the nature of the bug is revealed to be something  
> different.)
>

This doesn't make much sense, it seems more like a feature request  
than a "evil of trac". Again, request this with the trac devs. Does  
the "needs dev review" milestone not cover the basics of this request?

> - More flexibility in dealing with keywords. Specifically, drop  
> punctuation (‘,’, ‘;’). This should effectively bring across  
> to users that punctuation isn't necessary.

Trac devs.

>
> - Simplify permissions. The basic level (not logged in) would be  
> able to read wiki pages and submit and comment on tickets. Accounts  
> on the site would have any of three levels of permissions: admin,  
> developer, and editor. The last of these would have write access to  
> the wiki, but not be able to edit tickets (only comment on them).

We can do all of this with groups pretty easily. However, not logged  
in is not an option.



In conclusion. I don't think moving away from Trac would be  
beneficial. Other systems just have their own sets of problems, we'd  
be exchanging the problems we have with trac for the problems we'd  
have with some other system. The point of our using Trac was that  
filing a ticket was simple, even  if we ended up forcing user  
registration. I don't think other systems are going to give us that.

I've been investigating other options for the last 2-3 months and  
I've seen nothing that compares to the ease of use on the developer  
and user end. If anyone has suggestions that'd probably be useful,  
but it'd still just be swapping problems.