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