I remain -1 on uploading email addresses to third-party, and if that is the
intention, please check with Legal if that is kosher or not, considering
various legislation around the world.

On Wed, Nov 20, 2019 at 1:57 PM Kenneth Knowles <[email protected]> wrote:

> +1
>
> I appreciate the diligence of thought, and patience explaining the
> rationale.
>
> Kenn
>
> On Tue, Nov 19, 2019 at 7:55 AM Katia Rojas <[email protected]>
> wrote:
>
> > I vote +1 to the proposal of Kevin and to reopen the vote.
> >
> > Thanks,
> > Katia
> >
> > On Tue, Nov 19, 2019 at 1:17 AM Kevin A. McGrail <[email protected]>
> > wrote:
> >
> > > I vote +1 on the reopened vote just to be explicitly clear.
> > > --
> > > Kevin A. McGrail
> > > Member, Apache Software Foundation
> > > Chair Emeritus Apache SpamAssassin Project
> > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 <(703)%20798-0171>
> > >
> > >
> > > On Mon, Nov 18, 2019 at 5:59 PM Gris Cuevas <[email protected]> wrote:
> > >
> > > > Hi folks - I missed this thread due to wrong filtering on my inbox,
> > sorry
> > > > about that.
> > > >
> > > >
> > > > As VP of D&I I'm satisfied with the proposal Kevin stated in this
> > vote. I
> > > > see it as the most viable option to move forward safely and
> > effectively.
> > > > Not only Kevin has done some due diligence on reviewing LimeSurvey
> > from a
> > > > security and privacy perspective, but Bitergia, our vendor, has also
> > > > recommended the system based in their experience working with other
> OSS
> > > > projects.
> > > >
> > > > I also see that Kevin has addressed most of the concerns brought up
> by
> > > the
> > > > people in this thread, and I'm supportive of moving forward with the
> > > > following plan:
> > > >
> > > > 1. Use LimeSurvey as the platform for the EDI Survey and share
> visibly
> > a
> > > > link to their data privacy policy.
> > > > 2. Upload a list of all apache.org email addresses to LimeSurvey and
> > > send
> > > > direct emails to individuals
> > > > 3. Use a re-usable token for a universal link that we'll use to
> promote
> > > > the survey in social media
> > > >
> > > > I would like to re-open the vote to pursue this plan to give people
> the
> > > > chance to express any other concerns. I'll close the vote by Friday
> and
> > > > will assume lazy consensus by then.
> > > >
> > > > My vote is +1
> > > >
> > > > I'll be putting this plan and the vote in the board report to make
> sure
> > > > the president, vice-president and the board are aware of them.
> > > >
> > > > Cheers,
> > > > G
> > > >
> > > > On 2019/11/15 07:29:03, "Kevin A. McGrail" <[email protected]>
> > wrote:
> > > > > After sufficient time and a reminder, this vote does not pass to
> use
> > > > > limesurvey as described below.  Despite discussion, we had no votes
> > > > > other than my own.
> > > > >
> > > > > Regards,
> > > > > KAM
> > > > >
> > > > > On 11/5/2019 11:33 PM, Kevin A. McGrail wrote:
> > > > > >
> > > > > > I have researched the vendor for the D&I Survey and present the
> > > > > > following information and vote at the bottom.  The goal of this
> > > change
> > > > > > is technical to limit spamming as well as improve the
> > deliverability
> > > > > > of the survey and therefore the response rate.
> > > > > >
> > > > > > -KAM
> > > > > >
> > > > > > Operator: LimeSurvey GmbH
> > > https://www.limesurvey.org/about-us/imprint
> > > > > >
> > > > > > "The worldwide leading open source survey software
> > > > > > as a professional SaaS solution or as a self-hosted Community
> > > Edition."
> > > > > >
> > > > > > Licensed: GPL v2 or later (
> > https://www.limesurvey.org/stable-release
> > > )
> > > > > >
> > > > > >
> > > > > >
> > > > > > Due to the operator being German, the data protection Terms of
> > > Service
> > > > > > are excellent and follow BDSG, TKG and GDPR.  See
> > > > > > https://www.limesurvey.org/policies/terms-conditions, Section
> 10:
> > > Data
> > > > > > Protection.
> > > > > >
> > > > > > As is typical of the strong German data protection laws, the
> > privacy
> > > > > > policy is excellent as well:
> > > > > > https://www.limesurvey.org/policies/privacy-policy
> > > > > >
> > > > > > The only nit is that technically the terms of service point to
> the
> > > > > > privacy policy in German:
> > > > > > https://www.limesurvey.org/de/richtlinien/datenschutzrichtlinie
> > so a
> > > > > > minor thing they should fix.
> > > > > >
> > > > > > Otherwise, I think it's an excellent vendor providing no concerns
> > for
> > > > > > the ASF to use them as a service provider for the survey.
> > > > > >
> > > > > > My only key recommendation is that we make sure the survey is set
> > to
> > > > > > "Turn on the Anonymized responses- option" which will "...mark
> > > > > > participants who complete the survey only with a 'Y' instead of
> > > > > > date/time to ensure the anonymity of your participants."
> > > > > >
> > > > > > Therefore, I call a vote and +1 to use limesurvey, request a list
> > of
> > > > > > committer addresses, load them into the SaaS offering and use
> this
> > to
> > > > > > send to all committers rather than use committers@ for the
> survey
> > > for
> > > > > > 1 use only.
> > > > > >
> > > > > > We should also still allow anonymous entries, ask PMCs to post
> > about
> > > > > > the survey and spread the word on our social media.
> > > > > >
> > > > > > We should also ask Infra to join in a small test of the survey
> and
> > to
> > > > > > whitelist as appropriate the surveys on our system as well as to
> > > > > > provide a current CSV file export to KAM to load into the survey
> > > > software.
> > > > > >
> > > > > > If this vote passes, various Jira like DI-30 should be updated to
> > > > > > reflect this approach.
> > > > > >
> > > > > > On 11/2/2019 3:12 PM, Kevin A. McGrail wrote:
> > > > > >> Bitergia isn't the actual sender, it would be limesurvey.  I
> will
> > > > > >> look into how it sends on behalf of but the idea is not to use a
> > > > > >> mailing list software but to have the survey software send each
> > > > > >> individually.
> > > > > >>
> > > > > >> I doubt di30 talks about this as I have been suggesting offlist
> > how
> > > > > >> to improve the deliverability and response rate of the survey.
> > > > > >>
> > > > > >> On Sat, Nov 2, 2019, 12:35 Sam Ruby <[email protected]
> > > > > >> <mailto:[email protected]>> wrote:
> > > > > >>
> > > > > >>     On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> > > > > >>     <[email protected] <mailto:[email protected]>> wrote:
> > > > > >>     >
> > > > > >>     > The Apache.org email addresses are easily harvested from
> our
> > > > > >>     mailing
> > > > > >>     > list archives.
> > > > > >>     >
> > > > > >>     > This would be an export from LDAP or similar of all @
> > > apache.org
> > > > > >>     <http://apache.org>
> > > > > >>     > addresses which is the same as committers@ but will be
> sent
> > > > > >>     directly
> > > > > >>     > instead of routed through a mailing list.
> > > > > >>     >
> > > > > >>     > There are significant deliverability and response rate
> > > concerns
> > > > > >>     with
> > > > > >>     > using a mailing list.
> > > > > >>
> > > > > >>     I may have misunderstood the intent of
> > > > > >>     https://issues.apache.org/jira/browse/DI-30.
> > > > > >>
> > > > > >>     If there is a need to create an alias for all committers,
> that
> > > > could
> > > > > >>     be easily constructed.  Bitergia would send a single email
> to
> > > our
> > > > > >>     infrastructure, and our infrastructure would be forwarded to
> > > each
> > > > id
> > > > > >>     on the list.
> > > > > >>
> > > > > >>     If such an alias were created, it should either be set up to
> > > only
> > > > > >>     allow emails from known Bitergia emails, and the alias
> should
> > be
> > > > > >>     taken
> > > > > >>     down when not in use, as it would be a vector for spam.
> > > > > >>
> > > > > >>     - Sam Ruby
> > > > > >>
> > > > > >>     > Regards,
> > > > > >>     > KAM
> > > > > >>     >
> > > > > >>     > On 11/2/2019 5:53 AM, Justin Mclean wrote:
> > > > > >>     > > Hi,
> > > > > >>     > >
> > > > > >>     > > I would also be uncomfortable in creating a list of
> people
> > > to
> > > > > >>     email and making that available even internally. Pervious
> > > > > >>     experience with surveys (non D&I) at the ASF have shown
> > several
> > > > > >>     times that mistake are made and/or emails addresses
> harvested
> > > > > >>     without permission. If we do go down that path I would also
> > like
> > > > > >>     to know how we are creating this list e.g what would be the
> > > > > >>     criteria to be on it.
> > > > > >>     > >
> > > > > >>     > > committers@ has a wide distribution and with correct
> > > > > >>     messaging we can use it very little effort and risk.
> > > > > >>     > >
> > > > > >>     > > Thanks,
> > > > > >>     > > Justin
> > > > > >>     >
> > > > > >>     > --
> > > > > >>     > Kevin A. McGrail
> > > > > >>     > [email protected]
> > > > > >>     >
> > > > > >>     > Member, Apache Software Foundation
> > > > > >>     > Chair Emeritus Apache SpamAssassin Project
> > > > > >>     > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > <(703)%20798-0171>
> > > > > >>     >
> > > > > >>
> > > > > > --
> > > > > > Kevin A. McGrail
> > > > > > [email protected]
> > > > > >
> > > > > > Member, Apache Software Foundation
> > > > > > Chair Emeritus Apache SpamAssassin Project
> > > > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > <(703)%20798-0171>
> > > > >
> > > > > --
> > > > > Kevin A. McGrail
> > > > > [email protected]
> > > > >
> > > > > Member, Apache Software Foundation
> > > > > Chair Emeritus Apache SpamAssassin Project
> > > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > <(703)%20798-0171>
> > > > >
> > > > >
> > > >
> > >
> >
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Reply via email to