> I think, as a baseline, we should be working with multiple teams prior to any survey being published:
Very good idea indeed. Better safe than sorry. > It might make sense for us to have a privacy policy specifically for our surveys in general I think that would be a good idea for Niall, Christian and Bolke to chime in on that one - whether to have a separate policy or whether to fold it in the general policy. I know Christian, Niall and Bolke are working towards making our privacy policy "official" and "approved by board" [1] - and one of the important things raised by Christian in the discussion was that we need to explicitly list (provide catalogue of) all the tools we are using to collect potentially private data. We discuss Matomo (and the possibility of gathering "product usage" information) in this thread but I think this is fairly relevant as well. I linked directly to the message from Christian, but the whole thread is interesting to read in this context I think. [1] The "Matomo thread " https://lists.apache.org/thread/x4kjt81o1kxcy3wn79h25ghvsskgh912 I do not want to dominate the discussion here, so I will shut up, but I thought it's worth mentioning. J. On Fri, Aug 15, 2025 at 1:43 PM Daniel Gruno <humbed...@apache.org> wrote: > On 8/15/25 13:30, Jarek Potiuk wrote: > > The email one though is connected with keeping PII though ? (Personally > > Identifiable Information) - so I guess that one would require at least > some > > discussion with the privacy team ? > > I think, as a baseline, we should be working with multiple teams prior > to any survey being published: > > - privacy team for data privacy sanity checks > - M&P for messaging and promotion if/when needed > - Projects that have a significant interest in whatever survey is being > assembled. > > It might make sense for us to have a privacy policy specifically for our > surveys in general, which we can then refer to at the beginning of the > survey - preferably before any data is entered. This policy could also > be a guideline for us on how to handle the data. For instance, we could > -- or rather, I think we should/must -- delete or otherwise obfuscate > any PII in surveys no later than 60 days after the survey has been > closed for submissions. > > Let me know what people are thinking with regards to that, and I can > start putting together a privacy policy document for us in our wiki[1]. > > With regards, > Daniel. > > [1] https://cwiki.apache.org/confluence/display/EDI/ > > > > > On Fri, Aug 15, 2025 at 1:25 PM Daniel Gruno <humbed...@apache.org> > wrote: > > > >> On 8/15/25 13:14, Jarek Potiuk wrote: > >>> One question - I understand the survey is anonymous, but is there a way > >> to > >>> distinguish several answers from the same person (or at the very least > >>> browser, due to anonymity). Just thinking of some "gaming" scenarios - > >> ASF > >>> people are smart and might get the idea to increase chances of their > >> choice > >>> by responding to the survey several times (I just did with the low > rating > >>> for poor pony choices ;) ) . > >> > >> Great question, and thankfully one that I already asked myself as well, > >> so I have some answers for you. > >> > >> For surveys aimed at either a set group of people (like committers, > >> members, etc), we can make use of closed, individual links. We can > >> pre-generate these in advance to ensure only one submission per person. > >> > >> For wider, open audiences, we can use email verification to at least > >> limit responses to one per email address. This would require anyone > >> wanting to submit a survey to first verify their email address with the > >> system through a callback link sent to their email address. > >> > >> With the latter you could presumably also filter out obvious attempts at > >> gaming any sort of survey, though I would hope we don't have to do that. > >> > >> > >>> > >>> On Fri, Aug 15, 2025 at 10:27 AM Daniel Gruno <humbed...@apache.org> > >> wrote: > >>> > >>>> On 8/15/25 09:53, Jarek Potiuk wrote: > >>>>> This tool is great. Works flawlessly. But I think the choice of > ponies > >>>> was > >>>>> very limited, so you should try harder :) > >>>> > >>>> That's why we have the "how did we do?" questions at the end :-D > >>>> > >>>>> > >>>>> J. > >>>>> > >>>>> > >>>>> On Fri, Aug 15, 2025 at 9:23 AM Daniel Gruno <humbed...@apache.org> > >>>> wrote: > >>>>> > >>>>>> Hello again, wonderful D&I folks. > >>>>>> > >>>>>> I have been experimenting with a self-hosted tool for conducting > >> surveys > >>>>>> and collecting feedback/reviews, and things are looking pretty > decent. > >>>>>> > >>>>>> I'd love to get some feedback from the people on this list, so that > we > >>>>>> can perhaps decide on using this tool or not and discuss some basic > >>>>>> premises for conducting surveys in the future. > >>>>>> > >>>>>> You can try a survey demo here: > >>>>>> https://surveys.diversity.apache.org/s/wcee4v8ygw8q0pih0nflnxl1 > >>>>>> > >>>>>> Those of you on the D&I committee[1] who wants to try their hands at > >> the > >>>>>> behind-the-scenes work with surveys can let me know (private or this > >>>>>> list), and I'll set you up with access to manage surveys yourselves. > >>>>>> This will also allow you to see the results of surveys in various > >> ways. > >>>>>> > >>>>>> I have built a template for our surveys that comes with a standard > >>>>>> introduction and a data consent form at the very end; you should be > >> able > >>>>>> to see that in the survey demo I linked to. I had the wording in the > >>>>>> template refined by our resident "editor-in-chief", Andrew Wetmore, > >> but > >>>>>> things can always be improved upon further, so do not hesitate to > >>>>>> suggest changes. > >>>>>> > >>>>>> There isn't a whole lot more to say, take the survey for a spin and > >> see > >>>>>> if this survey tool fits the brief. > >>>>>> > >>>>>> With regards, > >>>>>> Daniel. > >>>>>> > >>>>>> > >>>>>> [1] Access to survey administration is restricted to members of the > >> D&I > >>>>>> committee for data privacy reasons; this is explained in more detail > >> in > >>>>>> the survey itself. > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > >
