Hi,

I find it a bit difficult to respond to this message and would prefer to review 
a document. If a document already exists please give me a pointer. 

I'd like to propose that the process being discussed be put onto the public 
wiki in the D&I site, including a discussion of the privacy issues.

I have a few points that I'd like to have considered when rolling out the plan.

1. We should have a way to track response counts to the survey.

2. We should allow non-committers to request a survey and encourage PMCs and 
podlings to have their contributors request a survey.

3. We should disallow multiple responses from the same individual to the 
survey. This might involve assigning an immutable ID to each person who 
receives or requests a survey.

4. After the survey is complete we should make the data public, anonymizing the 
persons submitting the survey. Something like:
ID                                                            Nationality      
Gender     Years
---------------------------------------------------- ------------------  
-----------  ---------
5394875438956fd43098ef7594365984   USA                 D            70

Can you verify that this is the document being developed? Perhaps link it from 
the suggested process page.
https://docs.google.com/document/d/1dfyMZ58ZENOO21sZvj__g1fjIP-BJfDuIECt066Dsuc/edit?ts=5dbba664

Regards,
Craig

> On Nov 18, 2019, at 2: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
>>>>> 
>>>> 
>>> -- 
>>> Kevin A. McGrail
>>> [email protected]
>>> 
>>> Member, Apache Software Foundation
>>> Chair Emeritus Apache SpamAssassin Project
>>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>> 
>> -- 
>> Kevin A. McGrail
>> [email protected]
>> 
>> Member, Apache Software Foundation
>> Chair Emeritus Apache SpamAssassin Project
>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>> 
>> 

Craig L Russell
[email protected]

Reply via email to