The intent is to get responses from Contributors + Committers We want to use email addresses on file to reach committers.
To reach contributors, we want to send an email to pmcs@ asking to repost a link so their user and dev lists can contribute. The vote Kevin is driving is to get consensus on wether we do a direct email address upload to lineaurvey or not. If we don't we will need to send an email to committers@ On Wed, Nov 6, 2019, 1:44 PM Ted Dunning <[email protected]> wrote: > On Wed, Nov 6, 2019 at 1:20 PM Georg Link <[email protected]> wrote: > > > > > > On Nov 6, 2019, at 2:19 PM, Justin Mclean <[email protected]> > > wrote: > > > > > > Hi Georg, > > > > > > Thanks for clearing up how that will work. > > > > > >> To send out invites through LimeSurvey, it requires creating a > > “participant table”. > > >> Every participant is assigned a token, to track whether the > participant > > responded or not. > > >> Again, the responses are anonymous and no link between the participant > > entry and the response is stored. > > > > > > I assume we know if the participant responded but can’t match that to > an > > individual response. That may not quite be as anonymous as some people > > expect. > > > > To avoid tracking who responded I see two options, assuming we want to > > send emails through LimeSurvey: > > > > Option 1: > > We can send everyone the same URL with the same token from the dummy > > participant. > > > > Option 2: > > We can leave the survey open, without a participant table. Thus > > eliminating the need for a token. > > The invites are sent from a “dummy survey” that we don’t actually use but > > instead we include the URL to the real survey. > > No tokens, no tracking, full anonymity, to information about response > rate. > > > > > Option 3: > Build a participant table and send with separate tokens per participant, > but don't record the correspondence (that let's us avoid duplicate > submissions for committers). > At the same time, run a separate (but with identical questions) survey for > social media with no tokens to allow wide spreading. > > This allows us to compare the social media results against the deduplicated > committer results. That should make any spamming of the social media branch > fairly apparent. >
