You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@diversity.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2019/11/01 15:03:34 UTC
Re: Survey Diversity and Inclusion
On Mon, Oct 28, 2019 at 6:10 PM Patricia Shanahan <pa...@acm.org> wrote:
> One danger that I don't know how to solve: In trying to reach as many
> people as possible you will bombard many of us with multiple e-mails.
Undoubtedly, but like many here, I'll end up seeing only one message.
> I am subscribed to dev@diversity.a.o, members@, committers@, two PMC
> private lists, and the corresponding dev@lists. I'm going to get about 7
> copies, and some people are subscribed to a lot more than 2 projects.
>
As a suggestion, committers@ are direct emails, which should entirely
overlap
the subset of everyone subscribed to members@ and private@ (therefore
including the pmcs@ superset), and those members@ and private@ lists
do not add value if the entire committers@ base will be solicited. So let's
please not duplicate.
Worried someone is filtering their committers@ traffic? Do we want to
include other /active/ contributors who are not yet committers? Then
it seems the dev@ lists are the most effective way to add people. But
it might improve the situation if the initial committers@ appeal does
include some text like the following;
> This survey seeks the input of any Apache "contributor", even those
> who are not committers. We seek your help to extend this invitation
> with those who have contributed in some way to the projects you
> participate in, or perhaps share with your communities' dev@ or
> users@ list.
For the message to come from a respected member of the project
means that even though people will see multiple copies, these direct
appeals will probably encourage more participation, especially by
external contributors, but also perhaps by committers.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
I wanted to give this vote a kick and see if we can get some people
weighing it. There's been a lot of discussion and I believe I've
answered all of the concerns.
+1 from me
-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 <rubys@intertwingly.net
>> <ma...@intertwingly.net>> wrote:
>>
>> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
>> <kmcgrail@apache.org <ma...@apache.org>> 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
>> > KMcGrail@Apache.org
>> >
>> > Member, Apache Software Foundation
>> > Chair Emeritus Apache SpamAssassin Project
>> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
>> >
>>
> --
> Kevin A. McGrail
> KMcGrail@Apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Daniel Gruno <hu...@apache.org>.
On 06/11/2019 21.25, Justin Mclean wrote:
> Hi,
>
>> The list will be all availids.
>
> Is that all emails people have subscribed to all lists or just certain lists? Or something based on Apache IDs? Or what's recorded in LDAP? Each of this is going to generate a different set of email addresses.
>
> Some things that come to mind. Have these been considered?
> - Some contributors do not have an Apache ID / are not in LDAP. (You get one when you become a committer.)
> - Some people have subscribed under multiple emails addresses to different lists
> - Emails address people use are not always the ones recorded in ldap (see for instance see the number of PMCs recorded as not signed up to their private lists as reported by Whimsy, when they have just signed up via other addresses).
> - People have multiple email address recorded in LDAP
>
> If instance if I look myself up LDAP it has several email addresses for me, but I also use other non recorded email addresses to subscribe to some lists.
>
>> There are numerous ways it helps spamming because for 1, people replying
>> with questions won't spm 7k other people.
>
> We currently have 7131 committers, if you included contributors it would be double that (or more). It’s still unclear how wide this group is that the survey link will sent to using this method. When sending to a list the reply to address could be set so that people don’t spam each other. I assume we would want replies to go to the dev@diversity list, if people have any questions about the survey or are having trouble filling it in we can answer them.
There are 26,971 contributors in the past year. We have this data
available, including most of their email addresses. Whether we choose to
spam/ham them (depending on your view) is another matter :)
>
>> Infra will generate the list. I expect it to be a trivial ldap to csv.
>
> Our contributors are not (that I’m aware) stored in LDAP, only committers are.
>
>> For the social media and pmc posts, we would use a single reusable survey
>> token.
>
> So we are posting to the lists as well? It might be best to put exactly what the plan is on a wiki page so everyone is clear what is expected to happen.
>
> Thanks,.
> Justin
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This is not going to reach all contributors but all committers.
OK. I assume you are aware that the intent is/was to send to a wider list that that?
> We are relying on their @apache.org address working.
OK so it will only be sent to committers thanks for clearing that up.
> That would be captured in Jira likely in DI-30. For now, the issue at
> hand is the vote about how it will be sent to the committers.
I assume only PMC votes are binding?
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Griselda Cuevas <gr...@google.com.INVALID>.
Adding Maria Cruz who is working on a comma launch plan for this.
...snip...
> So we are posting to the lists as well? It might be best to put exactly
what the plan is on a wiki page so everyone is clear what is expected to
happen.
We will do that
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 11/6/2019 3:25 PM, Justin Mclean wrote:
> Hi,
>
>> The list will be all availids.
> Is that all emails people have subscribed to all lists or just certain lists? Or something based on Apache IDs? Or what's recorded in LDAP? Each of this is going to generate a different set of email addresses.
AvailIds is the apache Ids when people get an @apache.org address.
> Some things that come to mind. Have these been considered?
> - Some contributors do not have an Apache ID / are not in LDAP. (You get one when you become a committer.)
This is not going to reach all contributors but all committers.
The mechanism to reach all contributors is the email to all PMCs asking
them to post to their users/dev lists and request responses.
> - Some people have subscribed under multiple emails addresses to different lists
Not applicable.
> - Emails address people use are not always the ones recorded in ldap (see for instance see the number of PMCs recorded as not signed up to their private lists as reported by Whimsy, when they have just signed up via other addresses).
We are relying on their @apache.org address working.
> - People have multiple email address recorded in LDAP
>
> If instance if I look myself up LDAP it has several email addresses for me, but I also use other non recorded email addresses to subscribe to some lists.
We are not getting a list of emails subscribed to lists. That would be
bridging into spam territory where we don't have consent.
I feel we do have consent to send an official Apache missive to your
official Apache email address.
>
>> There are numerous ways it helps spamming because for 1, people replying
>> with questions won't spm 7k other people.
> We currently have 7131 committers, if you included contributors it would be double that (or more). It’s still unclear how wide this group is that the survey link will sent to using this method. When sending to a list the reply to address could be set so that people don’t spam each other.
I would state that availids which is 1:1 with committers. Hopefully
this email clears that up.
> I assume we would want replies to go to the dev@diversity list, if people have any questions about the survey or are having trouble filling it in we can answer them.
Yes.
>
>> Infra will generate the list. I expect it to be a trivial ldap to csv.
> Our contributors are not (that I’m aware) stored in LDAP, only committers are.
Agreed.
>> For the social media and pmc posts, we would use a single reusable survey
>> token.
> So we are posting to the lists as well? It might be best to put exactly what the plan is on a wiki page so everyone is clear what is expected to happen.
That would be captured in Jira likely in DI-30. For now, the issue at
hand is the vote about how it will be sent to the committers.
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Justin Mclean wrote on 2019-11-22 3:55AM EST:
> Hi,
>
>> People filter those more often.
>
> I’m not sure how other people use filters but I tend to use them for a) emails that I want to pay more attention and respond right away and b) emails that I’ll look at at a later time. I filter emails sent to my apache.org address but don’t filter those sent to committers@.
I filter everything, and I read my @apache.org address frequently;
emails to committers@ much less frequently. So we have one data point
each way. Anyone have real, statistical data here? Otherwise we're
just pluraling anecdotes.
> I think that sending emails directly to apache addresses will result in less responses (based on my experience) and given previous history of how external people have used lists of address I’m concerned the list will be misused.
The security and reliability of uploading individual @apache.org
addresses has already been reviewed and approved elsethread. Do you
have a specific reason why you explicitly believe we can't trust
LimeSurvey to only use addresses for this survey?
Note that using individual @apache.org addresses allows individual
tokens which we want to use for tracking responded/didn't respond as
well, so changing the plan to use a single committers@ alias email would
lose data.
--
- Shane
Director & Member
The Apache Software Foundation
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Griselda Cuevas <gr...@google.com.INVALID>.
Hi everyone.
I reopened the vote and agreed to it because I wanted to get opinions that
could help me assess all possible scenarios and risks.
I also want to make this a committee's effort.
I will send the final plan tomorrow with the decision I made to move
forward.
Thanks everyone.
G
On Sun, Nov 24, 2019, 1:34 PM Ted Dunning <te...@gmail.com> wrote:
> Yeah...
>
> In fact, it essentially served as a survey about the survey mechanisms.
>
> On Sun, Nov 24, 2019 at 9:44 AM Matt Sicker <bo...@gmail.com> wrote:
>
> > Consider all the votes non-binding then. It's all informative
> nonetheless.
> >
> > On Sat, 23 Nov 2019 at 23:48, Ted Dunning <te...@gmail.com> wrote:
> > >
> > > There wasn't actually any reason to call for a vote.
> > >
> > > That didn't stop it being called for.
> > >
> > > On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > Niclas is absolutely correct here. The decision belongs to Gris.
> > She
> > > > may
> > > > > treat the results of the vote any way she pleases. I believe she
> has
> > > > > already expressed a preference. There is no deadlock here.
> > > >
> > > > Why call for a vote then?
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Ted Dunning <te...@gmail.com>.
Yeah...
In fact, it essentially served as a survey about the survey mechanisms.
On Sun, Nov 24, 2019 at 9:44 AM Matt Sicker <bo...@gmail.com> wrote:
> Consider all the votes non-binding then. It's all informative nonetheless.
>
> On Sat, 23 Nov 2019 at 23:48, Ted Dunning <te...@gmail.com> wrote:
> >
> > There wasn't actually any reason to call for a vote.
> >
> > That didn't stop it being called for.
> >
> > On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> > > Hi,
> > >
> > > > Niclas is absolutely correct here. The decision belongs to Gris.
> She
> > > may
> > > > treat the results of the vote any way she pleases. I believe she has
> > > > already expressed a preference. There is no deadlock here.
> > >
> > > Why call for a vote then?
> > >
> > > Thanks,
> > > Justin
> > >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Matt Sicker <bo...@gmail.com>.
Consider all the votes non-binding then. It's all informative nonetheless.
On Sat, 23 Nov 2019 at 23:48, Ted Dunning <te...@gmail.com> wrote:
>
> There wasn't actually any reason to call for a vote.
>
> That didn't stop it being called for.
>
> On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > Niclas is absolutely correct here. The decision belongs to Gris. She
> > may
> > > treat the results of the vote any way she pleases. I believe she has
> > > already expressed a preference. There is no deadlock here.
> >
> > Why call for a vote then?
> >
> > Thanks,
> > Justin
> >
--
Matt Sicker <bo...@gmail.com>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity and Inclusion
Posted by Gris Cuevas <gr...@apache.org>.
Hi folks,
As per the original message where I opened the vote, I closed it on Friday, and based on the input we received, we had:
4 people voted +1
1 person voted -1
1 person voted +0
So the voted passed, also as per indicated in this thread, even when the vote wasn't binding, I wanted to provide it as a means to discuss sensitive and critical aspects we have documented well and have find ways to protect and respond to in case it's needed.
I have created an entrey in the Wiki [1] where the plan can be read in an organized way as per Craig's suggestion.
I'll send an email with the plat to board-private@, If I see it necessary we can also send one to board@. The reason to email the private list is to give people actually in the board visibility before the launch.
Thanks and happy holidays everyone!
G
P.S. Big shout out to all the people who made this survey possible. It's been a great exercise and I hope we het great results out of it!
[1] https://cwiki.apache.org/confluence/display/EDI/The+2020+ASF+Community+Survey+-+Launch+Plan
On 2019/11/24 12:03:43, "Kevin A. McGrail" <km...@apache.org> wrote:
> The vote was to demonstrate consensus and done based on Sam's input on the
> matter.
>
> The vote isn't binding but that doesn't mean it is unnecessary. It helps
> guide the VP and alert members of the group to what's going on.
>
> It also helps put a deadline on debate so that things aren't endlessly
> debated.
>
> Regards, KAM
>
> On Sun, Nov 24, 2019, 00:48 Ted Dunning <te...@gmail.com> wrote:
>
> > There wasn't actually any reason to call for a vote.
> >
> > That didn't stop it being called for.
> >
> > On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> > > Hi,
> > >
> > > > Niclas is absolutely correct here. The decision belongs to Gris. She
> > > may
> > > > treat the results of the vote any way she pleases. I believe she has
> > > > already expressed a preference. There is no deadlock here.
> > >
> > > Why call for a vote then?
> > >
> > > Thanks,
> > > Justin
> > >
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
The vote was to demonstrate consensus and done based on Sam's input on the
matter.
The vote isn't binding but that doesn't mean it is unnecessary. It helps
guide the VP and alert members of the group to what's going on.
It also helps put a deadline on debate so that things aren't endlessly
debated.
Regards, KAM
On Sun, Nov 24, 2019, 00:48 Ted Dunning <te...@gmail.com> wrote:
> There wasn't actually any reason to call for a vote.
>
> That didn't stop it being called for.
>
> On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > Niclas is absolutely correct here. The decision belongs to Gris. She
> > may
> > > treat the results of the vote any way she pleases. I believe she has
> > > already expressed a preference. There is no deadlock here.
> >
> > Why call for a vote then?
> >
> > Thanks,
> > Justin
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Ted Dunning <te...@gmail.com>.
There wasn't actually any reason to call for a vote.
That didn't stop it being called for.
On Sat, Nov 23, 2019 at 1:29 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Niclas is absolutely correct here. The decision belongs to Gris. She
> may
> > treat the results of the vote any way she pleases. I believe she has
> > already expressed a preference. There is no deadlock here.
>
> Why call for a vote then?
>
> Thanks,
> Justin
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Niclas is absolutely correct here. The decision belongs to Gris. She may
> treat the results of the vote any way she pleases. I believe she has
> already expressed a preference. There is no deadlock here.
Why call for a vote then?
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Myrle Krantz <my...@apache.org>.
Niclas is absolutely correct here. The decision belongs to Gris. She may
treat the results of the vote any way she pleases. I believe she has
already expressed a preference. There is no deadlock here.
Best,
Myrle
On Sat, Nov 23, 2019 at 10:56 AM Niclas Hedhman <ni...@hedhman.org> wrote:
> Did I miss the formation of a PMC? AFAIK, there is no PMC, and Gris is
> treating the participation any way she likes.
>
> A. Appoint the Vice President, Diversity and Inclusion
>
> WHEREAS, the Board of Directors deems it to be in the best interests
> of the Foundation and consistent with the Foundation's purpose to
> appoint a Vice President, Diversity and Inclusion, responsible for
> diversity and inclusion matters, including but not limited to
> strategic planning, providing a framework and tools to support
> diversity and inclusion initiatives, and advising communities on
> matters related to diversity and inclusion; and
> <snip/>
>
> On Sat, Nov 23, 2019 at 5:20 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > Knowing the response rate anonymously is important and using a mailing
> > list
> > > will not let that happen.
> >
> > Yes it will we know how many are subscribed and we’ll know how many
> people
> > have filled it in.
> >
> > > Perfection is the enemy of progress. Please make a vote.
> >
> > I’m +0 because of the risks involved (compared to just sending it to a
> > mailing list) and the concerns that it could be perceived as a means of
> > tracking responses.
> >
> > Perhaps provided a means to opt out of this external list would be
> useful?
> > I also note (again) that only PMC votes are binding.
> >
> > Thanks.
> > Justin
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@me.com.INVALID>.
Hi,
> Did I miss the formation of a PMC? AFAIK, there is no PMC, and Gris is
> treating the participation any way she likes.
Sorry I misspoke, people on the committee votes shod be binding. [1]
Thanks,
Justin
1. https://whimsy.apache.org/roster/nonpmc/diversity
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Niclas Hedhman <ni...@hedhman.org>.
Did I miss the formation of a PMC? AFAIK, there is no PMC, and Gris is
treating the participation any way she likes.
A. Appoint the Vice President, Diversity and Inclusion
WHEREAS, the Board of Directors deems it to be in the best interests
of the Foundation and consistent with the Foundation's purpose to
appoint a Vice President, Diversity and Inclusion, responsible for
diversity and inclusion matters, including but not limited to
strategic planning, providing a framework and tools to support
diversity and inclusion initiatives, and advising communities on
matters related to diversity and inclusion; and
<snip/>
On Sat, Nov 23, 2019 at 5:20 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Knowing the response rate anonymously is important and using a mailing
> list
> > will not let that happen.
>
> Yes it will we know how many are subscribed and we’ll know how many people
> have filled it in.
>
> > Perfection is the enemy of progress. Please make a vote.
>
> I’m +0 because of the risks involved (compared to just sending it to a
> mailing list) and the concerns that it could be perceived as a means of
> tracking responses.
>
> Perhaps provided a means to opt out of this external list would be useful?
> I also note (again) that only PMC votes are binding.
>
> Thanks.
> Justin
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Knowing the response rate anonymously is important and using a mailing list
> will not let that happen.
Yes it will we know how many are subscribed and we’ll know how many people have filled it in.
> Perfection is the enemy of progress. Please make a vote.
I’m +0 because of the risks involved (compared to just sending it to a mailing list) and the concerns that it could be perceived as a means of tracking responses.
Perhaps provided a means to opt out of this external list would be useful? I also note (again) that only PMC votes are binding.
Thanks.
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
Limesurvey is an oss project so cves don't imply issues with their firm and
I see it as a good sign of transparency.
I don't think Gris or Bitergia will misuse the data and I think limesurvey
is a reputable company that seems to take security seriously.
Knowing the response rate anonymously is important and using a mailing list
will not let that happen. That alone is enough reason to do it
differently. It also removes concerns that those people are duplicating
entries because (love the term) it is tokenwalled.
Perfection is the enemy of progress. Please make a vote. I started the
first vote on Nov 5 and we are in paralysis analysis I fear.
Regards, KAM
On Fri, Nov 22, 2019, 16:27 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> > Preface: I think the statement of misuse potential is an insult to the
> > people involved.
>
> We’ve had several groups misuse data like this in the past and like all
> software LimeSurvey has security issues [1]. The risk may be low but it
> exists.
>
> > However, they then created their list by scraping public sources of
> Apache
> > org addresses and I cut the speaker from our event where they were to
> > present the results.
>
> I believe they created a list than included non apache.org emails as
> well, i.e. emails people used on the lists. That which probably get a
> better response rate and a number of angry emails.
>
> Take a list at random I can see that about 20% of the email is from an
> apache.org address, most people tend to use other address other than
> their apache.org email.
>
> Thanks,
> Justin
>
> 1.
> https://www.cvedetails.com/vulnerability-list/vendor_id-6900/Limesurvey.html
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Preface: I think the statement of misuse potential is an insult to the
> people involved.
We’ve had several groups misuse data like this in the past and like all software LimeSurvey has security issues [1]. The risk may be low but it exists.
> However, they then created their list by scraping public sources of Apache
> org addresses and I cut the speaker from our event where they were to
> present the results.
I believe they created a list than included non apache.org emails as well, i.e. emails people used on the lists. That which probably get a better response rate and a number of angry emails.
Take a list at random I can see that about 20% of the email is from an apache.org address, most people tend to use other address other than their apache.org email.
Thanks,
Justin
1. https://www.cvedetails.com/vulnerability-list/vendor_id-6900/Limesurvey.html
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
Preface: I think the statement of misuse potential is an insult to the
people involved.
However, we have easy and simple precedent about the response rate
comparing the mailing list vs direct. Specifically, with the survey that
went rogue in the summer of 2018, the response rates were dramatically
higher when they emailed directly. They went rogue because they didn't
receive statistically relevant responses using the lists.
However, they then created their list by scraping public sources of Apache
org addresses and I cut the speaker from our event where they were to
present the results.
That survey was about work experience so I won't posit on the response
rates for this survey. I would say we would want to collect a
statistically viable sample and comparable or in excess of 2016.
Regards, KAM
On Fri, Nov 22, 2019, 03:55 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> > People filter those more often.
>
> I’m not sure how other people use filters but I tend to use them for a)
> emails that I want to pay more attention and respond right away and b)
> emails that I’ll look at at a later time. I filter emails sent to my
> apache.org address but don’t filter those sent to committers@.
>
> I think that sending emails directly to apache addresses will result in
> less responses (based on my experience) and given previous history of how
> external people have used lists of address I’m concerned the list will be
> misused.
>
> Perhaps the better question to ask is what is the response rate we expect
> or hope for? What rate is needed for the results to be statistically
> significant? We could for instance start with a) and if we don’t get the
> repose rate we need switch to b),
>
> I am also happy to go along with what the wider PMC think on how we should
> approached this.
>
> Thanks,
> Justin
>
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> People filter those more often.
I’m not sure how other people use filters but I tend to use them for a) emails that I want to pay more attention and respond right away and b) emails that I’ll look at at a later time. I filter emails sent to my apache.org address but don’t filter those sent to committers@.
I think that sending emails directly to apache addresses will result in less responses (based on my experience) and given previous history of how external people have used lists of address I’m concerned the list will be misused.
Perhaps the better question to ask is what is the response rate we expect or hope for? What rate is needed for the results to be statistically significant? We could for instance start with a) and if we don’t get the repose rate we need switch to b),
I am also happy to go along with what the wider PMC think on how we should approached this.
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Nov 22, 2019 at 1:38 PM Griselda Cuevas <gr...@apache.org> wrote:
> >
> > IMO An email to committers it liker to get a higher response rate than
> one
> > sent to all the apache email addresses. I’ve sent emails out to groups of
> > apache emails addresses before and got a low rate of repose. Why do you
> > think an email to committers it would get less responses?
>
>
> People filter those more often.
>
Citation, please...
// Niclas
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Griselda Cuevas <gr...@apache.org>.
>
> IMO An email to committers it liker to get a higher response rate than one
> sent to all the apache email addresses. I’ve sent emails out to groups of
> apache emails addresses before and got a low rate of repose. Why do you
> think an email to committers it would get less responses?
People filter those more often.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> I also haven't hear from legal-discuss on the gift card side, so it looks
> like we won't have an incentive program for the survey. If this is combines
> with a general email to committers@, we are basically setting ourselves up
> for lower and lower response rate.
IMO An email to committers it liker to get a higher response rate than one sent to all the apache email addresses. I’ve sent emails out to groups of apache emails addresses before and got a low rate of repose. Why do you think an email to committers it would get less responses?
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Griselda Cuevas <gr...@apache.org>.
We have a case where all options have pros and cons.
We are also discussing the possible scenarios for two different sets of
participants: committers and non-committers.
To Patricia's earlier points. The only way to avoid spamming people is to
email directly to apache.org accounts. This is the solution I feel the most
comfortable with, since those email addresses belong to the apache.org
domain and the survey could fall under the program notification category in
the Can-Spam act. I am actually investigating this. This approach also
provides a unique token that would prevent people from filling a survey
multiple times.
For non-committers, the solution I feel most comfortable with is the open
universal token. I think the risk of having people filling multiple surveys
is low, and I am willing to take on the cons there.
From all the options, the risks of the current proposal is the less costly
and less risky.
I also haven't hear from legal-discuss on the gift card side, so it looks
like we won't have an incentive program for the survey. If this is combines
with a general email to committers@, we are basically setting ourselves up
for lower and lower response rate.
Craig, could you outline your questions or aspects you would like the doc
to clarify?
On Thu, Nov 21, 2019, 8:05 PM Patricia Shanahan <pa...@acm.org> wrote:
>
>
> On 11/21/2019 7:39 PM, Craig Russell wrote:
> > Hi Georg,
> >
> >> On Nov 21, 2019, at 7:33 PM, Georg Link <li...@gmail.com> wrote:
> >>
> >>> 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.
> >>
> >> Tricky. If we share one link on social media, then everyone using that
> same link expects to take the survey. We cannot prevent anyone from taking
> the survey again. I do not like to add a separate step of requesting to
> participate and then us manually sending out personalized invites.
> >
> > I thought that this would be the trickiest part.
> >
> > I thought that it might be possible to send an individual invitation to
> each person that we either know of (email address from our committer base)
> or who requests a survey for their specific email address (non-committer
> contributor) and we could then send an immutable survey ID.
>
> I have several e-mail addresses, and could create a lot more if I wanted
> to. A human might get suspicious of a lot of survey requests from domain
> patriciashanahan.com, but would your scripts?
>
> > Is there any other way to discourage if not eliminate multiple responses?
>
> Just ask people to only respond once.
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/21/2019 7:39 PM, Craig Russell wrote:
> Hi Georg,
>
>> On Nov 21, 2019, at 7:33 PM, Georg Link <li...@gmail.com> wrote:
>>
>>> 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.
>>
>> Tricky. If we share one link on social media, then everyone using that same link expects to take the survey. We cannot prevent anyone from taking the survey again. I do not like to add a separate step of requesting to participate and then us manually sending out personalized invites.
>
> I thought that this would be the trickiest part.
>
> I thought that it might be possible to send an individual invitation to each person that we either know of (email address from our committer base) or who requests a survey for their specific email address (non-committer contributor) and we could then send an immutable survey ID.
I have several e-mail addresses, and could create a lot more if I wanted
to. A human might get suspicious of a lot of survey requests from domain
patriciashanahan.com, but would your scripts?
> Is there any other way to discourage if not eliminate multiple responses?
Just ask people to only respond once.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <ke...@apache.org> 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 <ka...@gmail.com>
> 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 <km...@apache.org>
> > 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 <gr...@apache.org> 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" <km...@apache.org>
> > 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 <rubys@intertwingly.net
> > > > > >> <ma...@intertwingly.net>> wrote:
> > > > > >>
> > > > > >> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> > > > > >> <kmcgrail@apache.org <ma...@apache.org>> 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
> > > > > >> > KMcGrail@Apache.org
> > > > > >> >
> > > > > >> > Member, Apache Software Foundation
> > > > > >> > Chair Emeritus Apache SpamAssassin Project
> > > > > >> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > <(703)%20798-0171>
> > > > > >> >
> > > > > >>
> > > > > > --
> > > > > > Kevin A. McGrail
> > > > > > KMcGrail@Apache.org
> > > > > >
> > > > > > Member, Apache Software Foundation
> > > > > > Chair Emeritus Apache SpamAssassin Project
> > > > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > <(703)%20798-0171>
> > > > >
> > > > > --
> > > > > Kevin A. McGrail
> > > > > KMcGrail@Apache.org
> > > > >
> > > > > 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
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Kenneth Knowles <ke...@apache.org>.
+1
I appreciate the diligence of thought, and patience explaining the
rationale.
Kenn
On Tue, Nov 19, 2019 at 7:55 AM Katia Rojas <ka...@gmail.com> 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 <km...@apache.org>
> 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 <gr...@apache.org> 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" <km...@apache.org>
> 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 <rubys@intertwingly.net
> > > > >> <ma...@intertwingly.net>> wrote:
> > > > >>
> > > > >> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> > > > >> <kmcgrail@apache.org <ma...@apache.org>> 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
> > > > >> > KMcGrail@Apache.org
> > > > >> >
> > > > >> > Member, Apache Software Foundation
> > > > >> > Chair Emeritus Apache SpamAssassin Project
> > > > >> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> <(703)%20798-0171>
> > > > >> >
> > > > >>
> > > > > --
> > > > > Kevin A. McGrail
> > > > > KMcGrail@Apache.org
> > > > >
> > > > > Member, Apache Software Foundation
> > > > > Chair Emeritus Apache SpamAssassin Project
> > > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> <(703)%20798-0171>
> > > >
> > > > --
> > > > Kevin A. McGrail
> > > > KMcGrail@Apache.org
> > > >
> > > > Member, Apache Software Foundation
> > > > Chair Emeritus Apache SpamAssassin Project
> > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> <(703)%20798-0171>
> > > >
> > > >
> > >
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Katia Rojas <ka...@gmail.com>.
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 <km...@apache.org>
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
>
>
> On Mon, Nov 18, 2019 at 5:59 PM Gris Cuevas <gr...@apache.org> 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" <km...@apache.org> 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 <rubys@intertwingly.net
> > > >> <ma...@intertwingly.net>> wrote:
> > > >>
> > > >> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> > > >> <kmcgrail@apache.org <ma...@apache.org>> 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
> > > >> > KMcGrail@Apache.org
> > > >> >
> > > >> > Member, Apache Software Foundation
> > > >> > Chair Emeritus Apache SpamAssassin Project
> > > >> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > > >> >
> > > >>
> > > > --
> > > > Kevin A. McGrail
> > > > KMcGrail@Apache.org
> > > >
> > > > Member, Apache Software Foundation
> > > > Chair Emeritus Apache SpamAssassin Project
> > > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > >
> > > --
> > > Kevin A. McGrail
> > > KMcGrail@Apache.org
> > >
> > > Member, Apache Software Foundation
> > > Chair Emeritus Apache SpamAssassin Project
> > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > >
> > >
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
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
On Mon, Nov 18, 2019 at 5:59 PM Gris Cuevas <gr...@apache.org> 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" <km...@apache.org> 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 <rubys@intertwingly.net
> > >> <ma...@intertwingly.net>> wrote:
> > >>
> > >> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> > >> <kmcgrail@apache.org <ma...@apache.org>> 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
> > >> > KMcGrail@Apache.org
> > >> >
> > >> > Member, Apache Software Foundation
> > >> > Chair Emeritus Apache SpamAssassin Project
> > >> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> > >> >
> > >>
> > > --
> > > Kevin A. McGrail
> > > KMcGrail@Apache.org
> > >
> > > Member, Apache Software Foundation
> > > Chair Emeritus Apache SpamAssassin Project
> > > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> > --
> > Kevin A. McGrail
> > KMcGrail@Apache.org
> >
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> >
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
> On Nov 21, 2019, at 9:39 PM, Craig Russell <ap...@gmail.com> wrote:
>
>> On Nov 21, 2019, at 7:33 PM, Georg Link <li...@gmail.com> wrote:
>>
>>> 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.
>>
>> Tricky. If we share one link on social media, then everyone using that same link expects to take the survey. We cannot prevent anyone from taking the survey again. I do not like to add a separate step of requesting to participate and then us manually sending out personalized invites.
>
> I thought that this would be the trickiest part.
>
> I thought that it might be possible to send an individual invitation to each person that we either know of (email address from our committer base) or who requests a survey for their specific email address (non-committer contributor) and we could then send an immutable survey ID.
>
Yes, we can. But that would not allow us to have a public survey. The survey would be behind a “token-wall” (I just made up that word). Every participant would need to either enter their unique token or use a link that already contains their token.
This would make it difficult to advertise the survey on social media, because we would not have a link to share for directly taking the survey.
I recommend to keep the survey open and risk that someone provides multiple responses. I believe the benefit of having an open survey and inviting everyone outweighs the risk (but I don’t know everyone in the ASF community to accurately make a prediction).
> Is there any other way to discourage if not eliminate multiple responses?
Technically, not if we want to encourage everyone to participate, even though social media.
Socially, yes. We can draw attention to the fact that multiple answers are possible and then tell people not to use that possibility. Seems counterproductive though.
Do you have someone in mind that wants their specific demographic information to be counted several times? Or someone who wants to dilute the responses? It would require answering 20+ questions multiple times — quite a bit of effort.
--
Georg Link
(he/him)
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Craig Russell <ap...@gmail.com>.
Hi Georg,
> On Nov 21, 2019, at 7:33 PM, Georg Link <li...@gmail.com> wrote:
>
>> 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.
>
> Tricky. If we share one link on social media, then everyone using that same link expects to take the survey. We cannot prevent anyone from taking the survey again. I do not like to add a separate step of requesting to participate and then us manually sending out personalized invites.
I thought that this would be the trickiest part.
I thought that it might be possible to send an individual invitation to each person that we either know of (email address from our committer base) or who requests a survey for their specific email address (non-committer contributor) and we could then send an immutable survey ID.
Is there any other way to discourage if not eliminate multiple responses?
Craig
Craig L Russell
clr@apache.org
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
Hi Craig,
>
> 1. We should have a way to track response counts to the survey.
LimeSurvey will give us the number of responses.
>
> 2. We should allow non-committers to request a survey and encourage PMCs and podlings to have their contributors request a survey.
The plan is to advertise the survey in several channels and to allow anyone to respond.
>
> 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.
Tricky. If we share one link on social media, then everyone using that same link expects to take the survey. We cannot prevent anyone from taking the survey again. I do not like to add a separate step of requesting to participate and then us manually sending out personalized invites.
>
> 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
All responses are anonymous. LimeSurvey does not connect survey replies with the person who responded.
The only way to know who responded is if they provide their email address for the gift card or to be contacted for a follow-up interview. We will separate that data before sharing it, of course.
>
> 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
Here is the document that we are building the survey from: https://docs.google.com/document/d/17HqY9RdaYqy8tjvYu72gCoLKI870_CPiSGpR7FGleG0/edit# <https://docs.google.com/document/d/17HqY9RdaYqy8tjvYu72gCoLKI870_CPiSGpR7FGleG0/edit#>
Best,
Georg
--
Georg Link
(he/him)
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Craig Russell <ap...@gmail.com>.
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 <gr...@apache.org> 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" <km...@apache.org> 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 <rubys@intertwingly.net
>>>> <ma...@intertwingly.net>> wrote:
>>>>
>>>> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
>>>> <kmcgrail@apache.org <ma...@apache.org>> 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
>>>>> KMcGrail@Apache.org
>>>>>
>>>>> Member, Apache Software Foundation
>>>>> Chair Emeritus Apache SpamAssassin Project
>>>>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>>>>>
>>>>
>>> --
>>> Kevin A. McGrail
>>> KMcGrail@Apache.org
>>>
>>> Member, Apache Software Foundation
>>> Chair Emeritus Apache SpamAssassin Project
>>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>>
>> --
>> Kevin A. McGrail
>> KMcGrail@Apache.org
>>
>> Member, Apache Software Foundation
>> Chair Emeritus Apache SpamAssassin Project
>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>>
>>
Craig L Russell
clr@apache.org
Re: Vote on Technical Approach for Survey was Re: Survey Diversity and Inclusion
Posted by Gris Cuevas <gr...@apache.org>.
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" <km...@apache.org> 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 <rubys@intertwingly.net
> >> <ma...@intertwingly.net>> wrote:
> >>
> >> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> >> <kmcgrail@apache.org <ma...@apache.org>> 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
> >> > KMcGrail@Apache.org
> >> >
> >> > Member, Apache Software Foundation
> >> > Chair Emeritus Apache SpamAssassin Project
> >> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >> >
> >>
> > --
> > Kevin A. McGrail
> > KMcGrail@Apache.org
> >
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
> --
> Kevin A. McGrail
> KMcGrail@Apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <rubys@intertwingly.net
>> <ma...@intertwingly.net>> wrote:
>>
>> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
>> <kmcgrail@apache.org <ma...@apache.org>> 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
>> > KMcGrail@Apache.org
>> >
>> > Member, Apache Software Foundation
>> > Chair Emeritus Apache SpamAssassin Project
>> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
>> >
>>
> --
> Kevin A. McGrail
> KMcGrail@Apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Myrle Krantz <my...@apache.org>.
On Wed, Nov 6, 2019 at 7:03 PM Kevin A. McGrail <km...@apache.org> wrote:
> The list will be all availids.
>
> There are numerous ways it helps spamming because for 1, people replying
> with questions won't spm 7k other people.
>
Committers is moderated. So replying with questions to an email sent to
committers won't spam anyone but the moderators. (poor moderators)
>
> Infra will generate the list. I expect it to be a trivial ldap to csv.
>
I feel like before the discussion on technical solutions gets too advanced
someone should decide whether we're targeting committers or contributors.
Both have advantages and disadvantages. I'm not adamant about either way.
But it doesn't seem to me right now that there is consensus yet on that
question.
Best,
Myrle
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The list will be all availids.
Is that all emails people have subscribed to all lists or just certain lists? Or something based on Apache IDs? Or what's recorded in LDAP? Each of this is going to generate a different set of email addresses.
Some things that come to mind. Have these been considered?
- Some contributors do not have an Apache ID / are not in LDAP. (You get one when you become a committer.)
- Some people have subscribed under multiple emails addresses to different lists
- Emails address people use are not always the ones recorded in ldap (see for instance see the number of PMCs recorded as not signed up to their private lists as reported by Whimsy, when they have just signed up via other addresses).
- People have multiple email address recorded in LDAP
If instance if I look myself up LDAP it has several email addresses for me, but I also use other non recorded email addresses to subscribe to some lists.
> There are numerous ways it helps spamming because for 1, people replying
> with questions won't spm 7k other people.
We currently have 7131 committers, if you included contributors it would be double that (or more). It’s still unclear how wide this group is that the survey link will sent to using this method. When sending to a list the reply to address could be set so that people don’t spam each other. I assume we would want replies to go to the dev@diversity list, if people have any questions about the survey or are having trouble filling it in we can answer them.
> Infra will generate the list. I expect it to be a trivial ldap to csv.
Our contributors are not (that I’m aware) stored in LDAP, only committers are.
> For the social media and pmc posts, we would use a single reusable survey
> token.
So we are posting to the lists as well? It might be best to put exactly what the plan is on a wiki page so everyone is clear what is expected to happen.
Thanks,.
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
The list will be all availids.
There are numerous ways it helps spamming because for 1, people replying
with questions won't spm 7k other people.
Infra will generate the list. I expect it to be a trivial ldap to csv.
For the social media and pmc posts, we would use a single reusable survey
token.
All still anonymous but will let us get some insight into response rates.
Regards, KAM
On Wed, Nov 6, 2019, 07:02 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I think a little more information is needed before we can vote on this.
>
> > The goal of this change is technical to limit spamming
>
> How exactly does this limit spamming? Is the list sent to to a subset of
> the committers list or larger than it?
>
> > 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.
>
> How is this contributor list (which i assume is what you mean rather than
> committers) going to be determined / generated? It’s been mentioned several
> times that we want people other than committers to be contacted and fill in
> the survey.
>
> > We should also still allow anonymous entries, ask PMCs to post about the
> > survey and spread the word on our social media.
>
> I’m not familiar with the platform, but is this possible when each link to
> fill in the survey (as I understand it) needs a unique token?
>
> Thanks,
> Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
Hi Justin,
>
>> We should also still allow anonymous entries, ask PMCs to post about the
>> survey and spread the word on our social media.
>
> I’m not familiar with the platform, but is this possible when each link to fill in the survey (as I understand it) needs a unique token?
No.
LimeSurvey has a setting to allow multiple replies from the same token.
Because all responses are anonymous, we cannot track which token was used for a particular reply.
However, through the tokens, we can track who used the token to reply to the survey.
As I just sent in another email, we need to enable “multiple replies for a token” if we want to share the link on social media.
Best,
Georg
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I think a little more information is needed before we can vote on this.
> The goal of this change is technical to limit spamming
How exactly does this limit spamming? Is the list sent to to a subset of the committers list or larger than it?
> 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.
How is this contributor list (which i assume is what you mean rather than committers) going to be determined / generated? It’s been mentioned several times that we want people other than committers to be contacted and fill in the survey.
> We should also still allow anonymous entries, ask PMCs to post about the
> survey and spread the word on our social media.
I’m not familiar with the platform, but is this possible when each link to fill in the survey (as I understand it) needs a unique token?
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
That is effectively the original plan.
On Wed, Nov 6, 2019, 16:58 Georg Link <li...@gmail.com> wrote:
> I like Ted’s proposed option 3. - Good thinking!
>
> Two identical surveys and we combine the responses for the analysis.
> Survey 1: @apache emails, personalized invite links, no duplicate replies
> allowed, response rate tracking
> Survey 2: completely open for social media and other channels
>
>
>
> > On Nov 6, 2019, at 3:43 PM, Ted Dunning <te...@gmail.com> wrote:
> >
> > On Wed, Nov 6, 2019 at 1:20 PM Georg Link <linkgeorg@gmail.com <mailto:
> linkgeorg@gmail.com>> wrote:
> >
> >>
> >>> On Nov 6, 2019, at 2:19 PM, Justin Mclean <ju...@classsoftware.com>
> >> 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.
>
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
I like Ted’s proposed option 3. - Good thinking!
Two identical surveys and we combine the responses for the analysis.
Survey 1: @apache emails, personalized invite links, no duplicate replies allowed, response rate tracking
Survey 2: completely open for social media and other channels
> On Nov 6, 2019, at 3:43 PM, Ted Dunning <te...@gmail.com> wrote:
>
> On Wed, Nov 6, 2019 at 1:20 PM Georg Link <linkgeorg@gmail.com <ma...@gmail.com>> wrote:
>
>>
>>> On Nov 6, 2019, at 2:19 PM, Justin Mclean <ju...@classsoftware.com>
>> 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.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Griselda Cuevas <gr...@apache.org>.
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 <te...@gmail.com> wrote:
> On Wed, Nov 6, 2019 at 1:20 PM Georg Link <li...@gmail.com> wrote:
>
> >
> > > On Nov 6, 2019, at 2:19 PM, Justin Mclean <ju...@classsoftware.com>
> > 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.
>
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Ted Dunning <te...@gmail.com>.
On Wed, Nov 6, 2019 at 1:20 PM Georg Link <li...@gmail.com> wrote:
>
> > On Nov 6, 2019, at 2:19 PM, Justin Mclean <ju...@classsoftware.com>
> 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.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
> On Nov 6, 2019, at 2:19 PM, Justin Mclean <ju...@classsoftware.com> 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 2 would be identical with using a third-party email service to send personalized emails.
If ASF had the ability to send individual emails, that could be used without loading all email addresses into LimeSurvey.
>
> Does anything stops people filling in multiple responses?
No.
The only way we can have that control is to limit responses to invited people.
This would eliminate our option for spreading the word via social media and mailing lists.
>
>> We could use different “dummy” participants to share with different social media (or PMCs) to track how effective the outreach is for each channel.
>
> Again some people may be uncomfortable with any form of tracking.
>
I was merely pointing out the option. We don’t have to do this.
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
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.
Does anything stops people filling in multiple responses?
> We could use different “dummy” participants to share with different social media (or PMCs) to track how effective the outreach is for each channel.
Again some people may be uncomfortable with any form of tracking.
Thanks,
Justin
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Georg Link <li...@gmail.com>.
Thank you Kevin for evaluating the use of LimeSurvey.
Comments in-line below:
> 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."
Yes, that is how Bitergia set up the survey.
> We should also still allow anonymous entries, ask PMCs to post about the
> survey and spread the word on our social media.
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.
The challenge is that all respondents need to use a token.
My proposal is to create a “dummy” participant and we use it’s token for social media.
I did a test and we can enable multiple answers with the same token, which is required for my proposal.
We could use different “dummy” participants to share with different social media (or PMCs) to track how effective the outreach is for each channel.
Best,
Georg
Re: Vote on Technical Approach for Survey was Re: Survey Diversity
and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
The english privacy policy that was posted before can be found here [1] It seems to be about their website not about any email addresses we provide them with or their survey system. Do we know how they treat that data?
Thanks,
Justin
1. https://www.limesurvey.org/policies/privacy-policy
Vote on Technical Approach for Survey was Re: Survey Diversity and
Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <rubys@intertwingly.net
> <ma...@intertwingly.net>> wrote:
>
> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail
> <kmcgrail@apache.org <ma...@apache.org>> 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
> > KMcGrail@Apache.org
> >
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
>
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Survey Diversity and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
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 <ru...@intertwingly.net> wrote:
> On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail <km...@apache.org>
> 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
> > 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
> > KMcGrail@Apache.org
> >
> > Member, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
>
Re: Survey Diversity and Inclusion
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Nov 2, 2019 at 10:26 AM Kevin A. McGrail <km...@apache.org> 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
> 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
> KMcGrail@Apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
Re: Survey Diversity and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
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
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.
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
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Survey Diversity and Inclusion
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Re: Survey Diversity and Inclusion
Posted by "Kevin A. McGrail" <km...@apache.org>.
I am personally checking the tos and doing a review to advise on the use of
the software in question. The software is limesurvey in a saas model
controlled by us.
On Fri, Nov 1, 2019, 21:49 Niclas Hedhman <ni...@hedhman.org> wrote:
> I object to uploading our email database to third-party. That is
> effectively "selling email addresses" at $0 and something we should avoid.
>
> If "survey software" is something that we run on ASF hardware and can
> guarantee doesn't forward this elsewhere, then I withdraw the objection.
>
> Thanks
> Niclas
>
> On Sat, Nov 2, 2019 at 2:00 AM Griselda Cuevas <gr...@apache.org> wrote:
>
> > Thanks for the feedback everyone, we're evaluating the best alternative
> to
> > reach the most committers and contributors.
> >
> > Kevin is helping us determine if we can do a direct upload of apache.org
> > email addresses to the survey software directly. If we determine this is
> a
> > safe procedure, we'll do that instead of the email to committers@
> >
> > We will still send a note to pmcs@ asking them to share a link to the
> > survey with their mailing lists. The message will be different, so I
> > wouldn't worry about duplication or spam.
> >
> > I will also work with Sally to write any comms.
> >
> > G
> >
> > On Fri, 1 Nov 2019 at 08:04, William A Rowe Jr <wr...@rowe-clan.net>
> > wrote:
> >
> > > On Mon, Oct 28, 2019 at 6:10 PM Patricia Shanahan <pa...@acm.org>
> wrote:
> > >
> > > > One danger that I don't know how to solve: In trying to reach as many
> > > > people as possible you will bombard many of us with multiple e-mails.
> > >
> > >
> > > Undoubtedly, but like many here, I'll end up seeing only one message.
> > >
> > >
> > > > I am subscribed to dev@diversity.a.o, members@, committers@, two PMC
> > > > private lists, and the corresponding dev@lists. I'm going to get
> > about 7
> > > > copies, and some people are subscribed to a lot more than 2 projects.
> > > >
> > >
> > > As a suggestion, committers@ are direct emails, which should entirely
> > > overlap
> > > the subset of everyone subscribed to members@ and private@ (therefore
> > > including the pmcs@ superset), and those members@ and private@ lists
> > > do not add value if the entire committers@ base will be solicited. So
> > > let's
> > > please not duplicate.
> > >
> > > Worried someone is filtering their committers@ traffic? Do we want to
> > > include other /active/ contributors who are not yet committers? Then
> > > it seems the dev@ lists are the most effective way to add people. But
> > > it might improve the situation if the initial committers@ appeal does
> > > include some text like the following;
> > >
> > > > This survey seeks the input of any Apache "contributor", even those
> > > > who are not committers. We seek your help to extend this invitation
> > > > with those who have contributed in some way to the projects you
> > > > participate in, or perhaps share with your communities' dev@ or
> > > > users@ list.
> > >
> > > For the message to come from a respected member of the project
> > > means that even though people will see multiple copies, these direct
> > > appeals will probably encourage more participation, especially by
> > > external contributors, but also perhaps by committers.
> > >
> >
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: Survey Diversity and Inclusion
Posted by Niclas Hedhman <ni...@hedhman.org>.
I object to uploading our email database to third-party. That is
effectively "selling email addresses" at $0 and something we should avoid.
If "survey software" is something that we run on ASF hardware and can
guarantee doesn't forward this elsewhere, then I withdraw the objection.
Thanks
Niclas
On Sat, Nov 2, 2019 at 2:00 AM Griselda Cuevas <gr...@apache.org> wrote:
> Thanks for the feedback everyone, we're evaluating the best alternative to
> reach the most committers and contributors.
>
> Kevin is helping us determine if we can do a direct upload of apache.org
> email addresses to the survey software directly. If we determine this is a
> safe procedure, we'll do that instead of the email to committers@
>
> We will still send a note to pmcs@ asking them to share a link to the
> survey with their mailing lists. The message will be different, so I
> wouldn't worry about duplication or spam.
>
> I will also work with Sally to write any comms.
>
> G
>
> On Fri, 1 Nov 2019 at 08:04, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
> > On Mon, Oct 28, 2019 at 6:10 PM Patricia Shanahan <pa...@acm.org> wrote:
> >
> > > One danger that I don't know how to solve: In trying to reach as many
> > > people as possible you will bombard many of us with multiple e-mails.
> >
> >
> > Undoubtedly, but like many here, I'll end up seeing only one message.
> >
> >
> > > I am subscribed to dev@diversity.a.o, members@, committers@, two PMC
> > > private lists, and the corresponding dev@lists. I'm going to get
> about 7
> > > copies, and some people are subscribed to a lot more than 2 projects.
> > >
> >
> > As a suggestion, committers@ are direct emails, which should entirely
> > overlap
> > the subset of everyone subscribed to members@ and private@ (therefore
> > including the pmcs@ superset), and those members@ and private@ lists
> > do not add value if the entire committers@ base will be solicited. So
> > let's
> > please not duplicate.
> >
> > Worried someone is filtering their committers@ traffic? Do we want to
> > include other /active/ contributors who are not yet committers? Then
> > it seems the dev@ lists are the most effective way to add people. But
> > it might improve the situation if the initial committers@ appeal does
> > include some text like the following;
> >
> > > This survey seeks the input of any Apache "contributor", even those
> > > who are not committers. We seek your help to extend this invitation
> > > with those who have contributed in some way to the projects you
> > > participate in, or perhaps share with your communities' dev@ or
> > > users@ list.
> >
> > For the message to come from a respected member of the project
> > means that even though people will see multiple copies, these direct
> > appeals will probably encourage more participation, especially by
> > external contributors, but also perhaps by committers.
> >
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Survey Diversity and Inclusion
Posted by Griselda Cuevas <gr...@apache.org>.
Hi folks - I'm adding Maria, who will help us draft a comprehensive comms
plan to outline what we have communicated in this thread.
Maria,
The plan so far is the following:
1. Send direct emails to all apache.org addresses OR to committers@
inviting them to fill the survey
2. Send a note to pmcs@ asking them to share the survey in their users@ and
dev@ lists
3. Social media promotion (in partnership w/ Sally)
Can you help us note this in the comms plan? Once you have it, you can
share w/ this list in a new thread to facilitate discussion on a single
topic.
Thanks,
G
On Fri, 1 Nov 2019 at 11:00, Griselda Cuevas <gr...@apache.org> wrote:
> Thanks for the feedback everyone, we're evaluating the best alternative to
> reach the most committers and contributors.
>
> Kevin is helping us determine if we can do a direct upload of apache.org
> email addresses to the survey software directly. If we determine this is a
> safe procedure, we'll do that instead of the email to committers@
>
> We will still send a note to pmcs@ asking them to share a link to the
> survey with their mailing lists. The message will be different, so I
> wouldn't worry about duplication or spam.
>
> I will also work with Sally to write any comms.
>
> G
>
> On Fri, 1 Nov 2019 at 08:04, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
>> On Mon, Oct 28, 2019 at 6:10 PM Patricia Shanahan <pa...@acm.org> wrote:
>>
>> > One danger that I don't know how to solve: In trying to reach as many
>> > people as possible you will bombard many of us with multiple e-mails.
>>
>>
>> Undoubtedly, but like many here, I'll end up seeing only one message.
>>
>>
>> > I am subscribed to dev@diversity.a.o, members@, committers@, two PMC
>> > private lists, and the corresponding dev@lists. I'm going to get about
>> 7
>> > copies, and some people are subscribed to a lot more than 2 projects.
>> >
>>
>> As a suggestion, committers@ are direct emails, which should entirely
>> overlap
>> the subset of everyone subscribed to members@ and private@ (therefore
>> including the pmcs@ superset), and those members@ and private@ lists
>> do not add value if the entire committers@ base will be solicited. So
>> let's
>> please not duplicate.
>>
>> Worried someone is filtering their committers@ traffic? Do we want to
>> include other /active/ contributors who are not yet committers? Then
>> it seems the dev@ lists are the most effective way to add people. But
>> it might improve the situation if the initial committers@ appeal does
>> include some text like the following;
>>
>> > This survey seeks the input of any Apache "contributor", even those
>> > who are not committers. We seek your help to extend this invitation
>> > with those who have contributed in some way to the projects you
>> > participate in, or perhaps share with your communities' dev@ or
>> > users@ list.
>>
>> For the message to come from a respected member of the project
>> means that even though people will see multiple copies, these direct
>> appeals will probably encourage more participation, especially by
>> external contributors, but also perhaps by committers.
>>
>
Re: Survey Diversity and Inclusion
Posted by Griselda Cuevas <gr...@apache.org>.
Thanks for the feedback everyone, we're evaluating the best alternative to
reach the most committers and contributors.
Kevin is helping us determine if we can do a direct upload of apache.org
email addresses to the survey software directly. If we determine this is a
safe procedure, we'll do that instead of the email to committers@
We will still send a note to pmcs@ asking them to share a link to the
survey with their mailing lists. The message will be different, so I
wouldn't worry about duplication or spam.
I will also work with Sally to write any comms.
G
On Fri, 1 Nov 2019 at 08:04, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Mon, Oct 28, 2019 at 6:10 PM Patricia Shanahan <pa...@acm.org> wrote:
>
> > One danger that I don't know how to solve: In trying to reach as many
> > people as possible you will bombard many of us with multiple e-mails.
>
>
> Undoubtedly, but like many here, I'll end up seeing only one message.
>
>
> > I am subscribed to dev@diversity.a.o, members@, committers@, two PMC
> > private lists, and the corresponding dev@lists. I'm going to get about 7
> > copies, and some people are subscribed to a lot more than 2 projects.
> >
>
> As a suggestion, committers@ are direct emails, which should entirely
> overlap
> the subset of everyone subscribed to members@ and private@ (therefore
> including the pmcs@ superset), and those members@ and private@ lists
> do not add value if the entire committers@ base will be solicited. So
> let's
> please not duplicate.
>
> Worried someone is filtering their committers@ traffic? Do we want to
> include other /active/ contributors who are not yet committers? Then
> it seems the dev@ lists are the most effective way to add people. But
> it might improve the situation if the initial committers@ appeal does
> include some text like the following;
>
> > This survey seeks the input of any Apache "contributor", even those
> > who are not committers. We seek your help to extend this invitation
> > with those who have contributed in some way to the projects you
> > participate in, or perhaps share with your communities' dev@ or
> > users@ list.
>
> For the message to come from a respected member of the project
> means that even though people will see multiple copies, these direct
> appeals will probably encourage more participation, especially by
> external contributors, but also perhaps by committers.
>