<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 8, 2015 at 9:57 AM, Leif Madsen <span dir="ltr"><<a href="mailto:leif.madsen@avoxi.com" target="_blank">leif.madsen@avoxi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jun 8, 2015 at 9:35 AM, Russell Bryant <span dir="ltr"><<a href="mailto:russell@russellbryant.net" target="_blank">russell@russellbryant.net</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><span>On Tue, Jun 2, 2015 at 8:05 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br></span></span><span class=""><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Personally, I'd like some way to present any user of Asterisk with a<br></blockquote></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
one-time only, non-annoying "please help the project and opt in"<br>
question, and then move on forever. Unfortunately, I don't have a good<br>
idea on making this suggestion work. If the only way to opt in is to<br>
provide a .conf file and set "enable = true", then I can't see<br>
anywhere near sufficient numbers of people being aware of the<br>
configuration choice, much less making the choice to enable it, to<br>
justify the creation of the module itself.<br>
<br>
If someone has a good proposal on making the suggestion work, then I'd<br>
love to entertain it further.<br></blockquote><div><br></div></span><div>I feel that "opt-out" is fundamentally wrong from a privacy perspective.  Further, I think the potential backlash and resulting damage to the project is pretty severe.  </div><div><br></div><div>I also don't think "opt-in is hard" is an acceptable reason not to do it.  If it's too hard to make an opt-in solution useful, then maybe it shouldn't be done at all.  This sort of thing really doesn't seem very common, and this is probably a big reason why.</div><div><br></div><div>One alternative would be to issue periodic user surveys that are promoted on the mailing lists, twitter, etc.  I don't think you'll ever get a reliable "absolute numbers" measure.  A survey could still produce useful relative numbers and help identify some trends over time.</div></span></div></div></div></blockquote><div><br></div><div>First, I think the idea of a quarterly survey makes a lot of sense. You would probably get a bunch of useful information in one go rather than a slow trickle of information. You could also make this something people do on the website when downloading Asterisk from there.</div><div><br></div><div>Other projects I've seen this on (Bower for example), do it during the installation process. The way I would picture this working with the Makefile is that you provide a prompt with a Y/N selection asking if you want to opt-in. If someone wants to automate this process, provide a flag option that allows them to --opt-in or --opt-out in order to provide a selection while also skipping human input. Then you can "override" that compiled in default with the below suggestion.</div></div></div></div></blockquote><div><br></div><div>As Matt pointed out, not everyone installs from source.  I'd say the vast majority do not.  I think any packager that chose to compile Asterisk with this stuff enabled by default should be flamed.  It's just plain wrong.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Around the configuration file approach (which I think is also useful for those wanting to override the default compile time option, which will be selected during SOME sort of compile time process, whether that be on the machine, or during the package creation process), I would expect it to be a file provided via the 'make samples' option. </div><div><br></div><div>Then on the console when you connect, you could provide output that looks similar to the following:</div><div><br></div><div><div>$ asterisk -r</div><div>Asterisk 1.8.11-cert9, Copyright (C) 1999 - 2012 Digium, Inc. and others.</div><div>Created by Mark Spencer <<a href="mailto:markster@digium.com" target="_blank">markster@digium.com</a>></div><div>Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.</div><div>This is free software, with components licensed under the GNU General Public</div><div>License version 2 and other licenses; you are welcome to redistribute it under</div><div>certain conditions. Type 'core show license' for details.</div><div>=========================================================================</div><div>Connected to Asterisk 1.8.11-cert9 currently running on localhost (pid = 4364)</div><div>Verbosity is at least 5</div><div>Asterisk Beacon: Enabled (see core show help beacon)</div><div>*CLI> </div></div><div><br></div><div>With a separate configuration file and module, you could then provide the following option:</div><div><br></div><div>beacon set opt in</div><div>beacon set opt out</div><div><br></div><div>This would then write out to the configuration beacon.conf with enabled=yes or no and reload the module.</div></div></div></div></blockquote><div><br></div><div>So, all of this is about making opt-in easier.  That's fine, but folks will have to decide if it's still useful enough to do the work and run the server side infrastructure.  I suspect not, personally.</div><div><br></div><div>-- </div><div>Russell Bryant</div></div><br></div></div>