[llvm-dev] [RFC] GitHub Survey - Please review
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 24 12:01:34 PDT 2016
> On Aug 19, 2016, at 4:23 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> I've created the survey with the feedback I got on the "Voting" thread
> in the llvm-foundation list, and put it here:
> 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,
> 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
> 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.
I’m not sure what value we’ll get from these data without a free text field for *every* question.
For example, for anyone that select the answer "It'll be a major impact to our build system, as we'll have to stop most of our current production to refactor the whole build system to adapt to such a scenario” ; I’d like to have some explanations about this.
This is an example, but it is valid for almost all the questions: otherwise I wouldn’t trust that the answers are made with a full understanding of the proposals.
> 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
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev