[GSoC] Automated Usage Stats Collection

[Rishi Agarwal]

Hi Mark

Thanks for your interest in my application. I would like to answer your
queries as follows:

1. Regarding restrictions, I have following examples in my mind:
(a) No direct access to user's and his contacts' mail ids. If at all, a
plugin requires to collect these stats (let's say a plugin which collects
the level of participation in a group chat), actual ids will be substituted
with dummy markers.
(b) Limited access to chat conversations and keyboard. Actual chat
conversations can't be logged and only keyboard commands (like Alt +F4) can
be logged. This is basically to facilitate debugging while not compromising
on privacy.

The crash reports that I am targeting are mainly from the plugins' crashes.
Also, why I thought grouping of crash reports and filing under the same
ticket will be required is because multiple user's will have same sort of
crashes in a single plugin. Grouping will make it easy for the developer to
prioritize the issues which need to be fixed.

Regarding the account management point, I agree with you that maintaining a
separate account for every developer will be a bit cumbersome. I was
thinking of public-private key approach to do this, where a plugin
developer will share the public key with the logging framework and will use
the private key to access the logs. The reason I included this was so that
the developer can easily track issues related to his/her own plugin. A
simpler solution will be to keep the logs sorted according to the plugin on
the site.

I am more interested in providing the logging API rather than usage data
collection part of the project as I think this would be a great value add
to the Pidgin Universe. I'd be happy to provide more clarifications if
needed.

Thanks
Rishi

On Sun, Apr 1, 2012 at 2:31 AM, Mark Doliner <mark at kingant.net> wrote:

> On Fri, Mar 30, 2012 at 11:47 AM, Rishi Agarwal <rishiag.iitd at gmail.com>
> wrote:
> > The basic idea is to provide a logging interface to plugin
> > developers which they can use in their code for monitoring purposes (with
> > proper restrictions to protect user privacy).
>
> What sort of restrictions did you have in mind?
>
> > 3. Add support for crash reports. Maybe, try to file them under already
> open
> > tickets.
>
> I think crash collection and reporting would be fairly independent
> from usage stat collection and reporting.  It's not clear to me if it
> makes sense to lump them together in a single summer of code project.
>
> Also I don't think it's a good idea for crash reports to be tied to
> already open tickets.  I think this would be difficult to implement,
> possibly fragile, and susceptible to false positives.  It doesn't seem
> worth the effort.
>
> > 4. Website to display the stats. Also, every plugin developer can have a
> > separate account on this to view his/her plugin's logs.
>
> I wonder if it's really necessary to need an account to view this
> information?  If the information really is anonymous then I feel like
> it should be safe to make it public.  I see difficulties with trying
> to keep the information semi-private, or visible only to the plugin
> author (how would you enforce that the registered user is the plugin
> author?  what would stop the plugin author from resharing the
> information or sharing his account?).  Plus, account management is
> inconvenient--why require an account if there's no reason for it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120401/aee1806e/attachment-0002.html>