incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary <gary.mar...@wandisco.com>
Subject Re: Bloodhound thoughts
Date Mon, 20 Feb 2012 12:47:37 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message