openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <>
Subject Re: Error collecting infrastructure for Openmeetings
Date Wed, 12 Jun 2013 18:46:44 GMT
(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]
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> +7 916 562 8095
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message