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

[Jonathan Roelofs via llvm-dev]

On 8/19/16 5:32 PM, Renato Golin wrote:
> On 19 August 2016 at 23:57, Jonathan Roelofs <jonathan at codesourcery.com> wrote:
>> Not sure if this has already been mentioned elsewhere, but I think there's
>> another important aspect to this: a big change in workflow can make things
>> better/worse/same , but measuring the size of change doesn't tell you
>> whether that change is good or not. Both the effort required to change, and
>> the desirability of the end state are important here.
>
> This has been addressed early on by splitting short-term from long-term.
>
> So, if you require a lot of changes, but overall this will be better
> for you, the answer is "major impact short-term", "no impact
> long-term".

I don't think that actually susses out the difference I'm trying to draw 
(unless I'm misunderstanding how you're using "impact" here). For 
example, switching to git can have a large impact on one's workflow in 
the long term, but that large long term impact might be a good thing.... 
so maybe the right wording here is "negative impact"?

>
> You can interpret "no impact long term" as "it's would be a good
> move", as the long term "git-svn" already has a costly long term
> impact.
>
> So, It seems that the common misunderstanding here is that "the
> current cost is zero", but that's far from the truth, and it's the
> major reason why we're trying to change.
>
> I can add an extra answer to the long term like "it'll be better".
>
> does that help?

Yeah, I think that's better (pun intended).

The important thing here, I think, is to get data on whether people 
think the change is a good thing, rather than to get data on whether 
people think the change is "big". Maybe it's worthwhile to get data on 
all of: { big, small } x { good, bad } x { long term, short term } ?


Jon

>
> --renato
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded