bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Top 3rd party plugins
Date Sat, 15 Dec 2012 12:51:10 GMT
On Fri, Dec 14, 2012 at 12:16 PM, Ryan Ollos <>wrote:

> On Fri, Dec 14, 2012 at 3:46 AM, Jure Zitnik <> wrote:
>> Hi all,
>> does anybody have an idea where/how I could get a list of most commonly
>> used trac 3rd party plugins? I've been looking at but
>> there's no 'most popular' section there ;)
>> Cheers,
>> Jure
> Hi Jure,
> The closest thing I know of is the WhatUsersWant page on t.e.o [1]. There
> are also some suggestions on the SiteUpgradeProposal [2] on how we can
> gauge the popularity and stability of plugins. The first step, when I/we
> finally get the site upgraded to trac 1.0, is to add download statistics.
> However, there are so many ways of getting a plugin: install from PyPI,
> download ZIP from t-h.o, checkout from  t-h.o SVN; and number of downloads
> does not necessarily reflect the number of installs for obvious reasons -
> therefore this will hardly be a great measure.
> I think we'd find support for installing a plugin on t-h.o that would
> allow authenticated users to "vote up" plugins. This could be something
> like an "I use this" button on each page, and we could have a view of the
> site-wide data on plugin usage. This voting plugin would have be developed
> though.
> There exists at least two PollMacros and a VotePlugin which could serve as
> starting points for creating the plugin we need to collect the data. The
> VotePlugin is used on t.e.o; you can see it in action by navigating to a
> ticket and seeing the up/down arrows in the contextual navigation area.
> I've been maintaining this plugin, but haven't done much with it lately. We
> could extend it to do what I suggested here in a few days works. Installing
> it on t-h.o would require a site upgrade as well.
> It would be more practical to just create a poll using a third party tool,
> and post the poll to the trac and bloodhound communities. We could even
> allow for voting on the most desired plugins that don't yet exist. I think
> this would be fairly well received in the trac community, even if it
> originated from the Bloodhound community. I don't have a good guess as to
> what kind of response we would get.
> I feel like I have a fairly good sense of the popularity of various
> plugins. My list would potentially be biased though, so maybe we want to go
> one of these other routes in order to get real data.
> [1]
> [2]

I was thinking about this some more while reading over #168 this evening
[3]. #168 raises an issue which is very likely to depend on a user
or administrator preferences, and suggests that it would be valuable to get
feedback on how users feel about the feature. That led me to thinking,
wouldn't it be nice to allow voting on tickets such as this?

Maybe we should just install the VotePlugin on i.a.o, and use that to
collect feedback, like they do on t.e.o? It doesn't exactly address the
need that Jure raised in this email thread, but it will potentially provide
us with supporting data over time, and the feature could be a lot more
valuable as the community grows. In comparison to a page such as [1], I
think that using the VotePlugin would be a better way to collect feedback.
Why have a page listing a bunch of tickets and ask users to edit the page
with their vote when you could just add a keyword the tickets of interest
(e.g. keyword: "major-feature"), present a report of all of the proposed
features, and allow users to vote directly on the tickets?

We could even consider just bundling the plugin with bloodhound if we think
it will be generally useful (I'm neutral on that at the moment). We can
enhance the plugin with macros and an admin panel along the way in order to
add presentations of the vote data that the plugin currently does not

We are currently blocked by a minor issue [4], but I will aim to get that
fixed this week and report back here. If we install on i.a.o, we may want
to tweak the CSS a little bit so that it better fits the theme.


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