Questions for "Git User's Survey 2016"

I am thinking about returning to doing the Git User's Survey, and I'd like to ask for feedback.

Thanks to generocity of Survs.com, we have been gifted with premium annual plan (previous surveys always generated quite a large number of responses). This plan will last (at least; it was usually automatically renewed at no cost) till 26 October 2016, so I am planning on having the survey for 1 month, in September:

1 September -- 30 September 2016

For now I would like to ask what types of questions would you want to see in the survey, and what you want to get from it (what would be the survey purpose).

In my opinion, the survey has (at least) threefold purpose:

1. INFORMATIONAL. We can find out how people use Git, if the range of people answering the survey is wide enough and diverse enough. We can find out what are their pain points. It might be different from what we here on this mailing list think it is. Hopefully this would help direct Git development to make Git better for all.

2. EDUCATIONAL. For example a question about which features do one uses, or how one gets help about Git, tends to be educational for people taking the survey.

3. ADVERTISEMENT. Announcing Git User's Survey might be considered advertisement for git mailing list. Questions about hosting site or books can also be considered advertisement for the site in question or the book / the author, respectively.

What I'd like to see is how people use Git, which features do they use and which tools (maybe there is some great unknown tool there?), where they go to find help about Git.

What types of questions should there be in this year survey?

Jakub Narębski

Thanks for doing the survey!

Additionally to the categories you listed, I'd like to propose

4. TEMPORAL. We may get feedback if and how much some pain points were addressed since the last survey. This can be done by using the very same question we used in the last questionnaire, and see how much the answers shifted or by doing more suggestive questions ("Last survey showed, feature X is not easy to use, how easy is it now? Think of X in v1.7.5")

AFAICT the last survey was 2012?

As for the content, I think submodules improved a lot since then, however I do think they could be improved even more. e.g. one question could be:

What would you think would improve submodules most if you could only pick one?

* inclusion of submodules into more commands, e.g. "git checkout --recurse-submodules"
* support for direct clones of submodules from a host (i.e. not going through the .gitmodules file, but trying to obtain the submodule from that superprojects .git/modules/<name>. This would only work for non bare repos)
* more fault tolerance for miss-configured submodules
* more descriptive error messages for miss-configured submodules
* ...

This would help to gauge how to best spend developer time when trying to improve a feature (like submodules)

Thanks,
Stefan