[llvm-dev] GitHub Survey?

Thu Sep 8 11:10:25 PDT 2016

Hey Renato,

I want to again thank you for all your work herding this process along.

If I may for a moment I'd like to work backwards through your "Next Steps". The last step is that someone (or a group of people) will make the final decision based on the information in the survey and the conversation in the BoF.

A lot of the earlier steps depend on who and how the decision is to be made. For example, if the intent is that the final decision be dictated by the result of the survey, it is less a survey more a vote. On the other hand if the intent is that a group of people interpret survey results and make a decision based on survey results (although not dictated by them), then the survey should be worded differently.

It might make the process of constructing an appropriate survey easier if we first figure out who will be the decision makers, and how they are intended to make the decision.

My personal preference would be for the decision makers to be either a committee of developers or the LLVM Foundation board, and I would prefer if the survey were crafted to provide them with information to inform a decision, rather than a dictation of a decision.

-Chris

> On Sep 1, 2016, at 5:44 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Folks,
> 
> It's 1st of September, and we don't have the document nor the survey
> ready. With the US meeting on 3-4 November, that leaves us only 2
> months to do everything, and I'm not sure we'll be able to if we delay
> much more.
> 
> Being the devil's advocate and hoping this doesn't spiral down
> (again), there were a few pertinent questions left unanswered from the
> previous threads...
> 
> 1. How much vote, how much survey?
> 
> Most people are in agreement that a balance has to be struck, though
> there is no clear consensus on how much of each.
> 
> The concerns raised were:
> * As it is now, we may not have enough information on why, just what
> people want.
> * Without multiple choice questions, it'll be too hard to infer what
> people want.
> * With too many questions, statistical relevance will be diluted and
> spread too thin.
> 
> FWIW, I'm personally happy with the current format. But this is not about me.
> 
> 
> 2. How much information do we want?
> 
> Chris' point on the other thread is that he wants a lot more
> information, so we can derive all sorts of correlations and drive
> other decisions, not just GitHub. I think this is a valid point, but
> it depends on the time scale.
> 
> The concerns are:
> * If we want to have enough meaningful results by the US LLVM, we
> need to get it online ASAP
> * It'll take months to converge on a long list of questions, publish,
> get feedback, analyse it all
> * The result will be more general, so we only do it once, but won't
> help the GitHub choice
> * Free text interpretation is fuzzy and easy to bias, concrete
> decisions need concrete information
> 
> 
> 3. The current GitHub document
> 
> We need to update the current document to have both options:
> sub-modules and mono-repo, with an exact description of what they
> mean.
> 
> The sub-modules discussion has finished with a solid proposal, though
> there aren't many example use cases, which makes it hard to
> demonstrate. But the mono-repo discussion was still around which
> repositories belong to the mono-repo and which don't, and what do we
> do about the others.
> 
> So, the next steps on this task are:
> * Rename the file to GitHub.rst (since it'll have both proposals in there)
> * Update the sub-modules part, adding example use cases
> * Insert the whole mono-repo proposal, with what's in and out + examples
> * Update the migration plan to cope with either option (should be
> similar anyway)
> 
> 
> ==  Next Steps
> 
> I'm attaching the pre-survey dump, with an anonymised CSV file (no
> names or emails), plus a number of pictures of the pie charts. We'll
> put it up in a web document to look nicer with the official survey.
> 
> So, the next steps are:
> 
> 1. Make sure everyone is happy with the survey, and change it if necessary.
> 1.a Make sure the results are in a format that people expect / can work with.
> 
> 2. Make the appropriate changes to the proposal document.
> 2.a Review, reach consensus, approve, publish.
> 
> 3. Put the survey online, this time for real, deleting all current
> responses first.
> 3.a *Everyone* that has filled it already will have to fill it again, sorry.
> 
> 4. We'll need a deadline, so people feel compelled to answer sooner.
> 4.a When the deadline is reached, collate the results in a CSV file+PNGs.
> 4.b A group of people (volunteers? foundation?) will analyse the data
> and decide how to present.
> 4.c I volunteer to write the final document, with their final blessing
> before publishing.
> 4.d Hopefully before the US LLVM (4 Nov), we can have both the
> proposal and survey results.
> 
> 5. At the US LLVM, hold a BoF / Panel on the GitHub move.
> 5.a Use the proposal and survey results as a starting point.
> 5.b Gather the feedback, create a third document (I volunteer again).
> 
> 6. Someone(s) take(s) the final decision...
> 
> cheers,
> --renato
> <GitHubSurvey.zip>
> _______________________________________________
> 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/20160908/432bb42a/attachment.html>