forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sina K. Heshmati" <s...@khakbaz.com>
Subject Re: Brainstorming on the Baetle Plugin
Date Wed, 25 Jul 2007 19:21:42 GMT
Ross,

I'm trying to make the SKOS plugin dispatcher aware but my original Cocoon sitemap doesn't
seem to work well with Dispatcher so I should consider rewriting them probably looking at
the DOAP plugin.

At the same time, the DOAP plugin is using a fixed base path (projectDetails) for its samples.
Now, do you think I should follow the same approach as in the DOAP plugin or strive to make
it work using sourcetypeaction?

SinDoc

On Tue, July 17, 2007 1:48 pm, Ross Gardler <rgardler@apache.org> said:

> On 16/07/07, Sina K. Heshmati <sina@khakbaz.com> wrote:
>> The development of the Baetle plugin was suspended [1] and the priority was given
>> to
>> the SKOS plugin. Now, I think that the community could already start to
>> brainstorm
>> around the design and development of the plugin in question.
>>
>> Meanwhile, I'm discussing [2] with Henry Story to setup standard procedures to
>> extract data from issue tracking systems (starting with JIRA), so that we'll be
>> able to build our first samples of the plugin.
>>
>> The idea is to have a customizable Bug Dashboard for each project using Forrest.
>> The Bug Dashboard consists of an arbitrary number of widgets, each of them
>> associated
>> with a specific search filter (content aggregation). What's more, Bug Widgets can
>> communicate with the XML web server asynchronously (AJAX) to respond to user's
>> requests for information. A simple and small, yet useful web-app, that is.
> 
> I'd focus on manipulating the Baetle docs rather than the extraction
> of data from Jira. Create some sample docs to use in the plugin,
> otherwise you are likely to find yourself waiting for the JIRA
> integration which we should not be looking at in any detail within
> Forrest.
> 
> I'd also caution against trying to create a fully functional "bug
> dashboard". A projects chosen issue tracker should be doing that. What
> I think would be useful for a Baetle plugin would be to have a bunch
> of dispatcher contracts that allow us to embed select information
> within another page. For example, suppose we had a critical security
> issue in the webapp version of Forrest. We could drop a contract
> indicating the current status of the bug fix onto our home page.
> Another use case might be a "most popular" issues page in which we
> display the top five issues with respect to votes and invite people to
> visit the issue tracker to add their own votes to key issues.
> 
> Looking further forward it might be interesting to expose the Baetle
> data as a JSON file. This will allow us to use tools such as Exhibit
> to provide the "Bug Dashboard" you describe. As it happens, I recently
> committed some code to the DOAP plugin that does this with our DOAP
> catalogue data. This could almost certainly be leveraged in your work
> if you want to give it a go.
> 
> I'm sure you have some use case ideas as well, you can bring in any
> idea you like.
> 
> So, I'd suggest working along the following lines, don't feel
> constrained by this though, feel free to jump into whatever interests
> you, or to modify this with any other ideas that might come from the
> communty:
> 
> - learn the dispatcher (probably by making your SKOS plugin dispatcher aware)
> - create a basic Baetle plugin that can produce our "top 25 issues" page
> - create a dispatcher contract that does our "top 25 issues" content
> - extend the dispatcher contract to allow it to be customised (top 5
> issues, displayed data etc.)
> - samples, samples, samples
> - produce JSON
> - embed Exhibit
> 
> This sounds like a really cool plugin and is the one I was really
> looking forward to seeing.
> 
> Ross
> 



Mime
View raw message