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

[Peter Hosey]

On Sep 26, 2006, at 12:06:12, Christopher Forsythe wrote:
> 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.

That's why I didn't suggest a mark-up language. It should Just Work  
with anything obvious (e.g. ‘-’-bulleted lists), and not try to be  
fancy.

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

My list of items basically turns Trac into something else altogether.

I don't think plug-ins are enough to do the job, and I have my doubts  
as to whether they'd be willing to change their product so completely  
to address all the points on my list.

>> Or maybe a new support/development system altogether?
>
> Well, let's look at the options:
>
> [list of existing bug systems]
>
> Point is though, they all have problems.

That's why I suggested a *new* system, rather than just a *different*  
system.

New as in, not previously existing.

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

I haven't.

> MediaWiki syntax confuses users just as bad as InterWiki.

I didn't say that users should be allowed to edit the wiki; in fact,  
I said the exact opposite. The syntax by which links are created is  
irrelevant to the users; only editors on up need to know about it,  
and I should think that anybody to whom we grant such access would be  
known to be clueful enough to be able to handle it.

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

It's not a persistent account, though, which is where people get  
nervous. We hear time and again that people don't want to register  
for an account; they just want to report their bug.

And it does create extra steps; even if it takes longer each time  
than simply putting in a username and password, it's still simpler  
and faster from the perspective of a user who doesn't have to go  
through a registration process (of un-fore-known length). (Also, some  
users can't find the “login” link, and it takes them out of the  
ticket form and loses whatever they'd entered there. Ajax would be a  
win here.)

The average user only submits one bug, I'd guess, which makes no user  
accounts a savings (of time for the user).

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

That doesn't sound at all like what I wrote.

The words in the list would be censored from the ticket description  
or comment when viewed by a user. Only developers would get to see  
the uncensored description/comment.

>> - A feature akin to WordPress' “post slug” for confirmed
>> tickets.
>
> This doesn't make much sense, it seems more like a feature request  
> than a "evil of trac".

Truth.

> Does the "needs dev review" milestone not cover the basics of this  
> request?

Those two things don't sound alike.

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

Because of Trac's lacking spam protections.

> The point of our using Trac was that filing a ticket was simple,  
> even  if we ended up forcing user registration.

That's made it non-simple from the user perspective, as we've heard  
several times in the past week on the feedback list.
________________________________
\ Peter Hosey / prh at boredzo.org
PGP public key ID: 7AB26BAD (since 2006-01-01)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060926/ed8cd262/attachment.sig>