There are lots - you probably want to pick a topic with deeply-held preferences, and a fairly large cluster of releated beliefs.
For CS-heavy participants, Vi vs Emacs would have worked 20 years ago - now maybe Java vs Ruby or Android vs iOS. On gaming, perhaps PC vs Console.
More idealogically, vegetarian vs carnivore might work, or direct volunteerism vs earn-to-give, or local vs distant (in space or time) charity targets.
Your CS related ideas have me thinking. I would like to see git vs. svn. In my view, which system to use depends on the project. I prefer svn for most of my projects (those which are small and will not be released), and I think most git users don't understand the various advantages and disadvantages of the different available version control systems. When I mention that I like svn, many git users act with incredulity, and I usually find through discussion with them that they never tried svn.
It's true that most projects don't need or use the advanced features of git, but this isn't a good reason to use svn, because git can also be used in a simple manner: http://git.or.cz/course/svn.html You're at no disadvantage compared to if you used svn.
But when you want to contribute to one of the big projects that does require the full power of git, you are at an advantage, because you don't have to learn a complete new version control system, only the extra git features you hadn't learned yet.
In my view, svn has a number of benefits over git. Let me offer a quick runthrough of why I prefer svn for small projects.
The main reason to use svn in my view is simplicity. git can't do many things svn does with as little friction as svn requires.
Centralized version control is definitely simpler than distributed. Distributed can be useful if you want to develop a feature offline (and find the svn ways of doing that to be a pain, as I do), want to work on something independently for a while, want to work on an experimental branch, etc.. But there's a good reason to prefer centralized in some cases. Distributed version control is too confusing for many people you might want to collaborate with. My research group has enough trouble getting my PhD advisor to use svn. Do you think this will be easier with git?
The documentation for git is pretty bad. In contrast to svn, I can't rely on the documentation for git making sense and basically have to Google for many things, even some things which are straightforward in svn (like svn keywords). The Pro Git website is pretty good, however.
One thing I like is having a incrementing number that refers to a unique version. You actually can get that in git, but it's a complicated command that I've never seen used in real life. This is just how svn works.
Let's say you are using git just want to print the hash and date of last modification in your code or document. svn has a keyword functionality to do this automatically when you update. git makes this at least moderately complicated (for silly reasons). There are several ways to do this, but editing the file directly with a script is unsatisfactory because the file will show up modified, unless there's some git way around this. In svn the files show up as unmodified. You also could pass in the hash at compile time, which is just extra work over svn.
I have heard conflicting things about partial checkouts in git. My impression is that they work but are more complicated than svn. Partial checkouts are totally normal and easy in svn. I do them fairly regularly, as well.
GUIs for git were still underdeveloped last I checked, or at least the free ones were. GUIs make a number of things much easier. At one point I started converting my repositories over to git because I wanted to work offline more often, but the lack of good GUIs made me stick with svn. (I have some other restrictions here that made some GUIs not attractive, and maybe I should look into this again.)
Here are the advantages I see to git/github: pull requests being code reviews and the distributed nature of the software. The former is great, as problems are caught early. The latter is not always an advantage, as I explained earlier, but generally is a major advantage in large projects.
To be honest, I could see myself changing my mind over this in the future, but for now I see no reason to switch from svn to git for most of the repositories I have.
The big thing (for some people) that you are missing with git is that it makes working with branches really easy. In my first job we used SVN and maintaining separate branches was a pain in the ass, to the point where we only did it for a release branch, while with git it's pretty trivial to the point where people use them all the time even when working locally only.
I do agree that git's documentation and UX for basic operations is not as nice as SVN.
edit: Also agree about the signalling part to some extent. I do feel like there's a tendency among some programmers to gravitate toward the most complex plausible technology in order to show how smart they are.
If you really need to branch then svn is the wrong tool to use, because branching makes a lot more sense for distributed systems. For the repositories I use svn for, I never once have had to branch in any complicated way. If I needed to branch in a significant way, I'd use git or hg. The most I've done is "branching" a file by duplicating it, and then later merging in the changes with a graphical diff tool. At this level, git is no easier or harder than svn, though you might consider this approach to be sloppier than git's approach.
Talking to some git people gives me the impression that they branch way more often than is necessary, though. Maybe if you have a hammer, everything looks like a nail.
Maybe if you have a hammer, everything looks like a nail.
Those grapes are probably sour anyway.
edit: To make a less snarky contribution, there's always a difficult balance between "those people are doing something that seems weird to me, I should probably just ignore them and go my own way" vs "if smart people are doing something that seems weird, it's probably for a good reason, maybe I should learn it".
If you're suggesting that I say I don't think branching is useful because I can't do it well in svn, or something like that, then I can't say much other than that you're mistaken. If you're not suggesting this, please clarify.
Yes, I have learned about branching workflows. I decided that they don't make sense for most of my repositories. For example, the repository I commit most often to is primarily a collection of text outlines on a variety of subjects. How would a branching workflow help me here? It wouldn't. In the 3 years I've been using this repository, branching never seemed like a good idea. Branching just seems like extra friction in the process. My impression is that many git people probably would branch in this case, and I don't understand what benefits they get from that. If you're aware of any, I'm listening.
The larger project my PhD is a part of uses git with a pretty standard git workflow, which I agree makes sense for the project. My claims are that large software projects have different requirements than small software/documentation projects, and that you might find different tools to be useful in each case.
Edit: If you thought the hammer sentence was snark, sorry for that. It was my attempt to explain why some people who use git might branch more often than is needed.
If you don't need git's features it's fine not to use it. I just brought up branching because you left it out of your comparison, but IIRC it's the main reason git was even created.
I suspect the main cause of git snobbery is that the types of projects for which it is more useful tend to be larger and more likely to be released, hence higher status.
The way the dynamic works is as follows: initially the programmers working on small projects prefer svn and the programmers working on big (higher status) projects prefer git. Then people start noticing that preferring git correlates with status (and possibly skill). So people who don't use either but what to appear to be high status programers (and even some svn users) start trashing svn.
Not sure why you were downvoted. You're definitely onto something. Signaling does seem to be one reason for git's success. Someone I know compared it to The Emperor's New Clothes in the context of how bad git's UI (at least if you were used to svn) and documentation are.
To be honest, I see signaling in a lot of programmer culture. I use Ubuntu, and I had a conversation with my brother about it. He told me while he'd like to have more recent software and the ease of use that comes with Ubuntu, he doesn't want to look like a moron, so he uses Debian. The choice is strictly utilitarian to me, so others' impressions are of no concern. I don't feel the need to signal how hardcore I am in my OS choice. To be honest, switching to Ubuntu has made things so much easier. If you start with Ubuntu server or the netboot installer, you don't need to add Unity or any of the other garbage included by default. I can still do poweruser things if I'd like to (and sometimes I do). The main disadvantage is that I'd like to use a rolling-release distro, but Ubuntu LTS is close enough.
Editor choice also seems to be strongly influenced by signaling. Having tried both vim and emacs and rejecting both*, I'm struck by how condescending many people are about my editor choice. I use Geany at the moment, which is similar to Notepad++. I've had a few conversations that basically went like this:
"If you use any editor other than vim or emacs, you are a moron."
"I don't use vim or emacs. Which other editors have you tried?"
"...none. All others are terrible!"
These people generally have not considered any other editors at all. If they did, they considered Sublime, which is nice, but not open source, and I prefer open source. Many people seem to automatically assume that my editor of choice is garbage, despite the fact that I tried a bunch out at one point and picked the one that fit my needs best. I am yet to talk to anyone with these opinions who considered more than a couple editors when making a choice.
* This was before I heard about org-mode, which might cause me to switch to emacs in the future.
"If you use any editor other than vim or emacs, you are a moron."
"I don't use vim or emacs. Which other editors have you tried?"
"...none. All others are terrible!"
This is about the point at which my response would be "How would you know, then?" or, worse, "I try not to form strong convictions about subjects where I don't have evidence worth speaking of."
Fortunately, these days I get to work with people who are less of technical assholes than myself, so the subject doesn't come up.
SJW / NRX (or symmetric positions more towards the centre on both sides as appropriate)
Collectivism / individualism
Virtue ethics / consequentialism
I'd be interested to see your results!
And I wouldn't invent a new name for ITTs for two reasons: First, you're cutting down on the ability of people who are interested to find other examples, but not teaching them the commonly used name (and limiting how many ITT-interested people find you!). Second, I think the ITT name makes sense, Turing's original example (which he called the Imitation Game) was basically an ITT for gender; it makes sense to keep the allusion.
These are great suggestions! (As are others, suggested in other comments.) Thank you!
When I gave my presentation last night I made sure that people knew that it was called the ITT by others and that was what to search for (I also pointed them to UnEY). I'm still on the fence about pushing the name (ITT is really hard to say) but I'll keep your reservations in mind.
I'll keep you informed of the details moving forward. :-)
I recommend doing tests as closely related to values and as far removed from facts as possible, for roughly the reason Eliezer is against devil's advocacy. Policy discussions at least have the benefit that they combine facts and values, and ideologies are often about reasoning styles instead of conclusions.
Hello! I'm running an Ideological Turing Test for my local rationality group, and I'm wondering what ideology to use (and what prompts to use for that ideology). Palladias has previously run a number of tests on Christianity, but ideally I'd find something that was a good 50/50 split for my community, and I don't expect to find many Christians in my local group. The original test was proposed for politics, which seems like a reasonable first-guess, but I also worry that my group has too many liberals and not enough conservatives to make that work well.
What I plan to do is email the participants who have agreed to write entries asking how they stand on a number of issues (politics, religion, etc) and then use the issue that is most divisive within the population. To do that, however, I'll need a number of possible issues. Do any of you have good ideas for ITT domains other than religion or politics, particularly for rationalists?
(Side questions:
I've been leaning towards using the name "Caplan Test" instead of "Ideological Turing Test". I think the current name is too unwieldy and gives the wrong impression. Does the ITT name seem worth keeping?
Also, would anyone on here be interested in submitting entries to my test and/or seeing results?)