Hi Robert and Jim,
It is very good to see this kind of interest. These contributions to the
conversation are still coming at a very good time and it is great to
hear things that you want to see.
For the mentioned plugins:
* email2trac: I'll have to have a look at this. Being able to use
email to raise tickets is a good thing but, as it is GPL rather than
Apache or BSD licensed, we may need to be a bit more careful about
how we deal with this.
* BreadCrumbsNav: I was not thinking of adding this before but it
seems worthy of investigation. By default it shows the last 6
visited pages, though only if their paths start with milestone, wiki
or ticket (each of those aspects are configurable). I hope that
Joachim can have a look at this and see whether it duplicates or
conflicts with our ideas on navigation.
* Master/Child tickets: I was thinking of choosing the Master ticket
variety for this functionality. It provides the means to specify a
ticket as being blocked by another this seems a reasonable way of
describing the kind of relationships that are needed for ticket
management and we can investigate the use of graphviz for displaying
the dependencies.
At the moment I am also looking at providing the following by default:
* TracAccountManager - http://trac-hacks.org/wiki/AccountManagerPlugin
* BatchModify - http://trac-hacks.org/wiki/BatchModifyPlugin
* TracTocMacro - http://trac-hacks.org/wiki/TocMacro
* TracWysiwyg - http://trac-hacks.org/wiki/TracWysiwygPlugin
I suspect that this list is likely to grow a bit. It would be good to
see more suggestions in this area so that we can see what people think
are good.
The multi project strategy is going to be a single environment (single
database) solution. Essentially we are going to add another top level of
organisation which we are calling products at the moment. This is
intended to allow you to work within a particular product almost as if
it were a separate area (with its own wiki and tickets) and allowing you
to refer to tickets and wiki pages in a different product with an
InterTrac like syntax.
I think converting the dashboard elements to macros would be an
excellent idea too. I don't want to slow initial development so if that
is not the way that Olemis has already gone we should continue along the
existing route and we can factor out the functionality into macros a
little further down the line.
We are also interested in providing views of how milestones and products
progress over time. It is probably worth discussing what people would
want from that in more detail. Making use of the GoogleChartAPI plugin
might well be one of the easier ways of doing that.
Cheers,
Gary
On 02/20/2012 12:31 AM, Jim Callahan wrote:
> +1 bootstrap
> +1 breadcrumbs bundled
>
> +1 (or more) for better multi-Trac support
>
> I really like th idea of the widget-style dashboard elements. Making them
> part of the macro system is a great idea.
>
> jim
>
>
>
> On 2/19/12 5:43 PM, "Robert Rose"<robert.w.rose@gmail.com> wrote:
>
>> Hey all, I was googling around yesterday to see if anyone else was
>> working on a trac fork and discovered bloodhound. I've always found
>> it frustrating that the out-of-box experience with trac sucks. To get
>> trac up to where other issue management systems are you need to do a
>> fair bit of configuration and play around with some plugins. Not to
>> mention the UI looks like it came from the 90s, so most
>> newer-generation folks are immediately put off by it. If you grade
>> solely on the out-of-box experience, other systems like JIRA win
>> against trac. This is unfortunate because trac's extensibility and
>> simplicity (in my opinion anyways) make it a better long-term choice
>> for issue management.
>>
>> Anyways I'm glad others are actively rethinking these aspects of trac.
>> Before I did my googling yesterday I was playing around with a
>> bootstrap reskin for trac (hacking directly on the genshi templates),
>> so I'm especially delighted that you've chosen bootstrap. I haven't
>> caught up on all of the email archive yet, but I have a few thoughts I
>> wanted to share, so I apologize in advance if these were already
>> covered.
>>
>> * bootstrap +1
>>
>> * Can email2trac be bundled out-of-box?
>> https://subtrac.sara.nl/oss/email2trac
>>
>> * Can the breadcrumbs plugin be bundled out-of-box?
>> http://trac-hacks.org/wiki/BreadCrumbsNavPlugin
>>
>> * I would love it if one of the child / master ticket plugins was
>> included out of box, but rendered in the UI in a clean way
>> http://trac-hacks.org/wiki/ChildTicketsPlugin
>>
>> * Review of historical ticket data is an essential part of our
>> project management method. We have scripts that mine trac for
>> historical data and plot it using the google charts API. Tickets are
>> plotted by state over time, ticket "velocity" (the rates at which they
>> move through states), etc. It would be great if this was just part of
>> trac and available as a wiki macro.
>>
>> * I like the dashboard/activity views that have been shared but I'm
>> not clear if these are supposed to be new pages, or new functionality
>> available as wiki macros? I make a lot of dashboards using trac and
>> wiki macro queries, it would be nice if these dashboards you're making
>> were customizable using the same mechanism... can they just be wiki
>> pages themselves?
>>
>> * What's the multiple project strategy? We use trac to host multiple
>> projects on the same server just using apache redirect rules and the
>> intertrac plugin. It works very well, but is not easy to
>> setup/maintain. Would be nice if this was just done for you.
>>
>> -robert
|