On Mon, Jun 8, 2015 at 9:57 AM, Leif Madsen <leif.mad...@avoxi.com> wrote:
> On Mon, Jun 8, 2015 at 9:35 AM, Russell Bryant <russ...@russellbryant.net> > wrote: > >> On Tue, Jun 2, 2015 at 8:05 PM, Matthew Jordan <mjor...@digium.com> >> wrote: >> >>> Personally, I'd like some way to present any user of Asterisk with a >>> >> one-time only, non-annoying "please help the project and opt in" >>> question, and then move on forever. Unfortunately, I don't have a good >>> idea on making this suggestion work. If the only way to opt in is to >>> provide a .conf file and set "enable = true", then I can't see >>> anywhere near sufficient numbers of people being aware of the >>> configuration choice, much less making the choice to enable it, to >>> justify the creation of the module itself. >>> >>> If someone has a good proposal on making the suggestion work, then I'd >>> love to entertain it further. >>> >> >> 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. >> >> 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. >> >> 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. >> > > 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. > > 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. > 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. > > 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. > > Then on the console when you connect, you could provide output that looks > similar to the following: > > $ asterisk -r > Asterisk 1.8.11-cert9, Copyright (C) 1999 - 2012 Digium, Inc. and others. > Created by Mark Spencer <marks...@digium.com> > Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for > details. > This is free software, with components licensed under the GNU General > Public > License version 2 and other licenses; you are welcome to redistribute it > under > certain conditions. Type 'core show license' for details. > ========================================================================= > Connected to Asterisk 1.8.11-cert9 currently running on localhost (pid = > 4364) > Verbosity is at least 5 > Asterisk Beacon: Enabled (see core show help beacon) > *CLI> > > With a separate configuration file and module, you could then provide the > following option: > > beacon set opt in > beacon set opt out > > This would then write out to the configuration beacon.conf with > enabled=yes or no and reload the module. > 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. -- Russell Bryant
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
