Re: [Mailman-Developers] [GSoC 2012] Metrics
On Thu, May 3, 2012 at 8:04 AM, George Chatzisofroniou email@example.com wrote:
I’m also thinking to rearrange the GSoC schedule a bit. I’ll start writing code on the bonding period,
It's up to your coding mentors, but it's generally not a good idea to try to move up the coding stage by too much. Make sure you have a clear spec before you start coding anything, and at least a rough sketch of a design. Without those two pieces, there's no standard to evaluate progress, or whether your code is doing the right thing.
As wacky mentioned i'm not planning to skip any step of the process. The idea is to press myself a bit more now, so i can have some more time to study later. I should have explained myself better.
so i can have more time during my university’s exams (starting on half of June).
I'd say just take the time as needed, after negotiating with your mentors.
The Django app should handle some configuration parameters, like:
- Maximum number of the subscribers of a mailing list the user wants
to be shown in the charts
I don't know how feasible it would be to implement, but if you're willing to use AJAX, you could simply build up bar and line charts on the fly, adding "slices" of say 5 users at a time on the right side of the chart in progress. That might be cool. It could be set in a "viewport" and scrolled if it gets too big for the viewport.
- Month – This model will store total posts and threads for each month
- Year – Similar to month model, this one will store total posts and
threads for each year
It's not clear to me why year views can't be generated as an aggregate of monthly data? This would allow years to start with arbitrary months without too much redundancy.
Generating the year views from monthly data is some more calculations while displaying the metrics. That's why they should be stored somewhere.
Interface to the MM core
The app needs to interact with the Mailman core. I think the best idea is to implement a message bus that will send a notification every time a message is sent (the same way an archiver works).
Why not just use the iArchiver interface?
I think it should be possible to have this be a standalone app serving the list itself, or be hosted by a particular archive, which wouldn't need to be the list host (or even run by the same organization).
Yes, i agree. The iArchiver should be the origin of the interface.
Thank you for your feedback,