You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Alexei Fedotov <al...@gmail.com> on 2013/06/11 18:19:34 UTC
[local dev talk] Error collecting infrastructure for Openmeetings
[changing aliases once again - reducing them to dev@]
Hello, OM folks,
So generally what we have achieved with our request is
1) either there is no or little general interest at Apache to our
intention to collect user data,
2) or there are great flame battles somewhere on private lists we don't yet see.
I don't really think 2) is the case, and I believe we may continue
assuming 1) is true. That makes us on the safe side from being not
transparent enough with our project development. Maybe I'm paranoid a
bit, anyway.
I have seen that Maxim and Artyom has already achieved a consensus,
and it is aligned to what Sebastian has said. So there is one new
thing we have not yet discussed, the idea by Sebastian that we should
collect data here at Apache instead of Google Analytics with some form
of CGI or other script.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Mon, Jun 10, 2013 at 12:05 PM, Alexei Fedotov
<al...@gmail.com> wrote:
> [added general@ for vivid discussion]
>
> Hello Sebastian,
>
> I'm glad that the statement that this infrastructure is needed is not
> questioned.
>
> We technically can use either CGI script, or existing Confluence API.
> The intention for using Google Analytics is minimum effort. AFAIK,
> many Apache projects do use Google Analytics already.
>
> The goal for the request is to avoid inventing a project-wide policy
> where foundation-wide policy is needed.
>
> With best regards, Alexei
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Mon, Jun 10, 2013 at 7:03 AM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
>> Hi Alexei,
>>
>> what about a simple CGI script that takes the input and send an email to the
>> mailing list?
>> I think some more simple approach would do the same and does not have such a
>> deep impact on the whole infrastructure. Some legal and privacy aspects are
>> still tbc.
>>
>> However no matter what we do it is unlikely that including the actual UA
>> code or any kind of real pwd / hash in a release is a good idea. It is quite
>> easy to manipulate that.
>>
>> Also the question rises if the OpenMeetings server is in a public network at
>> all. Just sending request blindly without knowing if they ever reach their
>> destination is kind of odd.
>>
>> It should be some subscribe mechanism where an OpenMeetings admin can
>> activate the error collecting. The activation could then subscribe and load
>> a hash that will auth that server for error collecting.
>>
>> If you put that activation in the installer with appropriate explenations I
>> think it has better chances to find a wider positive reaction in devs and
>> users.
>>
>> Maybe it would be enough to give some kind of more general feedback from
>> @legal and @infra and we can then in the OpenMeetings PMC create a more
>> detailed spec of that component.
>>
>> @legal: Do you have general constraints regarding error collecting ?
>>
>> @infra: What kind of advices can you give us? I guess some CGI scripts are
>> not that big deal. Is there any process who would review and activate / make
>> them executable?
>>
>> Thanks,
>> Sebastian
>>
>> Am 06.06.2013 19:38 schrieb "Alexei Fedotov" <al...@gmail.com>:
>>
>>> [added Shane for reputation issues]
>>>
>>> Hello, Infra and Legal folks,
>>>
>>> We ask you for advice on the automated error collection
>>> infrastructure. Any helpful ideas are appreciated.
>>>
>>> 1. Our users are tainted with iphones and other reliable and fancy
>>> staff. They start wanting openmeetings to work reliably. This makes us
>>> think of a global error collecting infrastructure to plan important
>>> bug fixes. Here is an example by Firefox [1].
>>>
>>> We believe collecting user errors is generally ok if proper
>>> preparations are made. Is it generally possible to implement error
>>> collecting infrastructure as a part of Apache project? If not, we can
>>> try to do it as a commercial company, yet Firefox example shows a
>>> non-commercial org can be behind that error collection.
>>>
>>> 2. Could we use Google Analytics to store collected errors? The
>>> general Apache practice is to use Apache infrastructure. Google
>>> Analytics allows us storing 50 mln. events for free. The comparable
>>> thing won't be free for Apache for sure.
>>>
>>> Once can use JIRA, or Confluence via API, this will be a heavy load.
>>> Are you ok with using third party for storing error & environment
>>> messages and associated risks?
>>>
>>> The code we are talking about is below:
>>> try {
>>> _gaq = _gaq || [];
>>> _gaq.push(['_setAccount', 'UA-13024987-1']); // PMC id
>>> _gaq.push(['_trackPageview']);
>>> _gaq.push(['_trackEvent', 'Openmeetings client error',
>>> message, '', 0, true]);
>>> } catch (exception) {
>>> alert(exception);
>>> }
>>>
>>> 3. Is it ok for PMC to share Google Analytics id? Should we use some
>>> Apache Id instead?
>>>
>>> 4. Which preparations should be done to start this error collection
>>> service in the next release?
>>>
>>> 4.1. Is it ok just to semi-silently mention in release notes, that
>>> errors are automatically sent to the (Google) server right now?
>>> 4.2. Or should we explicitly notify each new user that the errors are
>>> now to be collected?
>>> 4.3. If 4.2. holds, can we ask once per user at the beginning of his
>>> session and remember if he agreed sharing error reports? Or should we
>>> allow a user to review each error report each time the error is sent
>>> (I expect 5-10 errors per standard openmeetings session)? Can we have
>>> a checkbox "Remember my choice" or a button "Send error reports
>>> always" for those, who are tied of error messages?
>>>
>>> [1]
>>> https://crash-stats.mozilla.com/report/index/050f1aab-1507-4c8f-a166-9b3322130422
>>>
>>> --
>>> With best regards / с наилучшими пожеланиями,
>>> Alexei Fedotov / Алексей Федотов,
>>> http://dataved.ru/
>>> +7 916 562 8095
Re: [local dev talk] Error collecting infrastructure for Openmeetings
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Sorry but what was the consens of Artyom and Maxim?
As far as I know the UA / Google analytics code is gone. Maxim has reverted
the commit.
So the current status is:
There is no such error collecting mechanism, neither Google Analytics nor
anything else.
There is a button on top right: Report error, that opens a new browser on
Jira.
What I would like to know now is:
What does this automated ping back to an error infrastructure collect at
all? What page will trigger this error collection?
As far as I know there is no general error page in OpenMeetings. In Wicket
we heavily use Ajax calls. There is almost no use case where the user would
be redirected to an error 500 page, as the result of an invalid Ajax
request is just an internal error that you could only see in Firebug or
comparable Developer tools. Or is there anything Wicket specific that does
collect that?
And in the Flash version I see no concrete use case that would send this
ping back either.
So what is the mechanism that triggers this error collection, when exactly
will there be a report send to Google Analytics (or whatever we will be
using)?
Thanks,
Sebastian
2013/6/12 Alexei Fedotov <al...@gmail.com>
> [changing aliases once again - reducing them to dev@]
>
> Hello, OM folks,
>
> So generally what we have achieved with our request is
> 1) either there is no or little general interest at Apache to our
> intention to collect user data,
> 2) or there are great flame battles somewhere on private lists we don't
> yet see.
>
> I don't really think 2) is the case, and I believe we may continue
> assuming 1) is true. That makes us on the safe side from being not
> transparent enough with our project development. Maybe I'm paranoid a
> bit, anyway.
>
> I have seen that Maxim and Artyom has already achieved a consensus,
> and it is aligned to what Sebastian has said. So there is one new
> thing we have not yet discussed, the idea by Sebastian that we should
> collect data here at Apache instead of Google Analytics with some form
> of CGI or other script.
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Mon, Jun 10, 2013 at 12:05 PM, Alexei Fedotov
> <al...@gmail.com> wrote:
> > [added general@ for vivid discussion]
> >
> > Hello Sebastian,
> >
> > I'm glad that the statement that this infrastructure is needed is not
> > questioned.
> >
> > We technically can use either CGI script, or existing Confluence API.
> > The intention for using Google Analytics is minimum effort. AFAIK,
> > many Apache projects do use Google Analytics already.
> >
> > The goal for the request is to avoid inventing a project-wide policy
> > where foundation-wide policy is needed.
> >
> > With best regards, Alexei
> >
> > --
> > With best regards / с наилучшими пожеланиями,
> > Alexei Fedotov / Алексей Федотов,
> > http://dataved.ru/
> > +7 916 562 8095
> >
> >
> > On Mon, Jun 10, 2013 at 7:03 AM, seba.wagner@gmail.com
> > <se...@gmail.com> wrote:
> >> Hi Alexei,
> >>
> >> what about a simple CGI script that takes the input and send an email
> to the
> >> mailing list?
> >> I think some more simple approach would do the same and does not have
> such a
> >> deep impact on the whole infrastructure. Some legal and privacy aspects
> are
> >> still tbc.
> >>
> >> However no matter what we do it is unlikely that including the actual UA
> >> code or any kind of real pwd / hash in a release is a good idea. It is
> quite
> >> easy to manipulate that.
> >>
> >> Also the question rises if the OpenMeetings server is in a public
> network at
> >> all. Just sending request blindly without knowing if they ever reach
> their
> >> destination is kind of odd.
> >>
> >> It should be some subscribe mechanism where an OpenMeetings admin can
> >> activate the error collecting. The activation could then subscribe and
> load
> >> a hash that will auth that server for error collecting.
> >>
> >> If you put that activation in the installer with appropriate
> explenations I
> >> think it has better chances to find a wider positive reaction in devs
> and
> >> users.
> >>
> >> Maybe it would be enough to give some kind of more general feedback from
> >> @legal and @infra and we can then in the OpenMeetings PMC create a more
> >> detailed spec of that component.
> >>
> >> @legal: Do you have general constraints regarding error collecting ?
> >>
> >> @infra: What kind of advices can you give us? I guess some CGI scripts
> are
> >> not that big deal. Is there any process who would review and activate /
> make
> >> them executable?
> >>
> >> Thanks,
> >> Sebastian
> >>
> >> Am 06.06.2013 19:38 schrieb "Alexei Fedotov" <alexei.fedotov@gmail.com
> >:
> >>
> >>> [added Shane for reputation issues]
> >>>
> >>> Hello, Infra and Legal folks,
> >>>
> >>> We ask you for advice on the automated error collection
> >>> infrastructure. Any helpful ideas are appreciated.
> >>>
> >>> 1. Our users are tainted with iphones and other reliable and fancy
> >>> staff. They start wanting openmeetings to work reliably. This makes us
> >>> think of a global error collecting infrastructure to plan important
> >>> bug fixes. Here is an example by Firefox [1].
> >>>
> >>> We believe collecting user errors is generally ok if proper
> >>> preparations are made. Is it generally possible to implement error
> >>> collecting infrastructure as a part of Apache project? If not, we can
> >>> try to do it as a commercial company, yet Firefox example shows a
> >>> non-commercial org can be behind that error collection.
> >>>
> >>> 2. Could we use Google Analytics to store collected errors? The
> >>> general Apache practice is to use Apache infrastructure. Google
> >>> Analytics allows us storing 50 mln. events for free. The comparable
> >>> thing won't be free for Apache for sure.
> >>>
> >>> Once can use JIRA, or Confluence via API, this will be a heavy load.
> >>> Are you ok with using third party for storing error & environment
> >>> messages and associated risks?
> >>>
> >>> The code we are talking about is below:
> >>> try {
> >>> _gaq = _gaq || [];
> >>> _gaq.push(['_setAccount', 'UA-13024987-1']); // PMC id
> >>> _gaq.push(['_trackPageview']);
> >>> _gaq.push(['_trackEvent', 'Openmeetings client error',
> >>> message, '', 0, true]);
> >>> } catch (exception) {
> >>> alert(exception);
> >>> }
> >>>
> >>> 3. Is it ok for PMC to share Google Analytics id? Should we use some
> >>> Apache Id instead?
> >>>
> >>> 4. Which preparations should be done to start this error collection
> >>> service in the next release?
> >>>
> >>> 4.1. Is it ok just to semi-silently mention in release notes, that
> >>> errors are automatically sent to the (Google) server right now?
> >>> 4.2. Or should we explicitly notify each new user that the errors are
> >>> now to be collected?
> >>> 4.3. If 4.2. holds, can we ask once per user at the beginning of his
> >>> session and remember if he agreed sharing error reports? Or should we
> >>> allow a user to review each error report each time the error is sent
> >>> (I expect 5-10 errors per standard openmeetings session)? Can we have
> >>> a checkbox "Remember my choice" or a button "Send error reports
> >>> always" for those, who are tied of error messages?
> >>>
> >>> [1]
> >>>
> https://crash-stats.mozilla.com/report/index/050f1aab-1507-4c8f-a166-9b3322130422
> >>>
> >>> --
> >>> With best regards / с наилучшими пожеланиями,
> >>> Alexei Fedotov / Алексей Федотов,
> >>> http://dataved.ru/
> >>> +7 916 562 8095
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com