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

[Renato Golin via llvm-dev]

We have free text answers for both groups of answers, usage and impact.
People can write whatever they want there.

I don't see what the problem is...

Cheers,
Renato

On 24 Aug 2016 8:01 p.m., "Mehdi Amini" <mehdi.amini at apple.com> wrote:

>
> > On Aug 19, 2016, at 4:23 AM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_
> forms_k4J7M3N7oLNTOlDq2&d=CwIGaQ&c=Hw-EJUFt2_
> D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=XndYjVJuvcoEtO9BUlAZk8839TPlVR
> JeJXMNUFEz-qQ&m=OhW1rKp29KzWPJmzePqaWyyFm8koNMtnNM4xM0DOCLM&s=
> 6u9FpXqnNR5dxnPdXhgM17YsrxuvACOEtpCweWvOffM&e=
> >
> > 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.
>
> 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.
>
> —
> Mehdi
>
>
>
>
> >
> > 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
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160824/a09fb272/attachment.html>