As part of
my research, I may have to
conduct a survey among Debian contributors. The word "survey" usually elicits
frowns because surveys are often misconducted. MJ has taken the time to draft
up
some advice to surveyors.
Problems with surveys generally fall into one of two categories: content and
presentation. I'll refrain from making statements about content (Wikipedia has
some stuff on
questionaire construction) and instead
concentrate on presentation in the following.
Commonly in the digital age, surveys are administered via a web page or
e-mail. In my recent
Ph.D. transfer report,
I identified a number of shortcomings with these approaches:
Asking Debian contributors to click radio buttons on a web page is a bit like
expecting a mountain biking champion to ride a tricycle across a paddock:
painful, if not offensive. Furthermore, web surveys can only be taken while
on-line, when most of us have better things to do.
E-mail surveys address some of these problems, but create new ones: answers
cannot be constrained to a domain (think multiple-choice), character set and
formatting issues make evaluation difficult, and it's impossible to prevent
users from attaching comments or modifying responses.
In thinking about the issue, I came up with a third means to administer
a survey: a console tool. Think of a Debian package which provides a console
application controlled by a study-specific data file. The data file specifies
the questions and their answer domains, and the tool presents those to the
participant. Since most of Debian happens on the console anyway, such an
approach to surveys seems more appropriate.
Interaction with the survey tool would be as easy as pressing the
2 or
4 keys to select one of the multiple choices, and the tool would
immediately move on to the next question (and not wait for the user to hit
enter). Obviously,
n and
p should allow navigation back and forth
across the set, and
c would spawn a text editor to give the user a chance
to attach a comment to his/her current response, in which s/he might criticise
the question or provide additional information. Finally, the tool should be
able to pick up where it left off, should the user chose to exit/suspend the
survey for now. Integration with
debconf or another interface abstraction
is also worth consideration.
There is more to it: people change their minds and should thus be able to
amend responses. With their consent, it might be valuable to track such
changes and inquire about their motivations. As I was thinking about how to
realise this, I suddenly arrived at version control: use
Git as a backend storage. The set of cool features this
would enable seems to be endless: it works off-line and can be used to track
aforementioned changes, but also offers the possibility to create a squashed
result in case the participant prefers to submit only the final result.
Furthermore, it's a trivial change between anonymous submissions, and
submissions authenticated by a
GPG signature.
In addition, the survey tool should be able to display questions according to
previous responses (control flow). For instance, if the survey determines that
a given user is a contributor to the bug tracking system, but not a project
member, it wouldn't make sense to ask when s/he received his/her Debian
account. Furthermore, questions could be dynamically creatable from context,
so that the survey can drill into depth depending on previous responses,
rather than asking the same questions to all participants.
I am currently applying for funding to outsource the development of such
a tool. If you are interested in coding it up and getting paid for it, speak
to me. Here are some more specifications to keep in mind before jumping on:
- the result must be released under a Free licence.
- the tool should be implemented in Python and use PyGit. Missing Git
bindings should be implemented in and contributed to PyGit.
- the logic should be in a reusable module, and the application a thin layer
on top of that.
- data files must be able to specify at least multiple-choice, Likert-scale
and free-form-answer questions.
- data files should be able to encode conditional flow.
- data files should encode whether submissions can/must/mustn't be anonymous.
- data files should encode policy whether changes can/must/mustn't be tracked.
- it would be nice if data files could encode dynamic questions assembled at
run-time.
- questions and answers must be translatable using standard .po files.
- in addition to the console interface, a debconf interface would be nice.
- every response results in a Git commit object, and commit messages may be
automated or queried from the user, depending on context and configuration.
- data files should provide parent/seed SHA-1 hashes such that every
participant essentially commits to a branch off the same parent, using e.g.
uuencoded bundles.
- submission should take place via git-push or git-send-email,
depending on whether a net connection exists or not.
These are likely to be incomplete, but should convey the basic picture.
Feedback is always welcome!
NP:
Oceansize:
Frames
Update: James Andrewartha pointed me to
purity, which asks multiple-choice
questions on the console. It has the kind of interface which I envision.
Also, Chris Lamb suggested
this personality survey as a base line. Well, actually he
just suggested I look into it.
In the "bits from the Planet Debian maintainer" department...
Steve Kemp has been running a little index and search script for
Planet Debian for a couple years now that lets you search for old
entries that have showed up on Planet Debian. He was going to take his
system offline but, since it was in use by a variety of people, he opted
to move it into the default Planet Debian instead.
You should be able to see and use the search box in the sidebar on
Planet Debian now. Feedback is welcome, I'm sure. Thanks to Steve
for the fantastic addition to our aggregator.
Benjamin Kosnik of Red Hat put together a guide on the GCC web site with
information on porting applications to the upcoming GCC 4.3 release. He
integrated some information from my blog and added a number of new items.
If you run into any issues while moving to GCC 4.3, I suggest you 
Well, this is actually our fourth day home, I just haven't had the time or
inclination to write anything until now.
We had an uneventful trip home on the 29th. I think I'm getting more used to
these long-haul flights, the time went pretty quickly. There is much to be
said for Qantas' in-flight entertainment system. And Melatonin tablets.
We had a good, jam-packed three weeks in Australia.
We landed on a Sunday morning, at around 8am. Sarah's Aunty Glenda picked us
up from the airport, and we stayed with her for the week. We caught up with
two sets of friends on the Sunday, and managed to last until the evening
without crashing.
I spent the week working from the Sydney office. Jetlag is a wonderful thing
for making me into a temporary morning person. I was at my desk by 8am every
day. I'd forgotten how early the sun got up in Australia in the summer time.
Monday in Sydney is Sunday in California, so Mondays are blissfully quiet
and great for getting things done. The beauty of getting in by 8am meant I
still caught Mountain View from about about 1pm onwards for the rest of the
week, so that was good. I got a lot done while I was in the Sydney office.
On Tuesday morning we went to the US Consulate to sort out Sarah's visa
renewal. It was a no-brainer, and our passports were back at my parent's
place within 48 hours.
Thursday night was the Sydney office Christmas party. The Friday night we
flew out of San Francisco was the Mountain View office one, so it was good
to be able to catch a party somewhere. Got to love working for an
international company. Photos 
Well its been a while since my last post and since I’ve celebrated my 29th Birthday on December 19th, Spent a wonderfull Christmas with my family ( 
Happy new year everyone!
NP: Moby Jam for the Ladies (Nevins Club Blaster mix)
I first heard about the 
