[RFC] Git User's Survey 2009 - trial run

[RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

I have created _proposed_ version of questions for upcoming 
"Git User's Survey 2009", based on (a bit of) feedback on git
mailing list:
  "[RFH] Questions for Git User's Survey 2009"
  Msg-Id: <200905291855.03328.jnareb@gmail.com>
  http://thread.gmane.org/gmane.comp.version-control.git/120287
and comments on #git IRC channel on FreeNode.  

Current version of survey has 30 questions, as compared to 
60 questions last year; the number of free-form essay questions
were also greatly reduced.


The *test* version of this year survey can be now found at
the following URL (as in previous year, we use Survs.com)

  http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y

Please tell me what you think about questions and about selection
of possible answers in single choice/multiple choice questions.
If you have better idea for theme (mainly background and font 
colors, and perhaps font size), help would be appreciated.  Is it
better to use vertical form everywhere, or should we use horizontal
layout of answers for questions with short number of possible
answers?  How long does it take to fill survey?

ATTENTION: All data in test survey would be deleted when survey
would start for real!
-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Johan Herland]

On Thursday 25 June 2009, Jakub Narebski wrote:
> Current version of survey has 30 questions, as compared to
> 60 questions last year; the number of free-form essay questions
> were also greatly reduced.

Good. :)

> The *test* version of this year survey can be now found at
> the following URL (as in previous year, we use Survs.com)
>
>   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
>
> Please tell me what you think about questions and about selection
> of possible answers in single choice/multiple choice questions.

There seems to be some unnecessary overlap among questions 11, 16/17 and 18. 
Examples: I found myself ticking off equivalent options like:
- 11/gitk, 17/gitk and 18/"gitk or other history viewer"
- 17/"git gui" and 18/"git-gui or other commit tool"
- 14/"via git-bundle", 15/"git bundle", 16/"git bundle" and 18/"git bundle"
- 11/StGIT/Guilt/TopGit and 18/"path management interface"
- 17/"git reflog" and 18/reflog
- 17/"git stash" and 18/stash
- 16/"git difftool" and 18/"mergetool and/or difftool"
- 16/"git mergetool" and 18/"mergetool and/or difftool"
- 17/"git rebase -i" and 18/"interactive rebase"
- 16/"git add -i" and 18/"interactive commit/..."
- 16/"git filter-branch", 18/"git-filter-branch or cg-admin-rewritehist" and 
18/"git-filter-branch or equivalent"
- 11/"editor/IDE VC integration" and 18/"integration with IDE/editor"

Some of this overlap is probably unavoidable, but I think some of it 
(especially between 16/17 and 18) can be eliminated without compromising the 
survey. Maybe we can integrate the non-overlapping parts of 18 into the 
other questions, thereby further decreasing the number of questions?

BTW, 17 is just a continuation of 16, AFAICS. Is it possible to just repeat 
the column headers (to break up the table length) and still keep it as one 
question?


Otherwise, I like the survey very much.

> How long does it take to fill survey?

~ 5-7 minutes


Thanks for the hard work you put into this. It is appreciated.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [RFC] Git User's Survey 2009 - trial run

[Santi Béjar]

2009/6/26 Johan Herland <johan@herland.net>:
> On Thursday 25 June 2009, Jakub Narebski wrote:
>> Current version of survey has 30 questions, as compared to
>> 60 questions last year; the number of free-form essay questions
>> were also greatly reduced.
>
> Good. :)
>
>> The *test* version of this year survey can be now found at
>> the following URL (as in previous year, we use Survs.com)
>>
>>   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
>>
>> Please tell me what you think about questions and about selection
>> of possible answers in single choice/multiple choice questions.
>
> There seems to be some unnecessary overlap among questions 11, 16/17 and 18.

[...]

>
> Some of this overlap is probably unavoidable, but I think some of it
> (especially between 16/17 and 18) can be eliminated without compromising the
> survey. Maybe we can integrate the non-overlapping parts of 18 into the
> other questions, thereby further decreasing the number of questions?
>
> BTW, 17 is just a continuation of 16, AFAICS. Is it possible to just repeat
> the column headers (to break up the table length) and still keep it as one
> question?
>


I agree.

[...]

>
> Otherwise, I like the survey very much.

Me too.

>
>> How long does it take to fill survey?
>
> ~ 5-7 minutes

For me it was 12 minutes, and it was without answering the free form
questions and with good git knowledge.

Santi

Re: [RFC] Git User's Survey 2009 - trial run

[Felipe Contreras]

2009/6/26 Johan Herland <johan@herland.net>:
> On Thursday 25 June 2009, Jakub Narebski wrote:
>> Current version of survey has 30 questions, as compared to
>> 60 questions last year; the number of free-form essay questions
>> were also greatly reduced.
>
> Good. :)
>
>> The *test* version of this year survey can be now found at
>> the following URL (as in previous year, we use Survs.com)
>>
>>   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
>>
>> Please tell me what you think about questions and about selection
>> of possible answers in single choice/multiple choice questions.
>
> There seems to be some unnecessary overlap among questions 11, 16/17 and 18.
> Examples: I found myself ticking off equivalent options like:
> - 11/gitk, 17/gitk and 18/"gitk or other history viewer"
> - 17/"git gui" and 18/"git-gui or other commit tool"
> - 14/"via git-bundle", 15/"git bundle", 16/"git bundle" and 18/"git bundle"
> - 11/StGIT/Guilt/TopGit and 18/"path management interface"
> - 17/"git reflog" and 18/reflog
> - 17/"git stash" and 18/stash
> - 16/"git difftool" and 18/"mergetool and/or difftool"
> - 16/"git mergetool" and 18/"mergetool and/or difftool"
> - 17/"git rebase -i" and 18/"interactive rebase"
> - 16/"git add -i" and 18/"interactive commit/..."
> - 16/"git filter-branch", 18/"git-filter-branch or cg-admin-rewritehist" and
> 18/"git-filter-branch or equivalent"
> - 11/"editor/IDE VC integration" and 18/"integration with IDE/editor"
>
> Some of this overlap is probably unavoidable, but I think some of it
> (especially between 16/17 and 18) can be eliminated without compromising the
> survey. Maybe we can integrate the non-overlapping parts of 18 into the
> other questions, thereby further decreasing the number of questions?
>
> BTW, 17 is just a continuation of 16, AFAICS. Is it possible to just repeat
> the column headers (to break up the table length) and still keep it as one
> question?

I agree, I found myself clicking on gitk multiple times (4?)

-- 
Felipe Contreras

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

On Fri, 26 June 2009, Johan Herland wrote:
> On Thursday 25 June 2009, Jakub Narebski wrote:

> > Current version of survey has 30 questions, as compared to
> > 60 questions last year; the number of free-form essay questions
> > were also greatly reduced.
> 
> Good. :)

Too large number of questions in the survey, and filling survey taking
too long were, I think, the most common complaints about survey in the
year before.

A number of free-form essay questions from previous survey are still
not analyzed (even now).

> > The *test* version of this year survey can be now found at
> > the following URL (as in previous year, we use Survs.com)
> >
> >   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
> >
> > Please tell me what you think about questions and about selection
> > of possible answers in single choice/multiple choice questions.
> 
> There seems to be some unnecessary overlap among questions 11, 16/17 and 18. 

Just a reminder; those questions are:

11. What Git interfaces, implementations, frontends and tools do you use?

16. How often do you use the following forms of git commands
    or extra git tools?
17. How often do you use the following forms of git commands
    or extra git tools? (continued)

18. Which of the following features do or did you use?

Overlap between questions 16/17 and 18 is, to some extent, intended.  
Those two questions ask about similar area but from the two different
points of view: question 16/17 is about git commands, 18 about features.

In first two drafts there were no question 16/17; it was brought back
at the request on #git channel.  I am a bit ambivalent about this 
question; on one hand side it allows responders to get to know some
git commands or form of git commands they didn't know about, on the
other hand side it is one of most work-intensive and time-consuming
questions.  It brings interesting information, but the same could
have been (perhaps better) gathered from a filtered list of commands
in history, or from list of commands generated by special 'statistic
gathering' compiled version of git.

It there are votes for removing questions 16/17 I can remove it from
survey (again).

> Examples: I found myself ticking off equivalent options like:
> - 11/gitk, 17/gitk and 18/"gitk or other history viewer"
> - 17/"git gui" and 18/"git-gui or other commit tool"

This can be easily corrected by removing extra tools which are
mentioned in question 11. about tools used from possible answers
to question 18. about features used.  I am not so sure about removing
'gitk' and 'git gui' from 16/17.

OTOH some tools can be uses both as history viewer, and as commit tool.
This answer allow to distinguish between those two distinct usages.

> - 14/"via git-bundle", 15/"git bundle", 16/"git bundle" and 18/"git bundle"

14. How do you fetch/get changes from upstream repository?
15. How do you publish/propagate your changes?

These are about different directions, and I think different ways of
using git-bundle.  For fetching (or rather cloning) via bundle I would
think that project would publish ready for download bundles to reduce
traffic and load on server (HTTP download can be resumed, git-clone
currently cannot; you can distribute bundle using P2P, GitTorrent and
git mirror-sync are not implemented (yet)).  For publishing via bundle
I would think about sending bundle via email, or posting it on review
board (BTW IIRC Gerrit uses git-bundle).

About 16/17 (git commands) and 18 (features): I guess I can remove
git-bundle from the list of features we ask about.

About 14, 15 (get / publish) and 16/17 (git commands): the command
list is meant to be comprehensive list of porcelain and porcelanish
git commands, so I don't think it would be good to remove bundle from
16/17.  OTOH git-bundle can be used neither for fetching nor for 
publishing, but for example only for review, or for syncing between
_own_ repositories.

> - 11/StGIT/Guilt/TopGit and 18/"patch management interface"

I could remove "patch management interface" / "topic branch management
interface" from 18 (features), as they are in 11 (tools), but I am less
sure about this than about removing "history viewers" and "commit tools".

> - 17/"git reflog" and 18/reflog

I think I'll remove 'reflog' from 18 (features), not because it is
present in 16/17 (git commands), but because this is feature one uses,
I think, quite often and less 'conscious'.

OTOH one can use reflog feature without using "git reflog" or 
"git log -g" ("git log --walk-reflogs") -- HEAD@{1} or @{yesterday}
uses reflog feature without using mentioned git commands :-)

> - 17/"git stash" and 18/stash

True. Nevertheless I'd rather leave this duplication (well, unless
question 16/17 (git commands) would be voted to be removed).

> - 16/"git difftool" and 18/"mergetool and/or difftool"
> - 16/"git mergetool" and 18/"mergetool and/or difftool"

Well, it is even more clear that the issue of gitk etc. in 16/17 and 18;
I think I can safely remove "mergetool and/or difftool" from 
18 (features).  IIRC it was here because initially there were no
16/17 (git commands) question.

> - 17/"git rebase -i" and 18/"interactive rebase"

Hmmm... I would think about this.

> - 16/"git add -i" and 18/"interactive commit/..."

Actually here "interactive commit/..." in 18 (features) covers more than
just "git add -i", as it is also about per-chunk committing feature
of git-gui and other commit tools.

> - 16/"git filter-branch", 18/"git-filter-branch or cg-admin-rewritehist" and 
>   18/"git-filter-branch or equivalent"

Ooops.  Certainly "git-filter-branch or cg-admin-rewritehist" and 
"git-filter-branch or equivalent" answers should be concatenated.
My mistake.

About having it both in 16/17 (git commands) and 18 (features): I wonder
if "git filter-branch" in 16/17 should be split into filterless version
(make grafts into history, add 'encoding' header) and version with some
filter specified...

> - 11/"editor/IDE VC integration" and 18/"integration with IDE/editor"

O.K. I think I can safely remove this from 18 (features), as it is
present in 11 (tools).

> 
> Some of this overlap is probably unavoidable, but I think some of it 
> (especially between 16/17 and 18) can be eliminated without compromising the 
> survey. Maybe we can integrate the non-overlapping parts of 18 into the 
> other questions, thereby further decreasing the number of questions?

Questions 16/17 (git commands) and 18 (features) are about the same area,
but orthogonal (different) approach.  I was not sure (and still I am not)
whether to include 16/17 (git commands) question in the survey.

> 
> BTW, 17 is just a continuation of 16, AFAICS. Is it possible to just repeat 
> the column headers (to break up the table length) and still keep it as one 
> question?

This is _technical_ limitation of Survs.com on number of answers in
a single question (I think it is 50 answers maximum, or something).

> > How long does it take to fill survey?
> 
> ~ 5-7 minutes

Thanks for this information.

-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Johan Herland]

On Friday 26 June 2009, Jakub Narebski wrote:
> On Fri, 26 June 2009, Johan Herland wrote:
> > On Thursday 25 June 2009, Jakub Narebski wrote:
> > > Current version of survey has 30 questions, as compared to
> > > 60 questions last year; the number of free-form essay questions
> > > were also greatly reduced.
> >
> > Good. :)
>
> Too large number of questions in the survey, and filling survey
> taking too long were, I think, the most common complaints about
> survey in the year before.

Yes, that's why I focused on decreasing the number of questions even
further.

> A number of free-form essay questions from previous survey are still
> not analyzed (even now).

Which is why we should as few free-form questions as possible.

> > > The *test* version of this year survey can be now found at
> > > the following URL (as in previous year, we use Survs.com)
> > >
> > >   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
> > >
> > > Please tell me what you think about questions and about selection
> > > of possible answers in single choice/multiple choice questions.
> >
> > There seems to be some unnecessary overlap among questions 11,
> > 16/17 and 18.
>
> Just a reminder; those questions are:
>
> 11. What Git interfaces, implementations, frontends and tools do you
> use?
>
> 16. How often do you use the following forms of git commands
>     or extra git tools?
> 17. How often do you use the following forms of git commands
>     or extra git tools? (continued)
>
> 18. Which of the following features do or did you use?
>
> Overlap between questions 16/17 and 18 is, to some extent, intended.
> Those two questions ask about similar area but from the two different
> points of view: question 16/17 is about git commands, 18 about
> features.

I see, but in the cases where the feature questions in 18 are tied to
a specific git command already mentioned in 16/17, I believe you can
drop it from 18 (since we already got our answer in 16/17).

> In first two drafts there were no question 16/17; it was brought back
> at the request on #git channel.  I am a bit ambivalent about this
> question; on one hand side it allows responders to get to know some
> git commands or form of git commands they didn't know about, on the
> other hand side it is one of most work-intensive and time-consuming
> questions.  It brings interesting information, but the same could
> have been (perhaps better) gathered from a filtered list of commands
> in history, or from list of commands generated by special 'statistic
> gathering' compiled version of git.
>
> It there are votes for removing questions 16/17 I can remove it from
> survey (again).

No, I don't want to remove 16/17. I'd rather remove 18, since it
overlaps so much with several of the earlier questions.

> > Examples: I found myself ticking off equivalent options like:
> > - 11/gitk, 17/gitk and 18/"gitk or other history viewer"
> > - 17/"git gui" and 18/"git-gui or other commit tool"
>
> This can be easily corrected by removing extra tools which are
> mentioned in question 11. about tools used from possible answers
> to question 18. about features used.  I am not so sure about removing
> 'gitk' and 'git gui' from 16/17.

makes sense.

> OTOH some tools can be uses both as history viewer, and as commit
> tool. This answer allow to distinguish between those two distinct
> usages.
>
> > - 14/"via git-bundle", 15/"git bundle", 16/"git bundle" and 18/"git
> > bundle"
>
> 14. How do you fetch/get changes from upstream repository?
> 15. How do you publish/propagate your changes?
>
> These are about different directions, and I think different ways of
> using git-bundle.  For fetching (or rather cloning) via bundle I
> would think that project would publish ready for download bundles to
> reduce traffic and load on server (HTTP download can be resumed,
> git-clone currently cannot; you can distribute bundle using P2P,
> GitTorrent and git mirror-sync are not implemented (yet)).  For
> publishing via bundle I would think about sending bundle via email,
> or posting it on review board (BTW IIRC Gerrit uses git-bundle).

yes, I don't want to remove or collapse 14 or 15. But in the cases
where they overlap with later questions (16/17 and 18), you can
remove those alternatives from the later questions.

> About 16/17 (git commands) and 18 (features): I guess I can remove
> git-bundle from the list of features we ask about.

yes.

> About 14, 15 (get / publish) and 16/17 (git commands): the command
> list is meant to be comprehensive list of porcelain and porcelanish
> git commands, so I don't think it would be good to remove bundle from
> 16/17.  OTOH git-bundle can be used neither for fetching nor for
> publishing, but for example only for review, or for syncing between
> _own_ repositories.

I believe the "comprehensive list of porcelain and porcelainish git
commands" can be distributed over several questions, including 14 and 15.

> > - 11/StGIT/Guilt/TopGit and 18/"patch management interface"
>
> I could remove "patch management interface" / "topic branch
> management interface" from 18 (features), as they are in 11 (tools),
> but I am less sure about this than about removing "history viewers"
> and "commit tools".
>
> > - 17/"git reflog" and 18/reflog
>
> I think I'll remove 'reflog' from 18 (features), not because it is
> present in 16/17 (git commands), but because this is feature one
> uses, I think, quite often and less 'conscious'.

agreed.

> OTOH one can use reflog feature without using "git reflog" or
> "git log -g" ("git log --walk-reflogs") -- HEAD@{1} or @{yesterday}
> uses reflog feature without using mentioned git commands :-)

But _why_ are we asking this question? If the reflog feature is used
all the time without people having to know about it, then there's no
point in asking about it. It's not like it's going to be removed in
the next version because people dislike it. It's like asking "Are you
using Git blob objects?". What are you going to do with the answer?

> > - 17/"git stash" and 18/stash
>
> True. Nevertheless I'd rather leave this duplication (well, unless
> question 16/17 (git commands) would be voted to be removed).

Again, I don't want to remove 16/17, I'd rather remove 18.

> > - 16/"git difftool" and 18/"mergetool and/or difftool"
> > - 16/"git mergetool" and 18/"mergetool and/or difftool"
>
> Well, it is even more clear that the issue of gitk etc. in 16/17 and
> 18; I think I can safely remove "mergetool and/or difftool" from 18
> (features).  IIRC it was here because initially there were no 16/17
> (git commands) question.

I understand.

> > - 17/"git rebase -i" and 18/"interactive rebase"
>
> Hmmm... I would think about this.

Ask yourself: Would anyone answer YES to one of these items, but NO
to the other (modulo typos/thinkos)? If not, you do not gain any
extra information by asking the extra question, so you can safely
drop one of them.

> > - 16/"git add -i" and 18/"interactive commit/..."
>
> Actually here "interactive commit/..." in 18 (features) covers more
> than just "git add -i", as it is also about per-chunk committing
> feature of git-gui and other commit tools.

Ok, but in that case do we really need to ask if they use "git add -i"?
Isn't the main point whether or not people use the concept/feature,
and not exactly which tool they use to do it?

> > - 16/"git filter-branch", 18/"git-filter-branch or
> > cg-admin-rewritehist" and 18/"git-filter-branch or equivalent"
>
> Ooops.  Certainly "git-filter-branch or cg-admin-rewritehist" and
> "git-filter-branch or equivalent" answers should be concatenated.
> My mistake.
>
> About having it both in 16/17 (git commands) and 18 (features): I
> wonder if "git filter-branch" in 16/17 should be split into
> filterless version (make grafts into history, add 'encoding' header)
> and version with some filter specified...

I don't think it is necessary to split it.

> > - 11/"editor/IDE VC integration" and 18/"integration with
> > IDE/editor"
>
> O.K. I think I can safely remove this from 18 (features), as it is
> present in 11 (tools).
>
> > Some of this overlap is probably unavoidable, but I think some of
> > it (especially between 16/17 and 18) can be eliminated without
> > compromising the survey. Maybe we can integrate the non-overlapping
> > parts of 18 into the other questions, thereby further decreasing
> > the number of questions?
>
> Questions 16/17 (git commands) and 18 (features) are about the same
> area, but orthogonal (different) approach.  I was not sure (and still
> I am not) whether to include 16/17 (git commands) question in the
> survey.

As I said above, I'd rather drop 18 (by which I really mean baking the
non-overlapping parts of 18 into the other questions).

> > BTW, 17 is just a continuation of 16, AFAICS. Is it possible to
> > just repeat the column headers (to break up the table length) and
> > still keep it as one question?
>
> This is _technical_ limitation of Survs.com on number of answers in
> a single question (I think it is 50 answers maximum, or something).

Ok.

> > > How long does it take to fill survey?
> >
> > ~ 5-7 minutes
>
> Thanks for this information.

BTW, Here are my suggested changes to the survey (in an ad-hoc
quasi-diff format that hopefully better overview than the above
discussion). As you can see, I have removed question 18, and added
its non-overlapping items to the other questions (mostly 17). For
each item in 18, I've noted [in square brackets] why it is removed
or where it has moved:


(1 - 10: No changes)

11. What Git interfaces, implementations, frontends and tools do you use? 
+ * my own scripts

(12 - 15: No changes)

- 16. How often do you use the following forms of git commands or extra git tools?
+ 16. How often do you use the following forms of git commands, features or extra git tools?
                                     never   rarely   sometimes   often
- * git add -i / -p                    [ ]      [ ]      [ ]      [ ]
+ * interactive commit / per-hunk comitting / partial commit (git add -i / -p)   [ ] [ ] [ ] [ ]

- * git filter-branch                  [ ]      [ ]      [ ]      [ ]
+ * git filter-branch (or equivalent)  [ ]      [ ]      [ ]      [ ]


- 17. How often do you use the following forms of git commands or extra git tools? (continued)
+ 17. How often do you use the following forms of git commands, features or extra git tools? (continued)
                                     never   rarely   sometimes   often
- * git rebase -i                      [ ]      [ ]      [ ]      [ ]
+ * git rebase -i (interactive rebase) [ ]      [ ]      [ ]      [ ]
- * git gui                            [ ]      [ ]      [ ]      [ ]
- * gitk                               [ ]      [ ]      [ ]      [ ]
+ * End-of-line conversion (CRLF)      [ ]      [ ]      [ ]      [ ]
+ * gitattributes                      [ ]      [ ]      [ ]      [ ]
+ * submodules (subprojects)           [ ]      [ ]      [ ]      [ ]
+ * subtree merge                      [ ]      [ ]      [ ]      [ ]
+ * git-subtree                        [ ]      [ ]      [ ]      [ ]
+ * separate worktree / core.worktree  [ ]      [ ]      [ ]      [ ]
+ * multiple worktrees (git-new-worktree)  [ ]  [ ]      [ ]      [ ]
+ * alternates mechanism (sharing object database)  [ ] [ ] [ ]   [ ]
+ * shallow clone                      [ ]      [ ]      [ ]      [ ]
+ * detaching HEAD                     [ ]      [ ]      [ ]      [ ]
+ * commit message templates           [ ]      [ ]      [ ]      [ ]
+ * non-default hooks                  [ ]      [ ]      [ ]      [ ]
+ * shell completion of commands       [ ]      [ ]      [ ]      [ ]
+ * git-aware shell prompt             [ ]      [ ]      [ ]      [ ]


- 18. Which of the following features do or did you use? 
- * git-gui or other commit tool [covered by 11/git-gui or 11/Other]
- * gitk or other history viewer [covered by 11/gitk or 11/Other]
- * patch management interface (e.g. StGIT, Guilt, TopGit) [covered by 11]
- * git bundle (off-line transport) [covered by 16]
- * eol conversion (crlf) [added to 17]
- * gitattributes [added to 17]
- * submodules (subprojects) [added to 17]
- * subtree merge (optionally git-subtree) [added to 17]
- * separate worktree / core.worktree [added to 17]
- * multiple worktrees (git-new-worktree) [added to 17]
- * alternates mechanism (sharing object database) [added to 17]
- * reflog (includes "git log -g" and branch@{n}) [covered by 17]
- * stash (optionally "git stash --keep-index") [covered by 17]
- * shallow clone [added to 17]
- * detaching HEAD [added to 17]
- * mergetool and/or difftool [covered by 16]
- * interactive rebase [covered by 17]
- * interactive commit / per-hunk comitting / partial commit [covered by / added to 16]
- * commit message templates [added to 17]
- * git-filter-branch or cg-admin-rewritehist [remove, duplicate below]
- * bisect (optionally "git bisect run <script>") [covered by 16]
- * working with dirty tree [rephrase or drop? why would anyone answer NO?]
- * git-filter-branch or equivalent [covered by / added to 16]
- * integration with IDE/editor [covered by 11]
- * non-default hooks [added to 17]
- * shell completion of commands [added to 17]
- * git-aware shell prompt [added to 17]
- * my own scripts [this is not a git "feature", added to 11, instead]
- * Other, please specify

(19 - 30: No changes)


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net
 

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

Dnia piątek 26. czerwca 2009 16:44, Johan Herland napisał:
> On Friday 26 June 2009, Jakub Narebski wrote:

>> Too large number of questions in the survey, and filling survey
>> taking too long were, I think, the most common complaints about
>> survey in the year before.
> 
> Yes, that's why I focused on decreasing the number of questions even
> further.

Having less questions (currently trying to fit within 30 questions)
is not the only criterion.  It is also important to not have too 
complicated questions (with large number of possible responses),
see e.g. question 10 (editors and RAD) which got slimmed down by
asking about kind of editors and not individual editors.

>>> There seems to be some unnecessary overlap among questions 11,
>>> 16/17 and 18.
>>
>> Overlap between questions 16/17 and 18 is, to some extent, intended.
>> Those two questions ask about similar area but from the two different
>> points of view: question 16/17 is about git commands, 18 about
>> features.
> 
> I see, but in the cases where the feature questions in 18 are tied to
> a specific git command already mentioned in 16/17, I believe you can
> drop it from 18 (since we already got our answer in 16/17).

Actually if I could I'd rather drop it from 16/17... but this question
is about comprehensive list of git commands (one can use).  I think
that some people won't answer 16/17 because it is long and time-consuming
(and difficult to answer, if you want to do it truthfully).

On the other hand trimming down the list of possible answers in 
18 (features of git) could be a good idea...

>> It there are votes for removing questions 16/17 I can remove it from
>> survey (again).
> 
> No, I don't want to remove 16/17. I'd rather remove 18, since it
> overlaps so much with several of the earlier questions.

I'd rather not.  I prefer 18 to 16/17.
 
>>> - 17/"git reflog" and 18/reflog
>>
>> I think I'll remove 'reflog' from 18 (features), not because it is
>> present in 16/17 (git commands), but because this is feature one
>> uses, I think, quite often and less 'conscious'.
> 
> agreed.
> 
>> OTOH one can use reflog feature without using "git reflog" or
>> "git log -g" ("git log --walk-reflogs") -- HEAD@{1} or @{yesterday}
>> uses reflog feature without using mentioned git commands :-)
> 
> But _why_ are we asking this question? If the reflog feature is used
> all the time without people having to know about it, then there's no
> point in asking about it. It's not like it's going to be removed in
> the next version because people dislike it. It's like asking "Are you
> using Git blob objects?". What are you going to do with the answer?

Actually I think this answer is here because it was present in previous
survey... and then reflog was not turned on by default, and <rev>@{<n>}
syntax didn't exist then.  Using reflog was then conscious choice.
Not nowadays.
 

Thank you for all your comments.  I'll try to come up soon with next
version of "Git User's Survey 2009", hopefully the last one before start
(and question about announcing it).

-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Peter Baumann]

On Thu, Jun 25, 2009 at 09:22:50PM +0200, Jakub Narebski wrote:
> I have created _proposed_ version of questions for upcoming 
> "Git User's Survey 2009", based on (a bit of) feedback on git
> mailing list:
>   "[RFH] Questions for Git User's Survey 2009"
>   Msg-Id: <200905291855.03328.jnareb@gmail.com>
>   http://thread.gmane.org/gmane.comp.version-control.git/120287
> and comments on #git IRC channel on FreeNode.  
> 
> Current version of survey has 30 questions, as compared to 
> 60 questions last year; the number of free-form essay questions
> were also greatly reduced.
> 
> 
> The *test* version of this year survey can be now found at
> the following URL (as in previous year, we use Survs.com)
> 
>   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
> 
> Please tell me what you think about questions and about selection
> of possible answers in single choice/multiple choice questions.
> If you have better idea for theme (mainly background and font 
> colors, and perhaps font size), help would be appreciated.  Is it
> better to use vertical form everywhere, or should we use horizontal
> layout of answers for questions with short number of possible
> answers?  How long does it take to fill survey?
> 


Remarks:

- I find the visual layout of footnotes to 10 ("What do you use to edit contents under
  version control with Git?  What kind of editor, IDE or RAD you use working
  with Git?") a little distracting. Could those at least be seperated by a newline?


- I'm not sure if question 16 ("How often do you use the following forms of git
  commands or extra git tools?") isn't a little too much. At least I got scared by looking
  at all questions in there and I imagine that people get easily bored answering them.

- The same might be true for question 17 and 18.


Overall, I like the survey.

-Peter

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

On Fri, 26 June 2009, Peter Baumann wrote:
> On Thu, Jun 25, 2009 at 09:22:50PM +0200, Jakub Narebski wrote:
 
> > The *test* version of this year survey can be now found at
> > the following URL (as in previous year, we use Survs.com)
> > 
> >   http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y
> > 
> > Please tell me what you think about questions and about selection
> > of possible answers in single choice/multiple choice questions.
> > If you have better idea for theme (mainly background and font 
> > colors, and perhaps font size), help would be appreciated.  Is it
> > better to use vertical form everywhere, or should we use horizontal
> > layout of answers for questions with short number of possible
> > answers?  How long does it take to fill survey?
> 
> Remarks:
> 
> - I find the visual layout of footnotes to 10 ("What do you use to edit contents under
>   version control with Git?  What kind of editor, IDE or RAD you use working
>   with Git?") a little distracting. Could those at least be seperated by a newline?

This is unfortunately technical limitation of Survs.com.  It replaces
run of empty lines with _single_ linebreak in text elements.  I have
submitted request for more rich formatting options (like whitelist HTML)
as feedback, but for the time being (if it didn't get accepted before
"Git User's Survey 2009" is run) I can simply divide those "footnotes"
in more than one text element.

> 
> - I'm not sure if question 16 ("How often do you use the following forms of git
>   commands or extra git tools?") isn't a little too much. At least I got scared by looking
>   at all questions in there and I imagine that people get easily bored answering them.
> 
> - The same might be true for question 17 and 18.

As you probably remember question "16/17. How often do you use the
following forms of git commands or extra git tools?" wasn't present
in first two drafts of Git User's Survey 2009.  It was only added
at request from #git channel.

On one hand side this question allows responders to get to know git
commands and forms of git commands they wouldn't otherwise know about.
So it can be seen as learning tool.  Answers to this question are also
quite interesting from the point of view of analysing git usage(s).

On the other hand side this question is very long; so long that due to
technical limits had to be split in two.  It is time-consuming and 
quite scary.  Also one can get similar statistics from filtered history;
we could also create version of git which would gather such statistics
and at request of user would aggregate responses and format for sending
(or even send via email), similarly to what Linux Counter does.


Possible solution would be to delete this question (again).  
Alternatively this question could be marked explicitly as optional
(even though all questions are optional in this survey), and put
it in separate page with more difficult / time consuming questions.

> 
> 
> Overall, I like the survey.

Thanks!  Thank you very much for taking your time to test this survey,
and to write your comments about it.
-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Felipe Contreras]

2009/6/25 Jakub Narebski <jnareb@gmail.com>:
> I have created _proposed_ version of questions for upcoming
> "Git User's Survey 2009", based on (a bit of) feedback on git
> mailing list:
>  "[RFH] Questions for Git User's Survey 2009"
>  Msg-Id: <200905291855.03328.jnareb@gmail.com>
>  http://thread.gmane.org/gmane.comp.version-control.git/120287
> and comments on #git IRC channel on FreeNode.
>
> Current version of survey has 30 questions, as compared to
> 60 questions last year; the number of free-form essay questions
> were also greatly reduced.
>
>
> The *test* version of this year survey can be now found at
> the following URL (as in previous year, we use Survs.com)
>
>  http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y

These are my comments:

3. Did you find Git easy to learn?

That assumes the user already learned to use git, how about:
3. Have you found Git easy to learn?

8. How do you obtain Git?

Most people install once, or at least not very often:
8. How did you obtain Git? (maybe s/obtain/install/)

14. How do you fetch/get changes from upstream repository?

Only one repository?
14. How do you fetch/get changes from upstream repositories?

git ... --dirstat

Isn't '--stat' more common?
git ... --stat (or --dirstat)

18. Which of the following features do or did you use?

More readable:
18. Which of the following features have you used?

22. Did you participate in previous Git User's Surveys?
22. In which of the previous Git User's Surveys have you participated?

24. Which form of Git documentation do you use?
Do you consider them useful?
24. How useful have you found Git documentation?

28. Do you read the mailing list, or watch IRC channel?
28. Which communication channels do you use?

Also, I would like to see a list of areas users would like improvements:
XX. In you opnion, which areas need improvement?
 * user-interface
 * documentation
 * performance
 * more features
 * other

Is there a way for users to assign points? eg. user-interface: 2,
documentation: 1, more features: 1

I like it better than the previous one :)

Cheers.

-- 
Felipe Contreras

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

On Fri, 26 June 2009, Felipe Contreras wrote:
> 2009/6/25 Jakub Narebski <jnareb@gmail.com>:

> > I have created _proposed_ version of questions for upcoming
> > "Git User's Survey 2009", based on (a bit of) feedback on git
> > mailing list:
> >  "[RFH] Questions for Git User's Survey 2009"
> >  Msg-Id: <200905291855.03328.jnareb@gmail.com>
> >  http://thread.gmane.org/gmane.comp.version-control.git/120287
> > and comments on #git IRC channel on FreeNode.
> >
> > Current version of survey has 30 questions, as compared to
> > 60 questions last year; the number of free-form essay questions
> > were also greatly reduced.
> >
> >
> > The *test* version of this year survey can be now found at
> > the following URL (as in previous year, we use Survs.com)
> >
> >  http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y

I reworked those comments a bit, to make it easier to see
proposed changes.

> These are my comments:
> 
> -3. Did you find Git easy to learn?
> +3. Have you found Git easy to learn?
> 
> That assumes the user already learned to use git [...]

Thanks.  I think your version is better.

> 
> -8. How do you obtain Git?
> +8. How did you obtain Git? (maybe s/obtain/install/)
> 
> Most people install once, or at least not very often

Perhaps

  +8. How did/do you obtain Git?

It is IMHO more interesting how people upgrade Git, than just how
they installed it.

> 
> -14. How do you fetch/get changes from upstream repository?
> +14. How do you fetch/get changes from upstream repositories?
> 
> Only one repository?

Good catch.  Thanks.

> 
> git ... --dirstat
> 
> Isn't '--stat' more common?
> git ... --stat (or --dirstat)

Well, this is specifically about this rare used feature/option.
"git ... --stat" or "git ... --summary" is a byproduct of many
other commands, like "git pull" / "git merge", or "git format-patch".
But perhaps we should ask about it explicitly.

> 
> -18. Which of the following features do or did you use?
> +18. Which of the following features have you used?
> 
> More readable.

True.  Thanks.

> 
> -22. Did you participate in previous Git User's Surveys?
> +22. In which of the previous Git User's Surveys have you participated?
> 
> -24. Which form of Git documentation do you use?
> -    Do you consider them useful?
> +24. How useful have you found Git documentation?
> 
> -28. Do you read the mailing list, or watch IRC channel?
> +28. Which communication channels do you use?

Good ideas.

> 
> Also, I would like to see a list of areas users would like improvements:
> XX. In you opinion, which areas need improvement?
>  * user-interface
>  * documentation
>  * performance
>  * more features
>  * other
> 
> Is there a way for users to assign points? eg. user-interface: 2,
> documentation: 1, more features: 1

We can always use 'matrix' form, with columns corresponding to importance
of a given area for improvement (1-3, or 1-5 numeric range).  Because
asking user to order from most important to least important (one can
enforce this on Survs.com by requiring only one answer with given column
selected) would be too difficult and confusing.

> 
> I like it better than the previous one :)

Thanks!

-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Felipe Contreras]

On Fri, Jun 26, 2009 at 6:44 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Fri, 26 June 2009, Felipe Contreras wrote:
>> 2009/6/25 Jakub Narebski <jnareb@gmail.com>:
>
>> > I have created _proposed_ version of questions for upcoming
>> > "Git User's Survey 2009", based on (a bit of) feedback on git
>> > mailing list:
>> >  "[RFH] Questions for Git User's Survey 2009"
>> >  Msg-Id: <200905291855.03328.jnareb@gmail.com>
>> >  http://thread.gmane.org/gmane.comp.version-control.git/120287
>> > and comments on #git IRC channel on FreeNode.
>> >
>> > Current version of survey has 30 questions, as compared to
>> > 60 questions last year; the number of free-form essay questions
>> > were also greatly reduced.
>> >
>> >
>> > The *test* version of this year survey can be now found at
>> > the following URL (as in previous year, we use Survs.com)
>> >
>> >  http://www.survs.com/survey?id=2PIMZGU0&channel=TFN2Y52K7Y

<snip/>

>  +8. How did/do you obtain Git?
>
> It is IMHO more interesting how people upgrade Git, than just how
> they installed it.

Sure, but it can be assumed from how it was installed:
 * Some kind of package management (automatically updated)
 * In other binary form (manually)
 * From a source tarball (manually)
 * From git.git repository (manually)

<snip/>

>> Also, I would like to see a list of areas users would like improvements:
>> XX. In you opinion, which areas need improvement?
>>  * user-interface
>>  * documentation
>>  * performance
>>  * more features
>>  * other
>>
>> Is there a way for users to assign points? eg. user-interface: 2,
>> documentation: 1, more features: 1
>
> We can always use 'matrix' form, with columns corresponding to importance
> of a given area for improvement (1-3, or 1-5 numeric range).  Because
> asking user to order from most important to least important (one can
> enforce this on Survs.com by requiring only one answer with given column
> selected) would be too difficult and confusing.

I see, in that case I think a matrix form would do.

Cheers.

-- 
Felipe Contreras

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

On Fri, 26 Jun 2009, Felipe Contreras wrote:
> On Fri, Jun 26, 2009 at 6:44 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>> On Fri, 26 June 2009, Felipe Contreras wrote:
>>> 2009/6/25 Jakub Narebski <jnareb@gmail.com>:

[...]
>>  +8. How did/do you obtain Git?
>>
>> It is IMHO more interesting how people upgrade Git, than just how
>> they installed it.
> 
> Sure, but it can be assumed from how it was installed:
>  * Some kind of package management (automatically updated)
>  * In other binary form (manually)
>  * From a source tarball (manually)
>  * From git.git repository (manually)

Hmmm... I'd have to think about it a bit.  On one hand side original 
version has the advantage of being similar to questions in previous
surveys, making comparison easier.  On the other hand side it is more
interesting to ask about how people update git.

BTW. you list does not include my example: I download src.rpm and
rebuild (recompile) it, then install created packages.  So it is from
source form, but compiled and installed automatically.

>>> Also, I would like to see a list of areas users would like improvements:
>>> XX. In you opinion, which areas need improvement?
>>>  * user-interface
>>>  * documentation
>>>  * performance
>>>  * more features
>>>  * other
>>>
>>> Is there a way for users to assign points? eg. user-interface: 2,
>>> documentation: 1, more features: 1
>>
>> We can always use 'matrix' form, with columns corresponding to importance
>> of a given area for improvement (1-3, or 1-5 numeric range).  Because
>> asking user to order from most important to least important (one can
>> enforce this on Survs.com by requiring only one answer with given column
>> selected) would be too difficult and confusing.
> 
> I see, in that case I think a matrix form would do.

I would replace then question "21. How does Git compare to other SCM
tools you have used?" which is not good question, especially now that
we don't have the whole "Other SCMs" section with this one to keep
within self-imposed 30 questions limit.

Thanks again for taking your time to review and test 
"Git User's Survey 2009"!

-- 
Jakub Narebski
Poland

Re: [RFC] Git User's Survey 2009 - trial run

[Jakub Narebski]

On Fri, 26 June 2009, Graham Perks wrote:

> Some comments on the survey:
> 
> Q14. I got confused on. "How do you fetch from <an> upstream  
> repository?"
> 
> Firstly, the word "an" is missing from the question.

Actually originally it was only "How do you fetch from upstream?", 
and it should be "How do you fetch from upstream repositories?".
One can follow more than one git repository.

> Secondly, the first two options are "git protocol" and "ssh". We use  
> git:// over ssh. So I don't know how to answer this.

"git protocol" was meant to be about connecting to git-daemon 
(anonymous, unauthenticated, port 9418), i.e. using URL like
"git://git.example.com/repo.git" for fetch/clone.

"ssh" was meant to be about running git-upload-pack via SSH, 
which means connecting to sshd/ssh daemon (authenticated, 
usually port 22).  This means URL like "ssh://example.com/srv/git/repo.git"
or "user@example.com:/srv/git/repo.git" (or ssh+git:// or git+ssh://).
Tunneling connection to git-daemon over SSH is not "ssh" in this
sense.

I'll try to explain this in 'footnotes' for this question, and use
example URLs to make it more clear how should one answer this question.

> 
> Q15, How do you publish?
>
> We sometimes use git format-patch and email out. Since we're on  
> Exchange, we can't use git am to pull directly from the email. We have  
> to save the patch files and "git am < 0001.change.patch". I don't see  
> an option that separates this usage out from how git am was  
> (seemingly) designed to work, directly against the mail server.

If you use git-format-patch (or equivalent) and send patches via email,
you should tick 'git format-patch + email' answer. It does not matter
how it is applied on the other side; only what you as sender do is
important.

I''l try to come with some explanation about this.


Thank you very much for your help in improving this survey!
-- 
Jakub Narebski
Poland