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

Tue Sep 26 21:17:36 UTC 2006

Hey Guys,

Chris,

Thanks for linking me to this thread.

OK. I've been developing for 6+ years and worked with almost all  
combo of bug + code management system that's been out there. I've  
settled on trac for the following reasons:

it's one tool (i *hate* bugzilla + cvsview + somewiki + roadmaptool).  
Users don't have to scrabble around for where to go to do xyz. Devs  
also don't have to be logged into 5 different places. I went to  
extreme lengths to ensure that your svn username + pass is the same  
as trac.

The markup is not html. It's markdown (i think) and yeah, so you  
gotta learn it but it's safer than permitting html.

One thing I learnt being associated with the mozilla project....  
users don't get anything. The best bug report is when you sit with  
then and ask them questions as the probelm happens. Even then it can  
still be voodoo.

some of these suggestions are interesting and should make their way  
into trac -

and as far as the deadlock problem i'm going to investigate moving  
from sqlite to mysql - once i've gotten all the rest of the users off  
that box and i can upgrade to my5.

Best,

james

On 26 Sep 2006, at 20:06, Christopher Forsythe wrote:

>
> 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.

--

James Cox,
Internet Consultant
t: 07968 349990  e: james at imajes.info w: http://www.imajes.info/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060926/72e0b1d3/attachment-0001.html>