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.wag...@gmail.com <seba.wag...@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 <alexei.fedo...@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.wag...@gmail.com >> <seba.wag...@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" <alexei.fedo...@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.wag...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
