terriko: (Default)
This has been cross-posted from Geek Feminism, but I found this research really fascinating so you're getting a full copy here too.

Rock on!
You might think if you put together a lot of smart people, you'd get a smart group, but new research into group intelligence shows that's not always the case. (For those of you who don't have access to online journal subscriptions through your local library or university, there are more details in the Carnegie Mellon University press release.)


What we found is that the intelligence of the team members was not significantly related to the collective intelligence, either positively or negatively.

[...]

Our first observation and the one that surprised us the most was that the proportion of females in the group seemed to be strongly predictive of the collective intelligence of the group.


However, when they looked more closely they realised that it wasn't the gender that mattered, but rather the social sensitivity of the group members (previous studies had shown that women tend to score more highly in social sensitivity).

It's not the intelligence of the group members that matters; it's their social sensitivity.

So the more your group members were socially sensitive, the better the group performed in measures of collective intelligence. The key here was that group members need to collaborate, and to do that they needed those social skills to help them work together. This includes some different conversational patterns: groups where one or two people dominated conversations exhibited low collective intelligence, while groups where more people contributed had higher collective intelligence.

This scientific research is potentially a big blow to the standard "meritocracy works" theory often espoused in open source and computing groups. Standard meritocracy rules say you do clever things and you get accepted, and this will make for perfectly good teams. But given that there's often bias that dismisses "soft skills," it turns out that folk may actually be using typical geek meritocracy rules to weed out some of the people we need to make the group most effective as a whole.


Some of my female colleagues would like to conclude that you simply just need to hire more women. While that might be easier, what it really suggests is that you need to pay attention to what people refer to as these "softer skills" and thinking about who's going to be a good team player, not necessarily focused solely on individual achievement, individual accomplishments.


So if you want to claim that the best way to build tech teams is meritocracy... you might want to think more carefully about how you define merit.


Rock show DS



The quotes in this article are drawn from Bob McDonald's conversation with Dr. Anita Williams Woolley, the lead author, on the Quirks and Quarks interview aired October 9. You can download the podcast of the segment on collective intelligence here.
terriko: (Default)
My paper was accepted to HotSec! This is the web visual security policy research I've been working on for a while in various forms, but this is my first proper paper on the subject (although some of the related issues were touched upon in my W2SP paper). Getting in to HotSec is rather a big deal, as it's among the top publishing venues available to me. I was one of 11 papers chosen (out of 57). Go me! So I'll be heading down to DC on August 10th to present it. If you're curious, we should have the final camera-ready copy done in a few days.

My HotSec acceptance causes a bit of a logistical problem, though, since I've also been accepted to speak at LinuxCon on August 12th. It's a bit of a long story as to how I ended up applying at all, but the short and relevant part is just that I wasn't originally planning on submitting to HotSec and didn't realise I'd have such a conflict. (There's a longer story involving speaker diversity issues and good folk willing to go out of their way to work on solving them.)

Anyhow, I really *should* send my regrets to LinuxCon as, academically speaking, it makes a lot more sense for me to go to USENIX Security immediately following HotSec. Especially this year, as I'm hoping to graduate soonish (more ish than soon; don't get too excited) and should be networking as much as possible. But I chatted with my supervisor, and he agreed that it's a bit of a toss-up as to which is more valuable to me: it's nearly as likely that the person I need to meet will be at LinuxCon and that I'll wind up finding a job through open source connections. Raising my open source speaking profile may be just as useful.

What's clear is that Mailman benefits more if I go to LinuxCon, since I'm going to be talking about upcoming awesomeness in version 3.0. The other day, I had someone comment that they didn't even realise Mailman was in active development... ouch. I think getting people interested now, while we're in alpha, is probably absolutely perfect timing. Plus I'm hoping to have some nice stuff to show off from my excellent GSoC students, if they're willing to let me talk about what they've been doing with the archives, and maybe some of the other projects as well.

If you're interested in coming out to LinuxCon, they helpfully gave me a 20% discount code to share. Drop me a note and I'll pass it along (they asked we not just post the code publicly, but I can pop it in a private post later). If you can offer me a job then I'll be able to tell my supervisor I made the right choice. Heh. No, seriously, it's just nice to see people.

Anyhow, I'll make my final decision when I see if the travel arrangements are ridiculous, but it *should* be relatively easy to go from DC to Boston after HotSec, so let's hope this all works out!
terriko: (Default)
Of course, now I've completely forgotten what I was going to do once I got this compiling...

Anyhow, for my own records, here's what I had to do to compile the WebCore portion of Webkit using XCode 3.1.4 (heh) under OS X 10.5.8.


  1. Follow these instructions for debugging.
  2. Make sure to compile JavaScriptCore (to get rid of the JavaScriptCore/Platform.h errors). Note that is has to be compiled into the same directory as WebCore.
  3. Edit CSSPropertyNames.h to add a property for CSSPropertyWebkitDashboardRegion (I was getting a bunch of errors saying it wasn't defined in that scope)
  4. Make sure that the WebCoreSQLite3 library can be found by adding WebKit/WebKitLibraries to the library search path.


Doesn't seem so bad, now that I've got them enumerated. I'm guessing the CSSPropertyWebkitDashboardRegion thing is an actual bug in how the scripts are called in xcode? Guess it's generated, and I need some flag to make it generate correctly? Anyhow, this works for now. Pity it took a couple of days to get it sorted out.
terriko: (Default)
As a follow-up to yesterday's irked post. This post is largely for myself in case I wind up getting these or similar errors again and can't remember what I did.

Context: I'm hoping to use WebKit to try out some research ideas. It builds fine using the build-webkit script provided, but balks when I try to build it in XCode.

If you're getting a pile of errors when building WebKitCore (e.g. following the instructions here) that are all about JavaScriptCore/Platform.h, then the problem is just that you need to build JavaScriptCore first. And make sure that you've got the BuildOutput set to be in WebKit/WebKitBuild for both, or they won't see each other.

Also, this seems like a nice summary of the cleanup steps if you're trying to make sure you're not using any old files.

It's still not building perfectly for me, but I'm not getting 10k errors anymore so clearly I'm getting closer to having this working. ;) Of course, I've also discovered the WebKitTools/Scripts/debug-safari script which runs it in gdb, so I probably don't need to be doing this anymore to have a debugger, but now I figure it's a halfway decent learning experience.

The biggest problem with webkit other than my current build errors is that a full build takes an hour. That's a lot of time to kill while my code's compiling. And I'm so used to working with web code/scripts that I'm not used to optimizing my time while the compiles happen! I've already caught up on my email, folded the laundry, had a shower... and now I'm blogging while I try to let WebCore finish and see if it gets more than the 4 errors it's already got.
terriko: (Default)
You know what's annoying? Trying to fix include paths in my build when what I really needed to be doing was following the instructions.

I was feeling really foolish when I saw that, but now that I've followed said instructions, it still doesn't work... Oh, coding. When you sometimes don't know if you've just typed the wrong character somewhere or if the whole thing is horribly broken. I'm sure this will be very obvious when I look at it later, but I've got a rehearsal to get to.
Page generated Oct. 17th, 2017 02:45 pm
Powered by Dreamwidth Studios