(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: [email protected]
For additional commands, e-mail: [email protected]
