[p2pu-dev] P2PU API

Wed Jun 1 06:55:15 UTC 2011

Karen Fasimpaur just started a wiki page thinking about analytics, and there
is this etherpad we started a few weeks ago (http://pad.p2pu.org/metrics). I
think there is some overlap with the reporting API notes below, and would
love to see these things come together.

http://wiki.p2pu.org/w/page/40734477/analytics-v1

On privacy: Our lawyer at Wilson Sonsini explained that even if information
could be scraped off the site, and even if we state that all content is
public, there are certain legal contraints which limit how much data we can
publish. But besides the legal implications, he felt the "soft" issues
around privacy were equally important for a project like P2PU that has a
strong community component. He warned that users might hold a
misc-conception about their privacy (this is something we are seeing already
- people are sending requests to delete their accounts, because they show up
in google searches) and the fall-out from users feeling we are invading
their privacy. He basically said that this is an area of high risk for an
organization and we should be very cautious. We didn't get into the details
of what data exactly we could make available, but I remember that he was
very opposed to sharing any information that could be tracked back to the
actions of an individual user.

To be honest, this is a huge can of worms and will take a lot of time/effort
to get through. I think a good start would be to (1) figure out what
analytics we need internally - and then start tracking those, and (2) share
regular reports of aggregate data.

And (3) move forward on the extension API if we feel we can support it
through the community. We don't currently have any budget earmarked for an
API - so it would take some time to raise the funds to pay someone to work
on this.

- P

On 1 June 2011 06:03, Jessy Kate Schingler <jessy at jessykate.com> wrote:

> alright, trying to push on both ideas a bit more:
> *
> *
> *extension api*
> for an extension api, we could look into starting with the ability for *
> existing* accounts to interact with *existing* courses. so focus on
> enabling contribution of content, rather than exposing settings and
> administrative tasks. folks who have been active on lernanta probably can
> flesh this out better than me, but as an initial thought, this would be a
> pretty simple set of API calls right now:
>
> (sg == study group)
>
> sg_follow
> sg_post_message
> sg_create_task
> sg_edit task
> sg_comment_task
> sg_comment_task_reply
>
> profile_post_message
>
> person_follow
> person_message
>
> this is a small set of api items (am i missing stuff?) but i think the
> bigger challenge would be maintenance and support... are we ready for that?
>
> * reporting api: *
> we could start by returning only information from queries which have > a
> certain number of results, but this doesn't stop people from combining
> queries in ways that expose additional information. i think there's a fair
> argument here that whatever is already public on the site is fair game for a
> reporting api.
>
> courses_total
> courses_per_school
> participants_total
> participants_in_course
> people_following
> courses_following
> person_comments_text
> (what else am i missing?)
>
> IMHO here's where it gets more interesting, if we can track, compare and
> contrast things like (very rough):
>
> number of times a study group page was visited by a given person
> number of times they commented (already public)
> most frequent words (already public)
> most "successful" (definition?!)/unsuccessful study groups and ...
>  - # of participants,
>  - frequency of participation (per person, and overall),
>  - average delta response time between comments,
>  - average number of posts total/per task/per person,
>  - avg. # of other courses being taken by participants,
>  - the "spread" of participation over multiple courses by participants who
> take multiple courses,
>  - participation and time zone/average participant time zone...
> courses and badges...
> study groups and... breakfast choice?! phase of the moon?!
>
> obviously tons we could do here. this is trickier to do "right" (and with
> privacy), but we could design queries which give back statistical
> information about correlations, rather than individual behaviour. that would
> be suuuper cool from a science perspective.
>
> i think we have all this data except for page views, which i'm not even
> sure we can track on a per-user level without getting pretty invasive.
> however, most of the rest is based on available data. a slightly different
> take on this kind of reporting statistics might be not as an API but as a
> (daily/weekly/whatever) automated data report, which people can consume as
> they wish. this would obviously simplify care and feeding, though it would
> reduce customizability (filters etc.).
>
> we could flesh some of these things out on an etherpad/wiki page in more
> detail if we want to get more specific.
>
> thoughts?
>
> Jessy
> --
> http://jessykate.com
>
>
>
> On Tue, May 31, 2011 at 12:18 PM, Hemanth H.M <hemanth.hm at gmail.com>wrote:
>
>> Hello All,
>> I had created a course called  paws on web apis<http://new.p2pu.org/en/groups/paws-on-web-apis/>will is still under development, as of now the subject is very general,
>> would be happy to involve more and contribute towards making an API for the
>> P2PU.  Please guide me through in making a proper plan. Thank you all.
>>
>>
>> On Tue, May 31, 2011 at 8:44 PM, John Britton <public at johndbritton.com>wrote:
>>
>>> I'd love to have a clear understanding of what we're doing about data
>>> privacy. Ideally we should be telling people that anything they submit (save
>>> for passwords,  billing info, or anything else we promise not to share) will
>>> be publicly accessible. The default state for data submitted to the site is
>>> pubilc.
>>>
>>> --
>>> contact info:
>>> http://www.johndbritton.com
>>> @johndbritton - http://twitter.com/johndbritton
>>>
>>>
>>> On Tue, May 31, 2011 at 4:16 AM, Philipp Schmidt <phi.schmidt at gmail.com>wrote:
>>>
>>>> On 31 May 2011 06:01, Jessy Kate Schingler <jessy at jessykate.com> wrote:
>>>>
>>>>> i agree with stian;s characterization. let's call the statistics stuff
>>>>> a reporting API, and the other an extension API (as in, people could use it
>>>>> to extend the ways people interact with p2pu).
>>>>>
>>>>
>>>> this is a good distinction. i know that our lawyers have serious
>>>> concerns about anything that exposes user data (even in semi-aggregate form,
>>>> and even if the same data could be scraped from the site) which affects the
>>>> reporting API. however, metrics are an in-house priority so even if we can't
>>>> easily make this data available through an API, we will have much better
>>>> reporting / tracking / status information in the near future.
>>>>
>>>> i'd love to push on the idea of the extension API, because that seems an
>>>> opportunity to build additional features and ways to learn for our users,
>>>> and connect P2PU to other sites/platforms/services.
>>>>
>>>> -- P
>>>>
>>>>
>>>> _______________________________________________
>>>> p2pu-dev mailing list
>>>> p2pu-dev at lists.p2pu.org
>>>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> p2pu-dev mailing list
>>> p2pu-dev at lists.p2pu.org
>>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>>
>>>
>>
>>
>> --
>> *'I am what I am because of who we all are'*
>> h3manth.com <http://www.h3manth.com>
>> *-- Hemanth HM *
>>
>> _______________________________________________
>> p2pu-dev mailing list
>> p2pu-dev at lists.p2pu.org
>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>
>>
>
> _______________________________________________
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org
> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20110601/1e22bea9/attachment-0001.html>