[Rivet] List of Rivet routines

[Andy Buckley]

Jonathan Butterworth wrote:
> Hum.
> 
> Using the ticketing system was my idea. This is supposed to be a sort of
> to do list (at least in my understanding) so the ticketing seemed to be
> appropriate. They can reported as tasks rather than bugs, and there are
> then email notifications for people interested (can add themselves to
> the cc field) in a given routine etc. Plus we can use prioritisation,
> assign them to milestones/release etc etc.
> 
> For user documentation of analyses, I think doxygen comments should be
> used. I'd resist having a wiki page too, too many sources of
> (potentially inconsistent) info to maintain.

Yes, I agree with that: synchronisation is best done by keeping documentation
close to the code. Actually, I think we should put a lot more metadata in the
analysis classes themselves. For example, a nice feature would be for each
analysis to have a "long description" or comment field, in which all current
issues, generator settings etc. are described, which could then be queried on
the rivetgun command line or via the API.

I would prefer to have this than either a set of always-open tickets or
outdated wiki pages.

> I was thinking a component like Emily suggests would be good, then we
> can set up a DB query which gives all analyses in progress or requested,
> with people assigned to them (if any) and progress/priority. And once
> they are written, the ticket could just refer people to the doxygen page.
> 
> Does that make you happier Andy?

Okay, I'll be open minded for once and see how it pans out!

It might be nicer to keep them separate from normal tickets and exclude them
from normal views, but to refer to active tickets that affect those analyses.
Otherwise we'll never get to close analysis tickets - just move them, which is
a bit artificial - and the tickets will become long and full of expired
information.

I think another more substantial thing that would be very useful would be
periodically-generated plots from all Rivet analyses, available from the Web.
But that a) requires a lot of CPU and b) is replicating a lot of JetWeb
functionality (has anything happened on JetWeb, by the way?) Any comments?

Andy