openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <>
Subject Re: Error collecting infrastructure for Openmeetings
Date Thu, 13 Jun 2013 08:11:32 GMT
Shane, thank you for commenting. This really helps.
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
+7 916 562 8095

On Wed, Jun 12, 2013 at 10:46 PM, Shane Curcuru <> 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]
>> --
>> With best regards / с наилучшими пожеланиями,
>> Alexei Fedotov / Алексей Федотов,
>> +7 916 562 8095
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message