ForFewAndMany

This is a description of SocialSoftware made to work for two parties:

Interaction between the few and the many is difficult.

On the whole, it’s just a mess.

This is about some software that could work for the few and the many to communicate more effectively with one another.

Say: The thousands and thousands of GNOME users, with respect to the limited number (dozens?) of GNOME developers.

The basic thing is you want the many to be able to collect and prioritize people’s concerns. And then you want the few to be able to address those concerns, or at least the most important among them, and make a formal respond to them.

The few can then say to a nagger: “Don’t tell me about it by email. Just participate in the concerns collection.”

How would such a thing work?

ConcernsCollection

Perhaps a little something like this:

Each user can sign up for an account. There is a requirement that accounts be linked to real people, and some form of InternetBonding or WebOfTrust can be used to make sure that accounts are honest.

Other ideas:

See also

CategorySocialSoftware

Discussion

Bayle, you wrote something about people dividing up points in a WebOfTrust. Some sort of allocation scheme- that’s what led me to the 10 concern points idea. Do you remember the name? It isn’t in CategoryRatingSystem, I don’t think.

I anderstand, that this procedure will help to show the main topics to work on. I do not understand, how this could help to efficiently share already worked out topics. This seems to me a question of effective tagging.

Another idea: by signing in you get some concern points for free. You may buy as many concern points you like for money. If a concern is fixed, the amount of concern points collected on this issue goes to the editor(s) of this topic. You may spend your concern points earned for ranking other concerns, or transfer them back to money.

Yow! I hadn’t thought of that! That’s a great idea, and links this in with those OpenSource bounty programs. I had neglected to think of a market as a communications system between the few and the many.

I worry, though- the “free” concern points, if they can be sold, are an incentive to try and cheat the authentication system.

Also: It is not clear if a person loses all their concern points, when someone solves their concern. If that’s the case, then they do not have a voice any more. The primary purpose here is to allow people to express their voice.

But I do think that a mixed system would be good here.

As for the question of: “How do people organize their concerns?”

Perhaps concerns are organized through the community via wiki. Each concern has a ConnectionPoint. The ConnectionPoint is 4-8 lines long; just there so people can put up signs about how things are organized.

Seiji Zenitani maintains a Carbon Emacs Package and he has a low-tech solution: You can cast votes on his to-do list. In other words: He chooses what he might be interested in working on, and “the many” help him by setting priorities.

People have a tendency to overengineer…

Lion: it was ReputationBudget. Thanks, I just added it to CategoryRatingSystem. Yeah, this is actually totally the sort of application I had in mind; not just reputations of people, but ratings of various things, such as favorite books and movies, and prioritization of concerns (maybe it should be called “RatingBudget?”).

The ReputationBudget way of doing things would be to allow each person to publish a machine-readable document that gives their take on what the most important problems are. Then, you have a “master page” that weights the individual’s documents. In order to get linked to from the master page, you have to get an account or pay a fee (to buy Concern Points) or whatever. This system is more decentralized in that interested third-parties could, if anyone wanted, extract the information from the individual documents and weight them in different ways than the “master page” did.

Note that “priorization of concerns by a large group of people” is just one thing that might fall under ForFewAndMany. Also, sometimes a single class of people need to do the same thing.

For example, my friend DanaDahlstrom? told me about the University of California system student government. They have this big meeting where delegations from the student governments of various U.C. schools (hundreds of people) show up and do various things. One of the things they do is decide on three “agenda items” for the organization for the coming year. They have a bunch of workshops to talk about (and try and sell to one another) various proposals, and then they have this big plenary session guided by Robert’s Rules where they make a list. The way something would be added to the list would be someone would make a motion to add it, and if the motion passed, it would be added.

Dana noticed that this mechanism wasn’t ideal; at the beginning of the meeting, it was easier to add things, but once two things had been added, it was much harder to add the last one (because everyone knew that there was only one slot left, and many of them had other things that they wanted more). In theory, someone could have made a motion to undo one of the previous items and replace it, but since the meeting already dragged on for so long, no one wanted to move “backwards”. I think there were other problems too (I’d let him tell you, but I think he’s out of town for a week).

He hit upon a better solution. Before the plenary session, each delegation would make a priority list. Then, using a form of Condorcet voting, these lists would be combined to form an overall priority list. After you did this, you would have the plenary session with Robert’s Rules. This way, it’s less probable that popular proposals would be overlooked because they weren’t brought up until the list already had 2 of 3 slots filled. The Robert’s Rules session at the end ensures that, for example, two contradictory proposals wouldn’t both make the list.

Dana is proposing his method for the next meeting, so it hasn’t been tried yet.

So, in this instance, a large group of people needed to make a prioritized list together. One (inferior) way of doing it was discussing items and adding them to the list by majority vote. A (proposed superior) way was to first use a Condorcet method to combine each member’s ranking into a group ranking, and then for the group to discuss the final list using that list as a starting point.

(btw, here is a web page that computes group ranked lists using a Condorcet method, although I haven’t personally tested it. I think there might be more software at linked from http://condorcet.org)

I wonder if, without getting into some kind of voting system (though that’s quite interesting too), just having two parallel wikis, for “the few” and “the many” wouldn’t be enough ? A “concerns” wiki and a “response” wiki, or just one wiki with some clear rules as to who can post what …

The “most important” concerns would also receive the most attention, so they would be the best linked (If you have pages organizing concerns by category, etc.), the most readable, the most terse … so they’d naturally get more attention from the “few”.

So all you’d need is a wiki with this explicit goal : to list, describe and categorize concerns. And eventually a wiki (or a password-procted wiki) with some kind of automatic interlinking between corresponding pages of the two.

Well, in small groups consensus can sometimes be reached, or the various points of view can be reconciled on a wiki. But for a student body of hundreds of people, this can take a long time. So trading off speed for consensus… At least Emile’s proposition doesn’t seem overengineered. :)

Engineers be damned! We need a TechnologySolution.

Your cute to-do solution might be fine for some guy some where, but the GNOME project is huge, and the number of users extraordinarily large.

You have to build something that isn’t there already.

You can’t do Wikipedia with WardsWiki.

Well, didn’t wikipedia start out using UseMod wiki and CamelCase ? =)

I don’t think it’s only a question of TechnologySolution versus SocialSolution?, it’s also about keeping the design simple and not too feature-ridden, at least at start.

So I’d say : first get the process working with a wiki for concerns, etc. And then, if it looks like it’s needed, a voting system can be added. And improved.

The main advantage I can see in directly implementing a weighted voting system would be that it may have better affordance than a wiki. But affordance isn’t as much of a problem when you’re working with a large group.

Of course, it’s quite possible that GNOME already found out that a wiki alone wasn’t enough for efficiently collecting concerns, and that’s why something more focused is needed - but then, unlike Lion, I know very little about the GNOME project :-P

(By the way, I don’t understand “Engineers be damned! We need a TechnologySolution.” - aren’t engineers the ones who would be expected to come up with TechnologySolutions for everything ?)

Is that true? Did Wikipedia start out with UseMod?

But, I’m concerned that that discussion is unnecessary here. I’m not so interested in talking about how the thing is implemented.

However, I do think: There are things where, you don’t get to level N, and it’s just not the thing you’re building.

If wiki is made without a hyperlinking notation, for example, it isn’t wiki. And there’s no need to start from that point.

In this case, without a ReputationBudget, it’s not the same thing.

The goal is to make it so that people can’t just vote for anything. The goal is to force people, with technology, to economize on their interest. If the word “force” sounds too hard, I can put it another way: We model the intrinsic limits on developer’s time and energy.

When a person asks questions about prioritizing, it is a substitution for having the exact same conversation with the developers.

We replace the questions (“will you work on this? do you have time for this? I care about this,”) and answers (“if I work on that, what about my work on this? what about what those people want?”) with a proxy model.

If you just have people voicing feelings on a wiki, you don’t have the hard questions.

At TwinOaks, they have a yearly budget session. EVERYBODY must perform budgeting. That is, every single individual writes the budget for TwinOaks. Then the planners average it out, and present the final budget. (The community can reject it.)

The reason they chose to do this, is because when they didn’t, everyone thought that one special interest or another had taken special hold over the planner’s ears. They always figured that some sort of infiltration had happened.

Also, people didn’t think, when they didn’t have to apportion anything, about what had to be lost for something else to be gained.

When they did do mass budgeting, everyone understood:

  • Budgeting involves hard decisions.
  • There aren’t any secret cabals at work here.

I think this is the sort of frame to think about our app from.

It’s not about just collecting concerns. It’s about making visible the concerns that people have.

This page is mostly about solving the ForFewAndMany problem with, among others, a ReputationBudget system. I guess I was mainly saying that that doesn’t require a reputation budget, and that you can also approach it with just a couple wikis. But, since the beginning this page has been talking about a more precise system, not the general “for few and many” topic, so we may as well leave it that way :)

And yes, I agree with the technology to “force” people in one direction. A wiki can do anything ( “ … but badly.” ), so a wiki doesn’t seem very suited for focusing on a specific problem. Something hard-coded to force people to focus on a single issue can be a good move.

The low tech solution would provide us with a lot of features, so I wouldn’t be too quick in rejecting it. Here’s an example how:

  1. Developers and users agree on a limited number of tasks that can be worked upon. These tasks are written on the tasks page.
  2. When you want to add something on to the tasks page, you’ll have to remove something else. This will be controversial, so you will have to diskuss it on the tasks’ talk page. There will be an informal decision-making process.
  3. This informal decision-making process will involve explaining the new task on its own page. The new task will also have a talk page where discussion can take place.
  4. Somebody will have to make the real change to the list of tasks. Since this page is so important, only respected community members will be able to do it. “Highly respected” will be an informal measure. Humans are quite good at this kind of assessment, however.
  5. The features on the task list can get reordered. The same process applies. Arguments redirected to specific pages. Only respected community members can make the changes to the main page.

It is not immediately clear which part of this process needs controls that go beyond ordinary wiki features.

Vandalism, trolls? I don’t think so.

People gaming the system by assuming too much? People trying to fake being respected community members when they are not? I believe a reputation tracking and voting system will make this kind of discussion easier, because “the system” allows or forbids certain actions. You will have a lot of discussion involving the system, however. And I’m not sure you will be able to give satisfying answers to all the questions. So using a system for the controversial parts of the process will not prevent the discussions from taking place. All it will do is shift the discussion from the real issues (who is a respected community member and why?) to software design issues (who wrote this piece of orwellian crap and who controls it?).

SilentMajority issues and people with too much time at hand could be something that disrupts the issue. At least voting makes it clear that everybody is supposed to cast exactly one vote. In an informal way, a wiki will also allow you to delegate responsiblity, however: If somebody is speaking up on your behalf, there’s no need to join the fray.

When you want to add something on to the tasks page, you’ll have to remove something else. This will be controversial, so you will have to diskuss it on the tasks’ talk page. There will be an informal decision-making process.

1,000 GNOME users?

Even 100’s… Wow. Wow.

The cost of expressing concern is so incredibly high, I don’t know that anyone would even bother to do it.

If talking and decision taking is so unbelievable, then I think the vision of involving the many is just as unbelievable. It would be an illusion to believe that a technological system can replace the discussions needed for informed priority setting.

Unless you’re arguing for something much simpler. Giving the many only very limited choice – like in our governments, where we traditionally vote for people that will govern in our name.

But then again did we not hope in some distant corner of our mind that using wikis and technology would give us – the many – more power? Empowering the many? Would that not require that the many do a lot of talking? To be afraid of that is to deny empowerment of the many, I think.

Nice page, hadn’t followed it. As far as “People have the Power” is concerned I guess Alex is right: people have to take the effort to do this work. The engeneers, when genius engough, have the change to effectivate and mininalize this work people still have to do. Engeneers have the chance for to make people think: “Wait a minute: It’s that easy? I can do it with that little effort and all the others can do it just as well? Hey, then I might even work! I’ll stick to it a little and invest some energy in it”.

This is about communication, not decision making.

This isn’t “the many make the decisions about what gets worked on.”

This is about “we devs have some sense of what the many are concerned about,” and “we devs get to respond to concerns.”

This idea was inspired by two things:

  • general observation
  • specific comments that GNOME developers have made about being overwealmed, confused, and generally not knowing about the general public’s concerns
  • specific comments that GNOME developers have made, asking for some way or process so that the general massive populaces concerns can be collected together and prioritized.

This is not for priority setting. It’s for communication.

It may happen that, if the GNOME devs find that there is general concern about some thing Foo, that they will be influenced to work on it.

It may also happen that, if the GNOME devs find that there is general concern about some thing Foo, that they will decide: “We can’t do that for another 4 years, because of reason Bar.”

What is good here, is that:

  • rather than feeling ignored, the public will have a response.
  • if a concern is not addressed, the public will know exactly why: that concern was not shared by enough people, and the devs couldn’t reasonably be expected to address it.
  • the public will have a sense of itself. Sometimes, someone is very vocal, and it sounds like hoards of people agree with that person. But, in reality, it’s a sham. With clear allocations of concern, it will be clear what people care about the most.

So, the theme here is: “Communication, but not Decision Making.” Communication is very valuable, in it’s own right. “Sensing.”

As for the issue of: “But then again did we not hope in some distant corner of our mind that using wikis and technology would give us – the many – more power? Empowering the many? Would that not require that the many do a lot of talking? To be afraid of that is to deny empowerment of the many, I think.”

A WeldingProcess necessarily happens in a tight space with room for few people.

Most software development projects, right now at least, are a WeldingProcess. Everything is delicately balanced in place, thought and communication and action (ThinkTalkAct) are on extreme economy- you know about this. We’re talking about making machines, here. It’s like the dedicated circuitry and robotics in a clean room that help make chips. Everything’s in lock-down.

This is why we need ForFewAndMany. We do need communication between the few and the many. But it needs to be carefully prepared before it’s addressed by the few. It needs to be clean, it needs to be prioritized.

What happens if this doesn’t happen? Festering. Big concerns amongst the many are lost. Small concerns held by vocal people are heard loudly. Confusion. Eventually, anger. And then we see postings to forums about how the GNOME dev’s don’t care about such-and-such, and how the little guy doesn’t have a voice. People start to compete for the attention of the devs, greatly irritating them. Secret social processes start taking over. People plot how to get so-and-so to bend an ear. A chill spirit runs through the social machinery.

What happens if you do this? I think: Clarity. A dev can simply say, (if someone tries to talk with them about something,) “register a concern.” The many now have a clear target: Concern points.

By the time GNOME devs issue concerns, they can say, very clearly: “This is what the community wanted addressed. Here are our answers.”

Ok, I’m with you. So what would the simplest thing be that could possibly work? We have to start somewhere, and starting small is easy and incremental improvements make us feel good.

Some observations:

  1. IRC channels with hundreds of people are usually not nice places. I don’t like #debian on freenode, for example. It is hardly social. On the other hand, I feel very much at home at #emacs.
  2. Some projects I was interested in would delegate all feature requests and patches into a bug-tracking system. It felt very cold and unpleasant.
  3. People like to talk to the devs.

Where do we start? Can we make a list of projects where it just works and see whether we can extract some features from it?

This is about communication, not decision making. Yes. Far too many projects are in one of these 2 extreme points:

  • I guess I’ll do it this way. I hope they like it.
  • The phone is ringing again! How am I ever supposed to do anything if I spend all my time talking to people on the phone!

There a probably lots of ways to give developers some sort of clue about what people would like, without (a) overwhelming them with more requests than are humanly possible even listen to, much less do anything about – many of them duplicates; or (b) filtering out too many requests, giving developers a badly biased or otherwise incorrect understanding of what people want.

a bug-tracking system. It felt very cold and unpleasant. Yes, but occasionally you see small amounts of humor in a bug-tracking system.


CategoryDiscussion CategoryDecisionMaking CategoryTransparency

Define external redirect: DanaDahlstrom SocialSolution RatingBudget

EditNearLinks: WardsWiki OpenSource UseMod CamelCase SilentMajority TechnologySolutions WebOfTrust

Languages: