From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [RFC] Git User's Survey 2008
Date: Thu, 24 Jul 2008 02:10:13 +0200 [thread overview]
Message-ID: <200807240210.13955.jnareb@gmail.com> (raw)
In-Reply-To: <7vwsjcft5g.fsf@gitster.siamese.dyndns.org>
On Wed, 23 July 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>
>>> Some people prefer to stay anonymous, so I think email is out.
>>>
>>>> 04. Which programming languages you are proficient with?
>>>> (The choices include programming languages used by git)
>>>> (zero or more: multiple choice)
>>>> - C, shell, Perl, Python, Tcl/Tk
>>>> + (should we include other languages, like C++, Java, PHP,
>>>> Ruby,...?)
>>>
>>> Yes, I think this should be a long list.
>>
>> I'd rather not have a "laundry list" of languages. I have put C++
>> because QGit uses it, Java because of egit/jgit, PHP for web
>> interfaces, Ruby because of GitHub and because of Ruby comminity
>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>> JavaScript here. What other languages should be considered?
>
> I refrained saying this in my initial response, but my initial reaction
> was "Why are you even asking this?".
>
> Yes, "getting to know you" demographics are customary done in surveys, and
> you kept it to the minimum which is also good, but I do not think this
> particular question is very interesting. For one thing, the question
> assumes the participant is a programmer, and we are giving an impression
> that we are interested in better programmers. Do we *still* require users
> to be a programmer to use git? I do not think so. Having to answer "none
> of these" to this question would make you feel unnecessarily bad, even if
> you are not a programmer and you know at the intellectual level that it is
> not your flaw not to be proficient in any.
The idea, I think, was to gauge which parts of Git would be hard to
find developers for, because of small number of people proficient in
the programming language the part is written in. I'm thinking here
about Tcl/Tk and gitk and git-gui, see
http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
Nevertheless, _if_ this question is to stay (I am not sure one way or
another), we would better add "I am not programmer" or something like
that to the list of possible answers.
> Asking about geographic location and preferred human languages might help
> to gauge what l10n are desired for GUIs, but even there, don't forget that
> we are no company. We do not research markets and translate messages to
> missing languages, however popular, before being asked. That's not how we
> operate. So the result of these questions will be mainly to satisfy our
> curiosity, nothing more.
It would also answer question if adding support for i18n in git, for
example support for translating git commands messages, is something
which people would want or not. If they would be translated or not
it would depend on people, but one cannot even begin translation
efforts if there is no infrastructure in place.
But as the rest of localization / internationalization / translation
questions ("What do you need translated?" for example) were removed
from proposed set of questions for this year survey, perhaps this
question should be removed as well.
> "What kind of content do you track" might also be an equally interesting
> question. It also falls into the curiosity department, though.
True.
What should be the list of possible choices? Source code,
documentation, configuration, backup, binary files, other?
>> I'm not sure about having multiple choice vs. free-form question here.
>> Multiple choice is easier to analyze, especially if one would want
>> histogram of replies...
>
> And when you expect very many respondents, (1) you cannot afford to
> free-form; and (2) statistics over multiple choices, as long as choices
> are well seeded, will give you a good enough overview picture.
I wonder how many responses will we get this year. In 2006 there were
around 117 responses (but IIRC it was announced only on git mailing
list, wasn't it?), in 2007 survey there were 683 individual responses.
Git is even more popular now, I think...
OTOH there are some questions, like "feature requests/proposals"
question which *do require* free-form question. But they should
be few, and preferably for questions for which we don't need
histogram of replies.
I'll convert as much questions as possible to multiple choice
(pre-seeded), trying to come up with a good set of canned responses.
A question: if analysis of responses was not a problem, do you prefer
free form, or "select a choice" question?
>> Again: free form has some hassles, but so does coming up with good
>> choice of fixed answers in multiple choice question.
>
> You need to do at least one or the other, and I do not think there is any
> way to avoid that. Without a good choices, histogram would become useless
> (not necessarily because the answer will be dominated by "Other", but the
> seeing the choices tends to set the frame of mind when/before somebody
> answers the question). With free-form, you will spend the rest of your
> life analyzing to get any useful insight.
True... well, depending of course on the number of replies. Analysing
around 50 free-form replies (half of 100 individual responses to survey)
is not impossible; analysing 250+ is a lot of work.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2008-07-24 0:11 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-23 1:25 [RFC] Git User's Survey 2008 Jakub Narebski
2008-07-23 4:39 ` Junio C Hamano
2008-07-23 7:47 ` HP-UX issues (WAS: Re: [RFC] Git User's Survey 2008) Miklos Vajna
2008-07-23 21:38 ` Jakub Narebski
2008-07-23 23:45 ` Miklos Vajna
2008-07-23 11:06 ` [RFC] Git User's Survey 2008 Jakub Narebski
2008-07-24 11:46 ` Marek Zawirski
2008-07-24 12:09 ` Mailing lists, was " Johannes Schindelin
2008-07-25 17:23 ` Shawn O. Pearce
2008-07-25 18:49 ` Junio C Hamano
2008-07-25 21:52 ` Jakub Narebski
2008-07-25 21:57 ` Shawn O. Pearce
2008-07-25 22:11 ` Junio C Hamano
2008-07-25 22:13 ` Shawn O. Pearce
2008-07-26 10:54 ` Jakub Narebski
2008-07-26 12:19 ` Marek Zawirski
2008-07-26 21:50 ` Shawn O. Pearce
2008-07-26 21:52 ` Jean-François Veillette
2008-07-25 22:15 ` Petr Baudis
2008-07-26 15:51 ` Jing Xue
2008-07-26 16:47 ` Jakub Narebski
2008-07-26 17:51 ` Shawn O. Pearce
2008-07-26 18:17 ` Jakub Narebski
2008-07-26 19:06 ` Johannes Schindelin
2008-07-26 18:38 ` Scott Chacon
2008-07-24 14:07 ` Jakub Narebski
2008-07-23 9:53 ` Johannes Schindelin
2008-07-23 13:08 ` Jakub Narebski
2008-07-23 13:18 ` Johannes Schindelin
2008-07-23 14:54 ` Robin Rosenberg
2008-07-23 16:00 ` Johannes Schindelin
2008-07-24 10:44 ` Jakub Narebski
2008-07-23 23:30 ` Jakub Narebski
2008-07-23 23:33 ` Johannes Schindelin
2008-07-23 23:53 ` Stephan Beyer
2008-07-24 5:02 ` david
2008-07-24 8:57 ` Stephan Beyer
2008-07-24 10:37 ` david
2008-07-24 9:52 ` Jakub Narebski
2008-07-26 15:34 ` Jakub Narebski
2008-07-27 11:24 ` Nguyen Thai Ngoc Duy
2008-07-23 16:43 ` Junio C Hamano
2008-07-24 0:10 ` Jakub Narebski [this message]
2008-07-23 14:54 ` Dmitry Potapov
2008-07-23 16:02 ` Johannes Schindelin
2008-07-23 17:01 ` Stephan Beyer
2008-07-24 8:24 ` Jakub Narebski
2008-07-23 17:17 ` Alex Riesen
2008-07-24 8:15 ` Jakub Narebski
2008-07-23 14:12 ` Stephan Beyer
2008-07-24 22:22 ` Stephan Beyer
2008-07-23 14:38 ` Dmitry Potapov
2008-07-23 15:43 ` Matthias Kestenholz
2008-07-23 20:09 ` Dmitry Potapov
2008-07-23 21:49 ` Jakub Narebski
2008-07-24 18:08 ` Dmitry Potapov
2008-07-24 21:06 ` Jakub Narebski
2008-07-23 21:44 ` Petr Baudis
2008-07-23 21:59 ` Jakub Narebski
[not found] ` <169F15EC-1A58-4C2A-84FC-3D14F7B4F1C5@yahoo.ca>
2008-07-23 22:46 ` Miguel Arroz
2008-07-23 23:49 ` Jakub Narebski
2008-07-24 10:11 ` Sverre Rabbelier
2008-07-24 14:45 ` Jon Loeliger
2008-07-24 18:18 ` Jakub Narebski
2008-07-24 18:50 ` Lachele Foley (Lists)
2008-07-24 21:08 ` Jakub Narebski
2008-07-24 17:57 ` Dmitry Potapov
2008-07-24 18:42 ` Jakub Narebski
2008-07-31 12:48 ` Jakub Narebski
2008-08-20 1:08 ` [RFC v2] " Jakub Narebski
2008-08-20 11:34 ` Alex Riesen
2008-08-20 12:04 ` Petr Baudis
2008-08-20 13:50 ` Jakub Narebski
2008-08-20 18:18 ` Alex Riesen
2008-08-20 20:14 ` Junio C Hamano
2008-08-21 1:30 ` Jakub Narebski
2008-08-21 3:10 ` Junio C Hamano
2008-08-21 11:19 ` Jakub Narebski
2008-08-20 21:18 ` Stephan Beyer
2008-08-20 21:26 ` Stephan Beyer
2008-08-21 11:11 ` Jakub Narebski
2008-08-21 21:26 ` Stephan Beyer
2008-08-22 0:06 ` Jakub Narebski
2008-08-21 3:22 ` Mike Gant
2008-08-24 21:36 ` Stephan Beyer
2008-08-25 0:41 ` Jakub Narebski
[not found] ` <20080825012653.GB28160@leksak.fem-net>
2008-08-25 1:56 ` Jakub Narebski
2008-08-20 7:31 ` Abhijit Bhopatkar
2008-08-25 22:08 ` [RFC v3] " Jakub Narebski
2008-08-28 0:28 ` Stephan Beyer
2008-08-30 1:33 ` [RFC v4] Git User's Survey 2008 (cover letters) Jakub Narebski
2008-08-30 19:00 ` Garry Dolley
2008-09-01 7:47 ` Paolo Ciarrocchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200807240210.13955.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).