Thread by @cshekhar

1/n #Thread on excerpts from an #essay "A #group is its own worst enemy" by Clay #Shirky ( #Social #software)

Original article can be found here - web.archive.org/web/2013120121…

or gwern.net/docs/technolog…

2/ hardly anybody really studies how to #design #software for human-to-human interaction.

so many of them just throw things together and allow themselves to be surprised by the social interactions that develop around their software.
#HCI

3/ As soon as the Internet happened, s/w stopped being solely about computer-to-human interaction and started being about human-to-human interaction. We had new applications like the Web, email, IM and forums, all of which were abt humans communicating with 1 another through s/w.

4/ Clay #Shirky - My definition is quite simple: it’s #software that supports #group interaction.

Groups are a runtime effect. You cannot specify in advance what any given group will do, and so you can’t instantiate in software everything you expect to have happen.

5/ Bion was a #psychologist who was doing group therapy with groups of #neurotics.

He said that humans are fundamentally #individual, and also fundamentally #social.

Human groups are “hopelessly committed to both”

6/ There are three patterns of groups
1. The first is sex talk, what he called, in his mid-century prose, “A group met for pairing off.” That means is, the group conceives of its purpose as the hosting of flirtatious/salacious talk/emotions passing between pairs of members.

7/ The second basic pattern is the identification and #vilification of external enemies.

If you cared about Linux on the desktop, there was a big list of jobs to do. But you could always instead get a conversation going about #Microsoft and @BillGates

8/ The third pattern is #religious #veneration the nomination and worship of a religious icon or a set of religious tenets.
The religious pattern is, essentially, we have nominated something that’s beyond critique.

9/ If you are building social software then you need to accept three things and design for four things.

Of the things you have to accept, the first is that you cannot completely separate technical and social issues.

10/ The second thing you have to accept: members are different from users.

There is some group of users that cares more than average about the integrity and success of the group as a whole.

11/ The third thing you need to accept: the core group has rights that trump individual rights in some situations.

12/ If u don’t accept these up front, they’ll happen to u anyway. You’ll end up writing documents that says, “Oh, we launched this and we tried it, and then the users came along and did all these weird things. And now we’re documenting it so future ages won’t make this mistake”

13/ Four Things to Design For

14/ The 1st thing you would design for is #handles the user can invest in. Now, I say “handles” because I don’t want to say “#identity”; identity has recently become one of those ideas where, when you pull on the little thread you want, this big bag of stuff comes along with it

15/ Second, you have to design a way for there to be members in good standing, some way in which good works get #recognized. You can do more sophisticated things like having formal #karma or listing “member since” dates or noting who is a #Pro user who helps #fund the #system.

16/ Three, you need some barriers to #participation, however small.

You have to have some cost to either #join or #participate, if not at the lowest level, then at higher levels. There needs to be some kind of segmentation of capabilities.

end/ Finally, u have to find a way to spare the group from #scale. Scale alone kills #conversations, bcz conversations require dense 2-way conversations. In conversational contexts, #Metcalfe’s Law— the number of connections grows with the square of the number of nodes—is a drag