You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Robert Rose <ro...@gmail.com> on 2012/02/20 00:43:40 UTC
Bloodhound thoughts
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
Re: Bloodhound thoughts
Posted by Ian Wild <ia...@wandisco.com>.
On Mon, Feb 20, 2012 at 8:33 PM, Felix Schwarz <felix.schwarz@oss.schwarz.eu
> wrote:
Maybe it's just a matter of moving the change content up?
>
Yep, that would certainly be a good start.
> Personally I prefer text for simple information, but no hard feelings here.
>
I like *really* simple emails. With HTML you can have a nicely formatted
small space and a lot less information to scan because you can use colours,
mark-up and short hyperlinks.
> However my Thunderbird is usually configured so that it only shows 'plain
> text' (so HTML-only mails will be automatically converted to 'plain text').
> The reason for this is that I get so many badly formatted HTML mails so an
> automatic downgrade is usually more readable than the original.
>
That's a very good point I was missing there. I can imagine a lot of people
do that too. Googlemail spoils me.
Ian
Re: Bloodhound thoughts
Posted by Felix Schwarz <fe...@oss.schwarz.eu>.
Am 20.02.2012 21:14, schrieb Ian Wild:
>> However I'd agree if you say that the information in Trac's notification
>> emails are not optimally layed out for that task.
>
> Quite true. Is it acceptable in todays day and age to default to HTML
> styled emails? Is there even any point in providing a text alternative
> (Surely not even the geekiest geek is still using Pine?).
I was referring to the information shown first in the email: You get all
ticket attributes first and that's pretty annoying if you're interested in
changes (though I like that the information is present). You can see the
problem pretty clearly in Trac's (t.e.o) change emails where the 'text' field
'API changes' is using several lines before any change-related content.
Maybe it's just a matter of moving the change content up?
Personally I prefer text for simple information, but no hard feelings here.
However my Thunderbird is usually configured so that it only shows 'plain
text' (so HTML-only mails will be automatically converted to 'plain text').
The reason for this is that I get so many badly formatted HTML mails so an
automatic downgrade is usually more readable than the original.
Therefore I'd recommend that you check at least that this automatic downgrade
does not remove important information.
fs
Re: Bloodhound thoughts
Posted by Mat Booth <ma...@wandisco.com>.
On 21 February 2012 09:30, Bas van der Vlies <ba...@sara.nl> wrote:
> Another suggestion:
>
> I just read this thread and what really want, is a check if my plugins are
> up to date (like thunderbird/firefox). Now i have to check manually if there
> are fixes or updates of my installed plugins
>
> regards
>
An excellent suggestion! I too would like this feature.
--
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: Bloodhound thoughts
Posted by Bas van der Vlies <ba...@sara.nl>.
Another suggestion:
I just read this thread and what really want, is a check if my plugins are up to date (like thunderbird/firefox). Now i have to
check manually if there are fixes or updates of my installed plugins
regards
--
********************************************************************
* Bas van der Vlies e-mail: basv@sara.nl *
* SARA - Academic Computing Services Amsterdam, The Netherlands *
********************************************************************
Re: Bloodhound thoughts
Posted by Gary <ga...@wandisco.com>.
On 20/02/12 23:18, Robert Rose wrote:
> On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild<ia...@wandisco.com> wrote:
>
>> cases for the project in question. We get:
>> * Recording of an email discussion, including the ability to quickly
>> contribute from a mobile device (no interface can achieve that in a
>> low-data environment better than email).
>> * Easy integration with third party notification systems that generate
>> alerts (eg mails from monitoring tools like Nagios)
>> * Very easy ability to turn an email thread with history into a ticket
>> * Very easy ability for anyone in the business with no training and no
>> hassle to raise a ticket
>>
>> It's not right for every project / case we deal with, but that model is
>> working very well for us in one of our internal projects at least.
> Just to add to what Ian wrote:
>
> It's definitely not right for everyone, but I would recommend it be
> included out-of-box (disabled by default?) if possible.
>
> Recording discussion is a big thing for my group. Where I work, we
> consider it shameful to discuss a trac ticket over email and not "on
> the ticket," we want an archive of every discussion so that we can
> refer back to it later. And because we require all svn changes to
> link to a trac ticket, its great because you can query svn/trac and
> read the discussion that led to a line of code being written. The
> problem is it's just too easy to reply-all to a ticket update email,
> so email discussions happen more often than we would like. And if
> you're on a mobile device, or you're not logged into the VPN, it means
> you're less-likely to take part in the ticket discussion.
>
> We also would like to use trac emails to modify the state of a ticket,
> not just add discussion. We have two other (non-trac) issue
> management systems that do this, and its very handy. For example, if
> your ticket workflow requires an approval before the ticket goes on to
> the next state, you can have the approver just reply to the ticket
> with "approve" and then the state gets updated.
>
>> Quite true. Is it acceptable in todays day and age to default to HTML
>> styled emails? Is there even any point in providing a text alternative
>> (Surely not even the geekiest geek is still using Pine?).
> I don't personally mind the non-html emails that much. The trick with
> HTML email is getting it right for all email clients, especially
> mobiles. If Bloodhound does HTML email, its got to work on an iPhone.
>
> One nice thing about HTML email though is you could run the ticket
> description through a fancy diff tool that paints the text red/green
> for changes, rather than a giant before/after block (that's not very
> useful in email). See
> http://code.google.com/p/google-diff-match-patch/
>
>
>
> We also modded our trac instance to reverse the order of the email
> updates, so changes are first and ticket state is on the bottom.
I have to say that I am very much in favour of being able to use email
to interact with Bloodhound. Clearly we would expect Bloodhound to have
the ability to notify interested users of ticket changes so that they
are not required to remember to look at tickets. Taking that a step
further to allowing users to raise and modify tickets by email does not
seem particularly controversial.
I am also in favour of being able to modify ticket state by email.
Installing by not enabling is a possible strategy. I don't yet know if
we will be able to provide it in a fully working state anyway.
Cheers,
Gary
Re: Bloodhound thoughts
Posted by Robert Rose <ro...@gmail.com>.
On Mon, Feb 20, 2012 at 12:14 PM, Ian Wild <ia...@wandisco.com> wrote:
> On Mon, Feb 20, 2012 at 8:01 PM, Felix Schwarz <felix.schwarz@oss.schwarz.eu
>> wrote:
>
>> I think that's overly simplified. As an system administrator the most
>> important source of information is email (e.g. customer reporting a
>> problem).
>> So replying to an email just makes sense because I'm interacting with my
>> mail
>> client anyway.
>>
>> Indeed - We have implemented this internally and that's one of our key use
> cases for the project in question. We get:
> * Recording of an email discussion, including the ability to quickly
> contribute from a mobile device (no interface can achieve that in a
> low-data environment better than email).
> * Easy integration with third party notification systems that generate
> alerts (eg mails from monitoring tools like Nagios)
> * Very easy ability to turn an email thread with history into a ticket
> * Very easy ability for anyone in the business with no training and no
> hassle to raise a ticket
>
> It's not right for every project / case we deal with, but that model is
> working very well for us in one of our internal projects at least.
Just to add to what Ian wrote:
It's definitely not right for everyone, but I would recommend it be
included out-of-box (disabled by default?) if possible.
Recording discussion is a big thing for my group. Where I work, we
consider it shameful to discuss a trac ticket over email and not "on
the ticket," we want an archive of every discussion so that we can
refer back to it later. And because we require all svn changes to
link to a trac ticket, its great because you can query svn/trac and
read the discussion that led to a line of code being written. The
problem is it's just too easy to reply-all to a ticket update email,
so email discussions happen more often than we would like. And if
you're on a mobile device, or you're not logged into the VPN, it means
you're less-likely to take part in the ticket discussion.
We also would like to use trac emails to modify the state of a ticket,
not just add discussion. We have two other (non-trac) issue
management systems that do this, and its very handy. For example, if
your ticket workflow requires an approval before the ticket goes on to
the next state, you can have the approver just reply to the ticket
with "approve" and then the state gets updated.
>> However I'd agree if you say that the information in Trac's notification
>> emails are not optimally layed out for that task.
>
>
> Quite true. Is it acceptable in todays day and age to default to HTML
> styled emails? Is there even any point in providing a text alternative
> (Surely not even the geekiest geek is still using Pine?).
I don't personally mind the non-html emails that much. The trick with
HTML email is getting it right for all email clients, especially
mobiles. If Bloodhound does HTML email, its got to work on an iPhone.
One nice thing about HTML email though is you could run the ticket
description through a fancy diff tool that paints the text red/green
for changes, rather than a giant before/after block (that's not very
useful in email). See
http://code.google.com/p/google-diff-match-patch/
We also modded our trac instance to reverse the order of the email
updates, so changes are first and ticket state is on the bottom.
Re: Bloodhound thoughts
Posted by Gary <ga...@wandisco.com>.
On 02/21/2012 12:42 PM, Itamar O wrote:
> On Tue, Feb 21, 2012 at 2:32 PM, Gary<ga...@wandisco.com> wrote:
>
>> On 02/20/2012 08:14 PM, Ian Wild wrote:
>>
>>> I'm planning to reach out to a couple of the GPL Plugin developers this
>>> week to see how they would feel about allowing Bloodhound to use these
>>> plugins under a different license. Hopefully we'll be able to find a way
>>> forward on that, but if not I would think it's inevitable that we'll need
>>> to build-in equivalent functionality.
>>>
>>> Ian
>>>
>>>
>> I think we might need to add http://trac-hacks.org/wiki/**CkEditorPlugin<http://trac-hacks.org/wiki/CkEditorPlugin>to the list of plugins to investigate license on if it is preferable to
>> TracWysiwygPlugin. In this case, it is the underlying CkEditor that might
>> be the problem. It is multi-licensed as GPL/LGPL/MPL.
>>
> As I just mentioned in another thread, the CkEditorPlugin should not be a
> problem, as I don't mind relicensing it as needed, as long as it plays well
> with CKEditor's license.
> Assuming licensing problems are solved, the real problems are maintenance
> of the plugin... (no much work occurs these days)
>
I was about to reply to that...
I think that we should be interested in collaborating if the licensing
situation of CKEditor can be resolved. Thanks for the offer.
Cheers,
Gary
Re: Bloodhound thoughts
Posted by Itamar O <it...@gmail.com>.
On Tue, Feb 21, 2012 at 2:32 PM, Gary <ga...@wandisco.com> wrote:
> On 02/20/2012 08:14 PM, Ian Wild wrote:
>
>> I'm planning to reach out to a couple of the GPL Plugin developers this
>> week to see how they would feel about allowing Bloodhound to use these
>> plugins under a different license. Hopefully we'll be able to find a way
>> forward on that, but if not I would think it's inevitable that we'll need
>> to build-in equivalent functionality.
>>
>> Ian
>>
>>
> I think we might need to add http://trac-hacks.org/wiki/**CkEditorPlugin<http://trac-hacks.org/wiki/CkEditorPlugin>to the list of plugins to investigate license on if it is preferable to
> TracWysiwygPlugin. In this case, it is the underlying CkEditor that might
> be the problem. It is multi-licensed as GPL/LGPL/MPL.
>
As I just mentioned in another thread, the CkEditorPlugin should not be a
problem, as I don't mind relicensing it as needed, as long as it plays well
with CKEditor's license.
Assuming licensing problems are solved, the real problems are maintenance
of the plugin... (no much work occurs these days)
>
> The Mozilla Public License might be free enough but
> http://www.apache.org/legal/**resolved.html#category-b<http://www.apache.org/legal/resolved.html#category-b>suggests that we would at least need to be careful. The code involved seems
> to be PHP and javascript.
>
> Cheers,
> Gary
>
Re: Bloodhound thoughts
Posted by Gary <ga...@wandisco.com>.
On 02/20/2012 08:14 PM, Ian Wild wrote:
> I'm planning to reach out to a couple of the GPL Plugin developers this
> week to see how they would feel about allowing Bloodhound to use these
> plugins under a different license. Hopefully we'll be able to find a way
> forward on that, but if not I would think it's inevitable that we'll need
> to build-in equivalent functionality.
>
> Ian
>
I think we might need to add http://trac-hacks.org/wiki/CkEditorPlugin
to the list of plugins to investigate license on if it is preferable to
TracWysiwygPlugin. In this case, it is the underlying CkEditor that
might be the problem. It is multi-licensed as GPL/LGPL/MPL.
The Mozilla Public License might be free enough but
http://www.apache.org/legal/resolved.html#category-b suggests that we
would at least need to be careful. The code involved seems to be PHP and
javascript.
Cheers,
Gary
Re: Bloodhound thoughts
Posted by Ian Wild <ia...@wandisco.com>.
On Mon, Feb 20, 2012 at 8:01 PM, Felix Schwarz <felix.schwarz@oss.schwarz.eu
> wrote:
> I think that's overly simplified. As an system administrator the most
> important source of information is email (e.g. customer reporting a
> problem).
> So replying to an email just makes sense because I'm interacting with my
> mail
> client anyway.
>
> Indeed - We have implemented this internally and that's one of our key use
cases for the project in question. We get:
* Recording of an email discussion, including the ability to quickly
contribute from a mobile device (no interface can achieve that in a
low-data environment better than email).
* Easy integration with third party notification systems that generate
alerts (eg mails from monitoring tools like Nagios)
* Very easy ability to turn an email thread with history into a ticket
* Very easy ability for anyone in the business with no training and no
hassle to raise a ticket
It's not right for every project / case we deal with, but that model is
working very well for us in one of our internal projects at least.
I can also see value in allowing for non-authenticated forms and other
systems to be used to raise tickets with this as the gateway. It's easy to
do that using some easy formmail, or even something like the Google form
tool in Google Docs.
> However I'd agree if you say that the information in Trac's notification
> emails are not optimally layed out for that task.
Quite true. Is it acceptable in todays day and age to default to HTML
styled emails? Is there even any point in providing a text alternative
(Surely not even the geekiest geek is still using Pine?).
I'm planning to reach out to a couple of the GPL Plugin developers this
week to see how they would feel about allowing Bloodhound to use these
plugins under a different license. Hopefully we'll be able to find a way
forward on that, but if not I would think it's inevitable that we'll need
to build-in equivalent functionality.
Ian
Re: Bloodhound thoughts
Posted by Felix Schwarz <fe...@oss.schwarz.eu>.
Am 20.02.2012 19:51, schrieb Joachim Dreimann:
>> * Can email2trac be bundled out-of-box? https://subtrac.sara.nl/oss/email2trac
>
> I would like to know more about this first. From reading some of the
> documentation I have the impression that the purpose of this plugin is
> to provide an alternative method to create/modify tickets for two
> reasons:
>
> 1. Trac's poor mobile/tablet interface
> 2. Forwarding information generated by other systems in an automated fashion
I think that's overly simplified. As an system administrator the most
important source of information is email (e.g. customer reporting a problem).
So replying to an email just makes sense because I'm interacting with my mail
client anyway.
The ticket system in the background ensures that all communication is logged
and can be categorized/searched by everyone.
However I'd agree if you say that the information in Trac's notification
emails are not optimally layed out for that task.
fs
Re: Bloodhound thoughts
Posted by Joachim Dreimann <jo...@wandisco.com>.
+1 to your initial assessment of Trac.
You've done a pretty good job of describing Bloodhound's goals too!
> * Can email2trac be bundled out-of-box? https://subtrac.sara.nl/oss/email2trac
I would like to know more about this first. From reading some of the
documentation I have the impression that the purpose of this plugin is
to provide an alternative method to create/modify tickets for two
reasons:
1. Trac's poor mobile/tablet interface
2. Forwarding information generated by other systems in an automated fashion
I believe Bloodhound will address both points, the first via the UI,
the second via an API.
>From a user experience perspective the syntax used is very specific
and those humans that would generate this manually per ticket would
always (?) be better off using Bloodhound directly when they have
access to it. If they don't, why not? May 1. or 2. above address this?
We should keep in mind that these Emails would be written in a generic
application without specific support for the syntax, so they wouldn't
be able to assist the user in any way, like providing guidance or
timely feedback.
On that basis I would say -1 for now.
> * 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.
This type of information will be shown on top of the Activity feed for
example in future, but more details on that need to be decided on for
a version after the initial release.
> * 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?
As a starting point these would just be pages without much ability to
modify them. The more feedback we receive and can observe people
actually using it, the better we'll understand how far towards full
flexibility we have to go.
A consistent UI will help users build a clear mental model of how
things work, which will allow them to move towards intermediate skills
more quickly, which should then allow them to use wiki macros etc.
- Joe
Re: Bloodhound thoughts
Posted by Olemis Lang <ol...@gmail.com>.
Hi all !
I just arranged previous messages in a different way so as to make
this thread more «readable» ... Hope you don't mind
;)
On Sun, Feb 19, 2012 at 7:31 PM, Jim Callahan
<ji...@statefarm.com> wrote:
> On 2/19/12 5:43 PM, "Robert Rose" <ro...@gmail.com> wrote:
>
>>
>> * 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?
>
> +1 bootstrap
even if I was a bit hesitant at the beginning ... now I second that :
Bootstrap is a lovely monster !
;)
>
> I really like th idea of the widget-style dashboard elements. Making them
> part of the macro system is a great idea.
>
Yes . At least I had already thought of that ;) . Indeed, as I
mentioned in previous messages , widgets are inspired on WikiMacros ;
so they actually have a lot of aspects in common ( ... IOW they are
almost the same thing) . Hence the following notes on the the future
of widgets :
- the only thing needed to make widgets become WikiMacros
is writing an adapter class (easy task ;).
- Later , it'd be nice to implement widgets for all parts of
Trac GUI (e.g. roadmap , milestones , ...)
- Much later , it'd be nice to offer some Genshi py:def(s) so as to
easily embed widgets in templates (... added by plugins ...)
- ... maybe more ;)
>>
>> * 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.
>>
afaicr , the idea was to start by considering Trac Multi-Project
proposal [1]_ and throw some further ideas in there so as to enhance
it . Nonetheless Gary should have more updated info , I guess ... (
and a bunny inside the hat ;)
.. [1] Multiple project support inside a single environment
(http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment)
--
Regards,
Olemis.
Re: Bloodhound thoughts
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Feb 20, 2012 at 8:33 PM, Gary <ga...@wandisco.com> wrote:
> On 20/02/12 23:02, Robert Rose wrote:
>>
>> On Mon, Feb 20, 2012 at 1:41 PM, Olemis Lang<ol...@gmail.com> wrote:
>>>
>>> That's a big subject ... Google Chart and Google Visualization API ,
>>>
>>> they both have these particular terms of usage .
>>> BTW , I'm making (on my own) some (kind of yet experimental)
>>> development for TracGViz and the goal is to render data in local
>>> server . This will make it suitable to be used in e.g. intranets .
>>> Nonetheless for more serious efforts in this direction and
>>> distribution as part of ASF code IMO , there's much more to figure out
>>> yet.
>>
>> We also use the flot API internally http://code.google.com/p/flot/
>> with great success. This is a free[-er] charting package, renders
>> completely client-side and doesn't require access to google's servers.
>
>
> I have looked at flot before for this kind of thing. I think the MIT license
> on that should be free enough for our purposes. Thanks for reminding me!
>
There are some good libraries out-there e.g. flot , RGraph (g)Raphael
, ... many indeed . Important considerations :
- Better to use stand-alone JS graph tool or something built on top of jQuery ;)
- What I had in mind was more about building a small API to deal with
the data ...
- ... which means that widgets may be built using any JS lib on top of
the «API» .
... but well , the idea still needs to evolve a little bit ;)
--
Regards,
Olemis.
Re: Bloodhound thoughts
Posted by Gary <ga...@wandisco.com>.
On 20/02/12 23:02, Robert Rose wrote:
> On Mon, Feb 20, 2012 at 1:41 PM, Olemis Lang<ol...@gmail.com> wrote:
>> That's a big subject ... Google Chart and Google Visualization API ,
>> they both have these particular terms of usage .
>> BTW , I'm making (on my own) some (kind of yet experimental)
>> development for TracGViz and the goal is to render data in local
>> server . This will make it suitable to be used in e.g. intranets .
>> Nonetheless for more serious efforts in this direction and
>> distribution as part of ASF code IMO , there's much more to figure out
>> yet.
> We also use the flot API internally http://code.google.com/p/flot/
> with great success. This is a free[-er] charting package, renders
> completely client-side and doesn't require access to google's servers.
I have looked at flot before for this kind of thing. I think the MIT
license on that should be free enough for our purposes. Thanks for
reminding me!
Cheers,
Gary
Re: Bloodhound thoughts
Posted by Robert Rose <ro...@gmail.com>.
On Mon, Feb 20, 2012 at 1:41 PM, Olemis Lang <ol...@gmail.com> wrote:
>>>+1 for looking further into GoogleChartAPI, although doesn't it
>>>require data to 'leave the premises' for Google to return the chart?
>>>Some companies may not be comfortable with this, whether on reasonable
>>>grounds or not.
>>
>> That's a profound truth. I'd like to have a more contained (??)
>> implementation of that.
>>
>
> That's a big subject ... Google Chart and Google Visualization API ,
> they both have these particular terms of usage .
> BTW , I'm making (on my own) some (kind of yet experimental)
> development for TracGViz and the goal is to render data in local
> server . This will make it suitable to be used in e.g. intranets .
> Nonetheless for more serious efforts in this direction and
> distribution as part of ASF code IMO , there's much more to figure out
> yet.
We also use the flot API internally http://code.google.com/p/flot/
with great success. This is a free[-er] charting package, renders
completely client-side and doesn't require access to google's servers.
Re: Bloodhound thoughts
Posted by Jim Callahan <ji...@statefarm.com>.
It will be hard to sell the powers that be of anything bordering on
sending data outside the firewall, so I'd ask that this be an easily
configurable (I.e. Turn-off-able feature)
On 2/20/12 3:41 PM, "Olemis Lang" <ol...@gmail.com> wrote:
>That's a big subject ... Google Chart and Google Visualization API ,
>they both have these particular terms of usage .
>
Re: Bloodhound thoughts
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Feb 20, 2012 at 2:27 PM, Jim Callahan
<ji...@statefarm.com> wrote:
> On 2/20/12 1:16 PM, "Joachim Dreimann" <jo...@wandisco.com>
> wrote:
>>
[...]
>>
>>> 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.
>>
>>+1 for looking further into GoogleChartAPI, although doesn't it
>>require data to 'leave the premises' for Google to return the chart?
>>Some companies may not be comfortable with this, whether on reasonable
>>grounds or not.
>
> That's a profound truth. I'd like to have a more contained (??)
> implementation of that.
>
That's a big subject ... Google Chart and Google Visualization API ,
they both have these particular terms of usage .
BTW , I'm making (on my own) some (kind of yet experimental)
development for TracGViz and the goal is to render data in local
server . This will make it suitable to be used in e.g. intranets .
Nonetheless for more serious efforts in this direction and
distribution as part of ASF code IMO , there's much more to figure out
yet.
;)
--
Regards,
Olemis.
Re: Bloodhound thoughts
Posted by Jim Callahan <ji...@statefarm.com>.
Thanks for that.
I got the path vs location deal now. I totally misunderstood, my bad
On 2/20/12 2:50 PM, "Joachim Dreimann" <jo...@wandisco.com>
wrote:
>On 20 February 2012 19:27, Jim Callahan <ji...@statefarm.com>
>wrote:
>>
>>
>> On 2/20/12 1:16 PM, "Joachim Dreimann" <jo...@wandisco.com>
>> wrote:
>>>
>>>The breadcrumb should reflect this structure, which handily is also
>>>existant in the Trac Wiki by default. As I understand it
>>>BreadCrumbsNav doesn't do this currently. Also, pages last visited
>>>should be returned to via the back button of the browser!
>>
>> I'd be afraid of complicating the BC functionality. Is there an example
>> out there where this multi-level BC functionality is implemented
>> successfully. I'm not saying it's not, just that I can't think of one
>>off
>> the top of my head.
>
>Apologies Jim for not being clear. Most breadcrumbs show the
>*location* (ie File systems, Websites, etc), which is what I believe
>Bloodhound should do too. Some breadcrumbs show the *path* of how the
>user got there, which is what I understand BreadCrumbsNav does.
>(Wikipedia for further brief definitions:
>http://en.wikipedia.org/wiki/Breadcrumb_(navigation) ).
>
>It seems to me that the plugin chose path over location because Trac
>doesn't have a structure as such, while Bloodhound will have some
>structure.
>
>>
>> My bread crumbs use case is more complicated than a simple click on a
>>back
>> button. I am constantly managing work for multiple milestones and
>> enhancements in multiple different online apps. The BC plugin is key to
>>me
>> being able to remember what I've done and go back just a little bit. I
>> won't necessarily even have a history tomorrow that isn't gummed up by
>> 85,000 other links.
>>
>> But, that may just be me.
>
>I'm sure that's not just you! I'm at least one other person, and I can
>see this being quite a common use case.
>Bloodhound provides more functionality to help you with this though:
>- Activity (Timeline in Trac) is now very prominent in the UI, and it
>makes perfect sense to allow you to filter this by your own actions
>- Custom Query Activity - I believe Custom Queries should have the
>option to show Activities as well as Tickets, with you being able to
>filter both in the same way.
>- Dashboard - While it currently only shows you Tickets allocated to
>you or watched by you, in future Bloodhound will allow you to watch
>anything: eg Projects, Products, Milestones, etc. That will allow you
>to keep track of things across all of the Bloodhound instance.
>- Projects allow you to keep track of anything (Tickets, Milestones,
>etc) across one or more Products.
>
>- Joe
Re: Bloodhound thoughts
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 20 February 2012 19:27, Jim Callahan <ji...@statefarm.com> wrote:
>
>
> On 2/20/12 1:16 PM, "Joachim Dreimann" <jo...@wandisco.com>
> wrote:
>>
>>The breadcrumb should reflect this structure, which handily is also
>>existant in the Trac Wiki by default. As I understand it
>>BreadCrumbsNav doesn't do this currently. Also, pages last visited
>>should be returned to via the back button of the browser!
>
> I'd be afraid of complicating the BC functionality. Is there an example
> out there where this multi-level BC functionality is implemented
> successfully. I'm not saying it's not, just that I can't think of one off
> the top of my head.
Apologies Jim for not being clear. Most breadcrumbs show the
*location* (ie File systems, Websites, etc), which is what I believe
Bloodhound should do too. Some breadcrumbs show the *path* of how the
user got there, which is what I understand BreadCrumbsNav does.
(Wikipedia for further brief definitions:
http://en.wikipedia.org/wiki/Breadcrumb_(navigation) ).
It seems to me that the plugin chose path over location because Trac
doesn't have a structure as such, while Bloodhound will have some
structure.
>
> My bread crumbs use case is more complicated than a simple click on a back
> button. I am constantly managing work for multiple milestones and
> enhancements in multiple different online apps. The BC plugin is key to me
> being able to remember what I've done and go back just a little bit. I
> won't necessarily even have a history tomorrow that isn't gummed up by
> 85,000 other links.
>
> But, that may just be me.
I'm sure that's not just you! I'm at least one other person, and I can
see this being quite a common use case.
Bloodhound provides more functionality to help you with this though:
- Activity (Timeline in Trac) is now very prominent in the UI, and it
makes perfect sense to allow you to filter this by your own actions
- Custom Query Activity - I believe Custom Queries should have the
option to show Activities as well as Tickets, with you being able to
filter both in the same way.
- Dashboard - While it currently only shows you Tickets allocated to
you or watched by you, in future Bloodhound will allow you to watch
anything: eg Projects, Products, Milestones, etc. That will allow you
to keep track of things across all of the Bloodhound instance.
- Projects allow you to keep track of anything (Tickets, Milestones,
etc) across one or more Products.
- Joe
Re: Bloodhound thoughts
Posted by Jim Callahan <ji...@statefarm.com>.
On 2/20/12 1:16 PM, "Joachim Dreimann" <jo...@wandisco.com>
wrote:
>
>
>In other words, when viewing a ticket inside a fully fleshed out
>Product, it will _probably_ belong to a Milestone, which belongs to a
>Version, which belongs to a Product. You can still have Projects that
>cover multiple Products, Versions, Milestones or Tickets, as with
>Components.
That's a very succinct way to put that.
>
>The breadcrumb should reflect this structure, which handily is also
>existant in the Trac Wiki by default. As I understand it
>BreadCrumbsNav doesn't do this currently. Also, pages last visited
>should be returned to via the back button of the browser!
I'd be afraid of complicating the BC functionality. Is there an example
out there where this multi-level BC functionality is implemented
successfully. I'm not saying it's not, just that I can't think of one off
the top of my head.
My bread crumbs use case is more complicated than a simple click on a back
button. I am constantly managing work for multiple milestones and
enhancements in multiple different online apps. The BC plugin is key to me
being able to remember what I've done and go back just a little bit. I
won't necessarily even have a history tomorrow that isn't gummed up by
85,000 other links.
But, that may just be me.
>
>>
>>
>> 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.
>
>+1 for looking further into GoogleChartAPI, although doesn't it
>require data to 'leave the premises' for Google to return the chart?
>Some companies may not be comfortable with this, whether on reasonable
>grounds or not.
That's a profound truth. I'd like to have a more contained (??)
implementation of that.
>
Jim
Re: Bloodhound thoughts
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 20 February 2012 12:47, Gary <ga...@wandisco.com> wrote:
> 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.
+1
> * 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.
As I understand it the BreadCrumbsNav plugin shows a history of
visited pages, rather than your actual location within Trac, because
it doesn't have any hierarchical structure. The key difference here is
that Bloodhound (unlike Trac) will have some structure, ie Products ->
Versions -> Milestones -> Tickets, with Projects and Components being
Tags more or less without structure.
In other words, when viewing a ticket inside a fully fleshed out
Product, it will _probably_ belong to a Milestone, which belongs to a
Version, which belongs to a Product. You can still have Projects that
cover multiple Products, Versions, Milestones or Tickets, as with
Components.
The breadcrumb should reflect this structure, which handily is also
existant in the Trac Wiki by default. As I understand it
BreadCrumbsNav doesn't do this currently. Also, pages last visited
should be returned to via the back button of the browser!
> * 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.
What dependency other than one ticket blocking one or more others do
we need to display?
> * TracWysiwyg - http://trac-hacks.org/wiki/TracWysiwygPlugin
To me it seems that this is doing too much. Providing half that
functionality would not just be sufficient, it would also make it
easier for users to find their way and reduce clutter. 6 Header sizes
+ bold + indentation = 8 ways to bring a structure into the text?
Seems like it's offering everything possible, not only what's useful..
> 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.
Regarding a growing list, I believe we should keep it to a minimum as
all extra features set expectations and increase the workload. I think
it's important to only include those plugins that are really essential
to making Bloodhound great and have a solid process to
find/install/manage/remove additional plugins.
> 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.
+1 for looking further into GoogleChartAPI, although doesn't it
require data to 'leave the premises' for Google to return the chart?
Some companies may not be comfortable with this, whether on reasonable
grounds or not.
- Joe
Re: Bloodhound thoughts
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Feb 20, 2012 at 7:47 AM, Gary <ga...@wandisco.com> wrote:
> Hi Robert and Jim,
>
Hi all once again !
> It is very good to see this kind of interest.
>
:)
[...]
>
> At the moment I am also looking at providing the following by default:
>
[...]
>
> * TracTocMacro - http://trac-hacks.org/wiki/TocMacro
+1
> * TracWysiwyg - http://trac-hacks.org/wiki/TracWysiwygPlugin
I'd rather go -1 for this . IMO we should move forward with CKEditor
plugin [2]_ due to the fact that it is extensible (using plugins ;)
hence this may allow Bloodhound to offer much better user experience
in there (e.g. [3]_ ) . I have some (initial) ideas to integrate it
with Trac / Bloodhound
> 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.
>
XmlRpcPlugin ?
;)
> 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.
>
... it'd be nice to think of product/project inside an environment
just like if it was a Trac<=0.13 environments inherit configuration
from a given environment ... but without all the overhead involved in
that cases (e.g. shared database , easy queries , ...)
just my $0.02
> 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.
>
... oh ! I talked about this in previous e-mail . Generic wrapper
class will provide support for this ;)
> 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.
>
or TracGVizPlugin may be an option as well , nonetheless this will
only work for instances deployed on the Internet ... afaik , but that
can change .
;)
.. [2] CKEditor plugins (greatsoftw channel i.e. my previous work ;)
(http://www.youtube.com/playlist?list=PLABED7BA09947CA55&feature=plcp)
.. [3] CkEditorPlugin - Trac Hacks - Plugins Macros etc. - Trac
(http://trac-hacks.org/wiki/CkEditorPlugin)
--
Regards,
Olemis.
Re: Bloodhound thoughts
Posted by Gary <ga...@wandisco.com>.
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"<ro...@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
Re: Bloodhound thoughts
Posted by Jim Callahan <ji...@statefarm.com>.
+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" <ro...@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