It sounds like p2 sending stats may need to change depending on the
final form of the policy.
As I recall, in our private exchange I just said "no" and that we'd
have to wait until the policy was developed.
There is a link to the work-in-progress policy on the bug.
But, for convenience...
http://wiki.eclipse.org/Development_Resources/Call_Home_Policy
Like I said on the bug, my current sense is that we have to make
this opt-in, but I remain willing to be convinced otherwise.
I'm also trying to think of the bigger picture. A single plug-in
sending an occasional heartbeat is a relatively simple thing. But
the precedent that we set could result in a dozen or more plug-ins
all doing the same thing. Does this turn it into a bigger deal? I
don't know the answer, I'm just very sensitive to anything that
might offend our user community.
Amplifying matters, what happens when we do have a dozen plug-ins
all sending heartbeats and the user wants to turn it off? Do they
need to find and turn off a dozen checkboxes in the preferences?
The right answer _might_ be that we permit plug-ins to just send a
heartbeat without providing any ability to opt-out. My sense is that
this has potential to set off a tremendous backlash.
Or maybe I'm just being stupid and paranoid.
Wayne
On 09/05/2013 12:11 PM, Igor Fedorenko
wrote:
On 2013-09-05 11:42 AM, Wayne Beaton wrote:
If the user initiates an install operation
with full understanding that
they are contacting an Eclipse Foundation server to download
some
artefact, then it is perfectly reasonable (in my opinion) for
them to
expect that we're keeping track of the fact that that thing has
been
downloaded.
Doesn't the p2 mechanism do this?
p2 will upload stats even during local-only installation. When I
install
a feature from my local disk (or from my company mirror), no
download from Eclipse Foundation servers takes place, so it is not
reasonable to assume implicit consent to provide Eclipse
Foundation with
download stats.
Or are you looking for more than that?
It's one thing to download an
artefact, but quite a different thing to be notified that it's
actually
being used. Is this what you're looking for? Are we talking
about a
per-use notification, or periodic heartbeat? In my mind, any
ongoing
"I'm using this feature now" sort of thing is very different
from a
user-initiated installation/update process.
I am looking for periodic (weekly) heartbeat. I am not sure I
agree
there is significant difference between one-time and ongoing
reporting,
both cases should be handled consistently and provide a way to
opt-in
before any reporting takes place or opt-out, if we decide this is
acceptable.
I understand the desire to make it
opt-out. Using an opt-in strategy
severely diminishes the value of the gathered information.
Creation of a "call home" policy is being discussed in Bug
413169 [1].
Based on your direct email earlier this week, I got the impression
that
the current policy allows this kind of reporting as long as the
user can
explicitly opt-in. If this is not the case, when to you expect
conclusive decision on 413169? Also, can you provide a link to the
policy?
--
Regards,
Igor
Wayne
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413169
On 09/05/2013 07:44 AM, Igor Fedorenko wrote:
On 2013-09-05 4:00 AM, Markus Alexander Kuppe wrote:
On 09/05/2013 02:14 AM, Igor Fedorenko
wrote:
* There will be workspace preference
to enable the counting, it will be
on by default.
Does this mean that the plug-in collects statistics even if
the user
does not opt-in to send stats?
No, I think nothing should recoded locally if the user decides
to
opt-out.
* When the plugin first starts, it
will inform the user about the
counting via a popup dialog or some other UI means and the
user will
have a choice to either acknowledge the counting or
navigate to
corresponding preferences page and disable counting there.
From what you describe it appears as if "no - do not
opt-in" requires
more clicks than "yes - opt-in". If this assumption is
correct, then
why?
Quite honestly, I want installation count report to be allowed
if the
user chooses not to think. I am open for discussion here and
if the
consensus is to make this single-click to both opt-in and
opt-out, I am
fine with it too.
Personally, though, I think Eclipse Foundation should allow
installation
report without explicit opt-in but still require a way to
allow opt-out.
This is what p2 is doing since 2010, so ability to opt-out
will be an
improvement compared to what we have now.
--
Regards,
Igor
M.
[1] http://bugs.eclipse.org/413169
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
<http://www.eclipse.org>
Learn about Eclipse Projects
<http://www.eclipse.org/projects>
EclipseCon Europe 2013
<http://www.eclipsecon.org/europe2013>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
