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

[Andrew Harvey]

I know I'm renowned for failed projects, but with some support, this  
would be something I'd be interested in. While Trac has become the  
defacto standard, it has a lot of downfalls. It wouldn't be too hard  
to implement a lot of your hit-list with ruby on rails.
On 26/09/2006, at 8:58 PM, Peter Hosey wrote:

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

I'd suggest something like what Typo (http://www.typosphere.org)  
uses. A combination of akismet, blacklisting and regexp keeps most  
spam off my blog. We could look at a bayesian filtering system, but  
that could tend to be more processor heavy and time consuming,

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

Markdown anyone? Already implemented for Ruby with BlueCloth.

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

I really don't get the DB lock. With fastcgi, it shouldn't be an issue.

>
> - Popcorn!

Also tasty sandwiches.

> <snipping things I agree with>

Sure, I suppose these are all design decisions
> - 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.)

Easily done with Ruby on Rails' routes system.

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

I'd suggest space separations, with quotes for multi-word.

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

Easy enough, again.

>
>
> A couple more more:
>
> - A Google-like search (Google itself if possible). (By this, I  
> mean quality of search results.) A simple site:hostname.domain.com  
> inurl:/tickets/ would suffice, although tighter integration should  
> be done if we can swing it.

Easy. Even livesearch if you want!

I'll add my own, too:

  - Built in IRC bot ;)
  - Auto-generated weekly summary for developers and editors.

We also need to look at what features from trac we deem essential,  
from major to minor. Here are mine:

  - Integration of commits with tickets (ie. "fixes #142" etc.)
  - Strike through links to closed tickets
  - Reports. Pretty reports.
  - Pretty diff support (I think we can do that)
  - Probably more, but I can't think of any.


Andrew

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