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/06 11:30:34 UTC
Error collecting infrastructure for Openmeetings
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>.
Shane, thank you for commenting. This really helps.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 10:46 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> (Bcc: privately-archived trademarks@ for brand awareness)
>
> I'm not familiar enough with OpenMeeting's functionality and intended use of
> this to make specific comments. However I can offer some general principles
> to consider.
>
> - If an Apache project PMC has a specific and clear need for assistance in
> dealing with legal, infra, or brand issues, then the appropriate ASF groups
> will figure out how to help. The question here is: what is the *specific*
> need that the PMC as a whole has addressed, and what legal/organizational
> issue(s) is blocking them from moving forward?
>
> This thread is certainly interesting for the discussion, but it's not
> specific enough for many of us to really help yet.
>
> - Any use of Google Analytics or other such user data capture systems must
> both comply with their terms of use, as well as comply with the ASF's
> branding requirements. In particular, use of Google Analytics requires
> posting a clear terms of service, etc. where the users will see it, etc.
>
> Also, as a public charity that relies on communities of volunteers (like
> yourself!) who do the work of our projects, we need to be sensitive to
> privacy issues of our users. It's fine to use a program like this, as long
> as we follow the rules, and give people an appropriate way to opt out.
> Separately, we should not give the impression that the ASF or any Apache
> project specifically endorses or requires such an outside service for our
> core functionality of our products.
>
> - Fundamentally, any Apache project's source code and releases must be on
> Apache controlled services/hardware. Apache project mailing lists and
> primary homepage websites really should also be on Apache hardware, although
> it's possible to host those elsewhere if there's a really good reason.
> Similarly, end users must be able to use the primary functionality of an
> Apache project by getting all they need from that Apache project's homepage.
>
> Optional features or systems can be run elsewhere, so from that point of
> view Google Analytics (or the like) could be an OK solution.
>
> - Personally, I'm not sure how shipping GA code in Apache OpenMeetings
> works, so I can't comment much on that. I would definitely post a clear
> notice about it, and ensure that end users understand how to turn it off or
> the like if they're concerned about privacy.
>
> - In terms of sharing login details to such third party services like GA,
> the best practice is first of all to keep the credentials secure. If this is
> a service that the PMC as a whole wants to use or needs to improve the
> project, then you should be sure to share the credentials with at least
> three separate PMC members, and make it clear that you intend to use this
> for the PMC, and not just as individuals.
>
> There have been cases in the past where similar credentials were created by
> individuals, used by projects, and then the individuals moved elsewhere...
> without passing the credentials to anyone else - hence the sharing within
> other individual PMC members.
>
> I hope that helps from the branding and best practices side.
>
> - Shane
>
> P.S. Re: 4.2 and 4.3, I would definitely recommend having a very clear
> notice that such error collection is being done in any new builds. But you
> can certainly (from my perspective, at least) just ask the user once per
> session or per new version install, etc. - no need to do it every single
> connection or whatever.
>
>
> On 6/6/2013 5:37 AM, Alexei Fedotov wrote:
>>
>> [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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
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>.
Shane, thank you for commenting. This really helps.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 10:46 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> (Bcc: privately-archived trademarks@ for brand awareness)
>
> I'm not familiar enough with OpenMeeting's functionality and intended use of
> this to make specific comments. However I can offer some general principles
> to consider.
>
> - If an Apache project PMC has a specific and clear need for assistance in
> dealing with legal, infra, or brand issues, then the appropriate ASF groups
> will figure out how to help. The question here is: what is the *specific*
> need that the PMC as a whole has addressed, and what legal/organizational
> issue(s) is blocking them from moving forward?
>
> This thread is certainly interesting for the discussion, but it's not
> specific enough for many of us to really help yet.
>
> - Any use of Google Analytics or other such user data capture systems must
> both comply with their terms of use, as well as comply with the ASF's
> branding requirements. In particular, use of Google Analytics requires
> posting a clear terms of service, etc. where the users will see it, etc.
>
> Also, as a public charity that relies on communities of volunteers (like
> yourself!) who do the work of our projects, we need to be sensitive to
> privacy issues of our users. It's fine to use a program like this, as long
> as we follow the rules, and give people an appropriate way to opt out.
> Separately, we should not give the impression that the ASF or any Apache
> project specifically endorses or requires such an outside service for our
> core functionality of our products.
>
> - Fundamentally, any Apache project's source code and releases must be on
> Apache controlled services/hardware. Apache project mailing lists and
> primary homepage websites really should also be on Apache hardware, although
> it's possible to host those elsewhere if there's a really good reason.
> Similarly, end users must be able to use the primary functionality of an
> Apache project by getting all they need from that Apache project's homepage.
>
> Optional features or systems can be run elsewhere, so from that point of
> view Google Analytics (or the like) could be an OK solution.
>
> - Personally, I'm not sure how shipping GA code in Apache OpenMeetings
> works, so I can't comment much on that. I would definitely post a clear
> notice about it, and ensure that end users understand how to turn it off or
> the like if they're concerned about privacy.
>
> - In terms of sharing login details to such third party services like GA,
> the best practice is first of all to keep the credentials secure. If this is
> a service that the PMC as a whole wants to use or needs to improve the
> project, then you should be sure to share the credentials with at least
> three separate PMC members, and make it clear that you intend to use this
> for the PMC, and not just as individuals.
>
> There have been cases in the past where similar credentials were created by
> individuals, used by projects, and then the individuals moved elsewhere...
> without passing the credentials to anyone else - hence the sharing within
> other individual PMC members.
>
> I hope that helps from the branding and best practices side.
>
> - Shane
>
> P.S. Re: 4.2 and 4.3, I would definitely recommend having a very clear
> notice that such error collection is being done in any new builds. But you
> can certainly (from my perspective, at least) just ask the user once per
> session or per new version install, etc. - no need to do it every single
> connection or whatever.
>
>
> On 6/6/2013 5:37 AM, Alexei Fedotov wrote:
>>
>> [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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> 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 Shane Curcuru <as...@shanecurcuru.org>.
(Bcc: privately-archived trademarks@ for brand awareness)
I'm not familiar enough with OpenMeeting's functionality and intended
use of this to make specific comments. However I can offer some general
principles to consider.
- If an Apache project PMC has a specific and clear need for assistance
in dealing with legal, infra, or brand issues, then the appropriate ASF
groups will figure out how to help. The question here is: what is the
*specific* need that the PMC as a whole has addressed, and what
legal/organizational issue(s) is blocking them from moving forward?
This thread is certainly interesting for the discussion, but it's not
specific enough for many of us to really help yet.
- Any use of Google Analytics or other such user data capture systems
must both comply with their terms of use, as well as comply with the
ASF's branding requirements. In particular, use of Google Analytics
requires posting a clear terms of service, etc. where the users will see
it, etc.
Also, as a public charity that relies on communities of volunteers (like
yourself!) who do the work of our projects, we need to be sensitive to
privacy issues of our users. It's fine to use a program like this, as
long as we follow the rules, and give people an appropriate way to opt
out. Separately, we should not give the impression that the ASF or any
Apache project specifically endorses or requires such an outside service
for our core functionality of our products.
- Fundamentally, any Apache project's source code and releases must be
on Apache controlled services/hardware. Apache project mailing lists
and primary homepage websites really should also be on Apache hardware,
although it's possible to host those elsewhere if there's a really good
reason. Similarly, end users must be able to use the primary
functionality of an Apache project by getting all they need from that
Apache project's homepage.
Optional features or systems can be run elsewhere, so from that point of
view Google Analytics (or the like) could be an OK solution.
- Personally, I'm not sure how shipping GA code in Apache OpenMeetings
works, so I can't comment much on that. I would definitely post a clear
notice about it, and ensure that end users understand how to turn it off
or the like if they're concerned about privacy.
- In terms of sharing login details to such third party services like
GA, the best practice is first of all to keep the credentials secure.
If this is a service that the PMC as a whole wants to use or needs to
improve the project, then you should be sure to share the credentials
with at least three separate PMC members, and make it clear that you
intend to use this for the PMC, and not just as individuals.
There have been cases in the past where similar credentials were created
by individuals, used by projects, and then the individuals moved
elsewhere... without passing the credentials to anyone else - hence the
sharing within other individual PMC members.
I hope that helps from the branding and best practices side.
- Shane
P.S. Re: 4.2 and 4.3, I would definitely recommend having a very clear
notice that such error collection is being done in any new builds. But
you can certainly (from my perspective, at least) just ask the user once
per session or per new version install, etc. - no need to do it every
single connection or whatever.
On 6/6/2013 5:37 AM, Alexei Fedotov wrote:
> [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: 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>.
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
>
Re: Error collecting infrastructure for Openmeetings
Posted by 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
---------------------------------------------------------------------
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>.
[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>.
[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 "seba.wagner@gmail.com" <se...@gmail.com>.
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 "seba.wagner@gmail.com" <se...@gmail.com>.
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 Shane Curcuru <as...@shanecurcuru.org>.
(Bcc: privately-archived trademarks@ for brand awareness)
I'm not familiar enough with OpenMeeting's functionality and intended
use of this to make specific comments. However I can offer some general
principles to consider.
- If an Apache project PMC has a specific and clear need for assistance
in dealing with legal, infra, or brand issues, then the appropriate ASF
groups will figure out how to help. The question here is: what is the
*specific* need that the PMC as a whole has addressed, and what
legal/organizational issue(s) is blocking them from moving forward?
This thread is certainly interesting for the discussion, but it's not
specific enough for many of us to really help yet.
- Any use of Google Analytics or other such user data capture systems
must both comply with their terms of use, as well as comply with the
ASF's branding requirements. In particular, use of Google Analytics
requires posting a clear terms of service, etc. where the users will see
it, etc.
Also, as a public charity that relies on communities of volunteers (like
yourself!) who do the work of our projects, we need to be sensitive to
privacy issues of our users. It's fine to use a program like this, as
long as we follow the rules, and give people an appropriate way to opt
out. Separately, we should not give the impression that the ASF or any
Apache project specifically endorses or requires such an outside service
for our core functionality of our products.
- Fundamentally, any Apache project's source code and releases must be
on Apache controlled services/hardware. Apache project mailing lists
and primary homepage websites really should also be on Apache hardware,
although it's possible to host those elsewhere if there's a really good
reason. Similarly, end users must be able to use the primary
functionality of an Apache project by getting all they need from that
Apache project's homepage.
Optional features or systems can be run elsewhere, so from that point of
view Google Analytics (or the like) could be an OK solution.
- Personally, I'm not sure how shipping GA code in Apache OpenMeetings
works, so I can't comment much on that. I would definitely post a clear
notice about it, and ensure that end users understand how to turn it off
or the like if they're concerned about privacy.
- In terms of sharing login details to such third party services like
GA, the best practice is first of all to keep the credentials secure.
If this is a service that the PMC as a whole wants to use or needs to
improve the project, then you should be sure to share the credentials
with at least three separate PMC members, and make it clear that you
intend to use this for the PMC, and not just as individuals.
There have been cases in the past where similar credentials were created
by individuals, used by projects, and then the individuals moved
elsewhere... without passing the credentials to anyone else - hence the
sharing within other individual PMC members.
I hope that helps from the branding and best practices side.
- Shane
P.S. Re: 4.2 and 4.3, I would definitely recommend having a very clear
notice that such error collection is being done in any new builds. But
you can certainly (from my perspective, at least) just ask the user once
per session or per new version install, etc. - no need to do it every
single connection or whatever.
On 6/6/2013 5:37 AM, Alexei Fedotov wrote:
> [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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
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>.
[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>.
Rob, thank you for sharing your opinion!
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 9:52 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jun 6, 2013 at 5:30 AM, Alexei Fedotov <al...@gmail.com> wrote:
>> Hello, Infra and Legal folks,
>>
>> We ask you for advice on the automated error collection
>> infrastructure. Any helpful ideas are appreciated.
>>
>
> A perspective from someone who has set up and used Google Analytics on
> an Apache project website and researched some of the issues.
>
>> 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?
>>
>
> If the weight of the tracking infrastructure is a concern, have you
> thought of using an open source web analytics tool like Piwik? Would
> that give you what you need?
>
> http://piwik.org/
>
>
>> 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);
>> }
>>
>
> You should be aware of two legal/regulatory concerns:
>
> 1) Read the terms of service for Google Analytics carefully. You
> will, for example, be required to disclose its use in a posted privacy
> policy.
>
> 2) There have been some concerns raised in Germany about the IP
> address storage that Google Analytics, and whether that contravenes
> local data privacy laws. I have no opinion on whether this concern is
> legitimate, but it does exist. Google has added an API to help
> anonymize the IP and you might want to add that to your code, if your
> community and users share this concern:
>
> https://developers.google.com/analytics/devguides/collection/gajs/methods/gaJSApi_gat#_gat._anonymizeIp
>
>> 3. Is it ok for PMC to share Google Analytics id? Should we use some
>> Apache Id instead?
>>
>
> Two things: the ID, which is just a string, and the password to the
> Google Analytics account that gives you access to the results of the
> tracking. I don't see any problems with the ID. That is public
> information, and anyone can see it in the code. It is not a secret.
> But for access to the reports Google does allow you to assign access
> to multiple users, at various control levels. What we did with
> OpenOffice is give access to interested PMC members.
>
>
> Regards,
>
> -Rob
>
>> 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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
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>.
Rob, thank you for sharing your opinion!
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Wed, Jun 12, 2013 at 9:52 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jun 6, 2013 at 5:30 AM, Alexei Fedotov <al...@gmail.com> wrote:
>> Hello, Infra and Legal folks,
>>
>> We ask you for advice on the automated error collection
>> infrastructure. Any helpful ideas are appreciated.
>>
>
> A perspective from someone who has set up and used Google Analytics on
> an Apache project website and researched some of the issues.
>
>> 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?
>>
>
> If the weight of the tracking infrastructure is a concern, have you
> thought of using an open source web analytics tool like Piwik? Would
> that give you what you need?
>
> http://piwik.org/
>
>
>> 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);
>> }
>>
>
> You should be aware of two legal/regulatory concerns:
>
> 1) Read the terms of service for Google Analytics carefully. You
> will, for example, be required to disclose its use in a posted privacy
> policy.
>
> 2) There have been some concerns raised in Germany about the IP
> address storage that Google Analytics, and whether that contravenes
> local data privacy laws. I have no opinion on whether this concern is
> legitimate, but it does exist. Google has added an API to help
> anonymize the IP and you might want to add that to your code, if your
> community and users share this concern:
>
> https://developers.google.com/analytics/devguides/collection/gajs/methods/gaJSApi_gat#_gat._anonymizeIp
>
>> 3. Is it ok for PMC to share Google Analytics id? Should we use some
>> Apache Id instead?
>>
>
> Two things: the ID, which is just a string, and the password to the
> Google Analytics account that gives you access to the results of the
> tracking. I don't see any problems with the ID. That is public
> information, and anyone can see it in the code. It is not a secret.
> But for access to the reports Google does allow you to assign access
> to multiple users, at various control levels. What we did with
> OpenOffice is give access to interested PMC members.
>
>
> Regards,
>
> -Rob
>
>> 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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> ---------------------------------------------------------------------
> 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 Rob Weir <ro...@apache.org>.
On Thu, Jun 6, 2013 at 5:30 AM, Alexei Fedotov <al...@gmail.com> wrote:
> Hello, Infra and Legal folks,
>
> We ask you for advice on the automated error collection
> infrastructure. Any helpful ideas are appreciated.
>
A perspective from someone who has set up and used Google Analytics on
an Apache project website and researched some of the issues.
> 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?
>
If the weight of the tracking infrastructure is a concern, have you
thought of using an open source web analytics tool like Piwik? Would
that give you what you need?
http://piwik.org/
> 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);
> }
>
You should be aware of two legal/regulatory concerns:
1) Read the terms of service for Google Analytics carefully. You
will, for example, be required to disclose its use in a posted privacy
policy.
2) There have been some concerns raised in Germany about the IP
address storage that Google Analytics, and whether that contravenes
local data privacy laws. I have no opinion on whether this concern is
legitimate, but it does exist. Google has added an API to help
anonymize the IP and you might want to add that to your code, if your
community and users share this concern:
https://developers.google.com/analytics/devguides/collection/gajs/methods/gaJSApi_gat#_gat._anonymizeIp
> 3. Is it ok for PMC to share Google Analytics id? Should we use some
> Apache Id instead?
>
Two things: the ID, which is just a string, and the password to the
Google Analytics account that gives you access to the results of the
tracking. I don't see any problems with the ID. That is public
information, and anyone can see it in the code. It is not a secret.
But for access to the reports Google does allow you to assign access
to multiple users, at various control levels. What we did with
OpenOffice is give access to interested PMC members.
Regards,
-Rob
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
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>.
[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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Error collecting infrastructure for Openmeetings
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jun 6, 2013 at 5:30 AM, Alexei Fedotov <al...@gmail.com> wrote:
> Hello, Infra and Legal folks,
>
> We ask you for advice on the automated error collection
> infrastructure. Any helpful ideas are appreciated.
>
A perspective from someone who has set up and used Google Analytics on
an Apache project website and researched some of the issues.
> 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?
>
If the weight of the tracking infrastructure is a concern, have you
thought of using an open source web analytics tool like Piwik? Would
that give you what you need?
http://piwik.org/
> 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);
> }
>
You should be aware of two legal/regulatory concerns:
1) Read the terms of service for Google Analytics carefully. You
will, for example, be required to disclose its use in a posted privacy
policy.
2) There have been some concerns raised in Germany about the IP
address storage that Google Analytics, and whether that contravenes
local data privacy laws. I have no opinion on whether this concern is
legitimate, but it does exist. Google has added an API to help
anonymize the IP and you might want to add that to your code, if your
community and users share this concern:
https://developers.google.com/analytics/devguides/collection/gajs/methods/gaJSApi_gat#_gat._anonymizeIp
> 3. Is it ok for PMC to share Google Analytics id? Should we use some
> Apache Id instead?
>
Two things: the ID, which is just a string, and the password to the
Google Analytics account that gives you access to the results of the
tracking. I don't see any problems with the ID. That is public
information, and anyone can see it in the code. It is not a secret.
But for access to the reports Google does allow you to assign access
to multiple users, at various control levels. What we did with
OpenOffice is give access to interested PMC members.
Regards,
-Rob
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>