[llvm-dev] [RFC] GitHub Survey - Please review

[Renato Golin via llvm-dev]

Folks,

I've created the survey with the feedback I got on the "Voting" thread
in the llvm-foundation list, and put it here:

https://goo.gl/forms/k4J7M3N7oLNTOlDq2

Apparently, I can't allow people to comment on the form itself. It's
either full permission or nothing. So, I think the best way to do this
is to do a review on the list, with my most sincere apologies to the
anti-spam folks.

For that reason, I have only sent to llvm-dev, and would encourage
people to share privately with colleagues that didn't get it, via
lists, IRC, etc. Let's leave social media out of this, or we risk
having to filter out a lot of spam / trolls and make the whole
exercise moot.

People that have an interest on this question already subscribe to
this list or the IRC channel.


  The Plan

Today it's the 19th, so about the time I promised to put the survey up
for review. From today to the Sep 1st, we'll be filling the form,
trying out the questions, changing the wording, adding new questions,
etc.

If you guys could fill up with some data, see how it feels, and in the
end I'll try to share the bogus results, to see if that's what people
expected.

Around Sep 1st, The GitHub proposal should be finished (we'll have a
common document with both sub-modules and mono-repo explained), and
the survey should also be finished.

Since the survey has some free-text fields, it's less important how
precise is the writing, but we need to get the multiple-choice
questions right, to have a general idea of a "voting" mechanism.

My hope is that by Sep 1st, we'll have the GitHub proposal done and
the survey online for real, when I'll wipe out all responses and we'll
start fresh again.


  Design Choices

TL;DR, feel free to ignore this section...

Just FYI, the design choices for the survey were:

1. Request name, email and affiliation to de-duplicate the data. There
is no way to prevent people from responding twice without forcing them
to sign up on Google, which I will most certainly not do.

The identification also helps us to group people by their affiliations
and to have an idea of representation. I'm not expecting everyone on
the same group to have the same opinion, but it will be interesting to
see how they change.

Name and email will not be shared, but affiliation will (should it?).
I'm expecting the free-text descriptions to be very telling to that
respect, so there's no point is hiding it.

2. Gathering people's involvement in LLVM is important. We want to
know how much stake people have in LLVM, so we can weight more the
choices of people with more stake, but weight the same the *opinions*
of everyone.

What I mean by this is that, if most of the core developers feel
strongly towards using Git and a few external developers feel strongly
against, the people that will be using the most will have a higher
weight.

But the technical arguments of the minority is still weighted in the
same way as the vast majority, after all, they're *technical*
arguments and not *opinions*.

3. Separating "moving to Git/Github" from "using
mono-repo/sub-modules" is crucial. We may not get a consensus on the
latter, but we should get it for the former. It'll be much simpler for
a second iteration if we know we're going to use Git and GitHub and I
want to make sure we get this right.

If we have an overwhelmingly positive response to using GitHub, but
we're still divided to use sub-modules or mono-repo, we can close the
"move to Git" question now, and just work on the details later.

cheers,
--renato