On Sat, 10 July 2010, Felipe Contreras wrote: > 2010/7/3 Jakub Narebski <jnareb@xxxxxxxxx>: > > I guess it is time for annual (so far) Git User's Survey. Should > > there be one? When should it start, and how long should it last? > > Yes, I think there should definitely be one! IMO one month is enough. By the way, I think it is important that Git User's Survey 2010 lasts past the holidays, i.e. into September or even October, even at the cost of lasting two months, and not one month. What do you think about this? > > == About you == > > > > NOTES: > > ^^^^^^ > > This section gives us a bit of demographical information about survey > > responders. Is it useful? Should we leave it in survey, or remove it? > > > > Should we for example include 'gender' as one of questions? Perl Survey > > 2010 did. > > I don't see the point of 'gender'. What does that tells us? Well, one can say that 'age' doesn't tell us much either. Sidenote: country of residence, besides giving a bit of demographical information, it also gives us information about where we could organize mini Git Together (beside the large one at Google, after GSoC Mentors Summit). It would be even better if Survs.com provided Google Map gadget to mark point of residence... :-) > > === 02. How old are you (in years)? === > > (free-form single line) > > > > NOTES: > > ^^^^^^ > > Instead of unconstrained free-form response it might be better to have > > single choice (or menu) of age ranges. What do you think? Of course with > > ranges there is question what ranges to use (how to quantize age); goo > > solution would be to chose ranges corresponding somewhat to the levels of > > education. > > What's wrong with a free-form? I think that's easy and it works. O.K., I agree that it is not that hard to analyze free-form in this case. > > === 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? > > (multiple choice, with other) > [...] > > NOTES: > > ^^^^^^ > > Is this question useful, or should it be removed from survey? > > I think this is useful to correlate communities. Hmmm... > > === 15. How do you publish/propagate your changes? === > > (multiple choice, with other) > [...] > > NOTES: > > ^^^^^^ > > Should it stay, or should it be removed? I guess it can be > > interesting for git hosting sites... Should we have separate answrs > > for different kinds of push (ssh, "dumb" HTTP(S) with WebDAV, "smart" > > HTTP - if it is possible, git:// protocol with push enabled)? > > I think this question should stay. It would also help projects to > decide how to accept patches based on what most git users are familiar > with. All right. > > === 16. Which of the following features do you use? === > > (multiple choice, with other) > [...] > > NOTES: > > ^^^^^^ > > The problem is come up not with exhaustive list of features: there are > > too many of them to list. The problem is coming up with list of > > important and used enough often features. > > > > So: what features should be included in this list? What features > > should be removed from above list of answers? > > I propose to add: > + git stage/cache/index > > We really are not sure how many people are actually aware of it, are we? > > And IMO new features should go on the top. Good idea! This and the next question about _proposed_ features are IMHO hardest to create well. > > === 19. Overall, how happy are you with Git? === > > (single choice) > [...] > > NOTES: > > ^^^^^^ > > I'm not sure if this question is at all useful. > > I think it is. Otherwise how do we know that people are happy with it? Well, I think there is rather heavy bias that if people are unhappy with Git, they wouldn't be using it (well, unless they have to), and they wouldn't be responding to this Git User's Survey (because they didn't found it, for example). > > === 20. In your opinion, which areas in Git need improvement? === > > Please state your preference. > > (matrix) > [...] > > NOTES: > > ^^^^^^ > > Are there any general areas that are missing from this list? > > What are they? > > How about: > + communication channels > > I think if users have trouble reporting issues, asking questions, we > should catch that. O.K. + communication channels (incl. requesting help) > > === 22. How do you compare the current version with the version from one year ago? === > > (single choice) > [...] > > NOTES: > > ^^^^^^ > > This question was mainly excuse for providing list of main changes > > from the year ago. I think that this question should be removed, as > > it doesn't bring any important information. > > Yeah, and I think many people don't even notice the changes as they > come, but learn slowly features that have been there since a long time > ago. O.K. I think that Git matured enough that improvements are not of the kind that make usable out of unusable (or vice versa). O'd remove this question, then. > > === 28. How did you hear about this Git User's Survey? === > > (single choice, with other) > [...] > > NOTES: > > ^^^^^^ > > This list would of course be updated to reflect the list of (planned) > > announcement channels. > > > Should I try to post announcement on mailing list for projects that > > use git? There are entirely too many such projects nowadays, and such > > announcement can be considered spamming by some... > > I still maintain that we need an official blog (not planet). Last year > the most popular way of finding about the survey was through blog > posts, but you argued that it was because you didn't spam mailing > lists. > > http://article.gmane.org/gmane.comp.version-control.git/124609 > > I still think it's unnecessary to spam mailing lists, but if it helps > us reach considerably more people, we should do it. > > Hopefully after this year's result we will know for sure ;) Well, there is Junio's blog, there is GitHub blog, and there is http://gitlog.wordpress.com/ Well, let's spam mailing lists in the name od "science"! ;-)))) -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html