You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alexei Fedotov <al...@gmail.com> on 2013/06/10 10:05:41 UTC
Re: Error collecting infrastructure for Openmeetings
[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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Answering a personal request on general@ usage:
1) we discovered from our internal discussions that the topic is sensitive
and want to be transparent with our intentions to collect user data;
2) we want to know more about Apache ways of addressing the problem;
3) we have not got any answer from legal@ and infra@ in this thread, thus I
believe this may be more a cultural issue than a legal or technical issue;
the incubator is a culture-spreading entity;
4) finally addressing general@ may be my mistake.
I still will be grateful if anyone shares their experience on best
practices on how to collect user errors to improve product quality.
10.06.2013 12:05 пользователь "Alexei Fedotov" <al...@gmail.com>
написал:
> [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: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Answering a personal request on general@ usage:
1) we discovered from our internal discussions that the topic is sensitive
and want to be transparent with our intentions to collect user data;
2) we want to know more about Apache ways of addressing the problem;
3) we have not got any answer from legal@ and infra@ in this thread, thus I
believe this may be more a cultural issue than a legal or technical issue;
the incubator is a culture-spreading entity;
4) finally addressing general@ may be my mistake.
I still will be grateful if anyone shares their experience on best
practices on how to collect user errors to improve product quality.
10.06.2013 12:05 пользователь "Alexei Fedotov" <al...@gmail.com>
написал:
> [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: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Sebastian,
I believe as for now, the decision is *not to include* the code into
release. I opposed this initially, yet it seems I have to step down
here. There were no strong support for this from anyone other then me.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 3:16 AM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> *AFAIK,
> many Apache projects do use Google Analytics already.*
> => The next question will be: Which projects do you Google Analytics?
>
> I doubt that any Apache product includes a UA code in its release packages.
>
> Sebastian
>
>
> 2013/6/10 Alexei Fedotov <al...@gmail.com>
>
>> [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
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Sebastian,
I believe as for now, the decision is *not to include* the code into
release. I opposed this initially, yet it seems I have to step down
here. There were no strong support for this from anyone other then me.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 3:16 AM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> *AFAIK,
> many Apache projects do use Google Analytics already.*
> => The next question will be: Which projects do you Google Analytics?
>
> I doubt that any Apache product includes a UA code in its release packages.
>
> Sebastian
>
>
> 2013/6/10 Alexei Fedotov <al...@gmail.com>
>
>> [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
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Sebastian,
I believe as for now, the decision is *not to include* the code into
release. I opposed this initially, yet it seems I have to step down
here. There were no strong support for this from anyone other then me.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 3:16 AM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> *AFAIK,
> many Apache projects do use Google Analytics already.*
> => The next question will be: Which projects do you Google Analytics?
>
> I doubt that any Apache product includes a UA code in its release packages.
>
> Sebastian
>
>
> 2013/6/10 Alexei Fedotov <al...@gmail.com>
>
>> [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
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
Re: Error collecting infrastructure for Openmeetings
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
*AFAIK,
many Apache projects do use Google Analytics already.*
=> The next question will be: Which projects do you Google Analytics?
I doubt that any Apache product includes a UA code in its release packages.
Sebastian
2013/6/10 Alexei Fedotov <al...@gmail.com>
> [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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Error collecting infrastructure for Openmeetings
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
*AFAIK,
many Apache projects do use Google Analytics already.*
=> The next question will be: Which projects do you Google Analytics?
I doubt that any Apache product includes a UA code in its release packages.
Sebastian
2013/6/10 Alexei Fedotov <al...@gmail.com>
> [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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Error collecting infrastructure for Openmeetings
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
*AFAIK,
many Apache projects do use Google Analytics already.*
=> The next question will be: Which projects do you Google Analytics?
I doubt that any Apache product includes a UA code in its release packages.
Sebastian
2013/6/10 Alexei Fedotov <al...@gmail.com>
> [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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Error collecting infrastructure for Openmeetings
Posted by Alexei Fedotov <al...@gmail.com>.
Answering a personal request on general@ usage:
1) we discovered from our internal discussions that the topic is sensitive
and want to be transparent with our intentions to collect user data;
2) we want to know more about Apache ways of addressing the problem;
3) we have not got any answer from legal@ and infra@ in this thread, thus I
believe this may be more a cultural issue than a legal or technical issue;
the incubator is a culture-spreading entity;
4) finally addressing general@ may be my mistake.
I still will be grateful if anyone shares their experience on best
practices on how to collect user errors to improve product quality.
10.06.2013 12:05 пользователь "Alexei Fedotov" <al...@gmail.com>
написал:
> [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
>