PourPeuEtBeaucoup

Cette page a démarré sur ForFewAndMany

Ceci est une description du LogicielRelationnel faite pour fonctionner pour deux parties :

L’interaction entre les peu et les beaucoup est difficile.

En général, c’est simplement un bazar.

Ceci traite de quelque logiciel qui pourrait fonctionner pour les peu et les beaucoup afin de communiquer plus efficacement les uns avec les autres.

Disons : Les milliers et milliers d’utilisateurs de GNOME, en respect avec le nombre limité (des dizaines) de développeurs GNOME.

La chose basique est que vous voulez que les beaucoup puissent assembler et prioritiser les problèmes des gens. Et puis vous voulez que les peu puissent régler ces problèmes, ou au moins les plus importants d’entre eux, et puissent fournir une réponse formelle.

Les peu peuvent dire ensuite à un râleur : “Ne me parle pas de ça par email. Participe simplement à la collecte des problèmes”.

Comment fonctionnerait une telle chose ?

CollecteProblèmes

Peut-être quelque chose qui soit un peu comme ça :

Chaque utilisateur peut s’enregistrer un compte. Il y a une obligation que les comptes soient liés à de vrais personnes, et une sorte de forme de LiaisonInternet ou WebDeConfiance? peut être utilisée pour s’assurer que les comptes sont honnêtes.

Autres idées :

Voir aussi


PageTranslation LangueFrançaise ForFewAndMany DossierLogicielSocial

Discussion

Bayle, tu as écrit quelque chose sur les personnes divisant les points dans un WebDeConfiance?. Quelque sorte de schéma d’allocation - c’est ce qui m’a amené à l’idée des dix points problème. Te souviens-tu du nom ? Ce n’est pas dans le DossierSystèmeNotation, je ne pense pas.

Je comprends que cette procédure aidera à afficher les principales thématiques à travailler. Je ne comprends pas comment cela pourrait aider à partager efficacement les sujets déjà travaillés. Cela me semble une question de politique efficace de tag.

Une autre idée : en vous enregistrant vous obtenez gratuitement quelques points problème. Vous pouvez acheter autant de poits problèmes que vous voulez pour de l’argent. Si un problème est résolu, la quantité de points problèmes amassés sur ce problème va à l’éditeur(s) de cette thématique. Vous pouvez dépensez vos points problèmes gagnés pour classer d’autres problèmes ou les transférer en argent.

Yow ! Je n’avais pas pensé à ça ! C’est une idée géniale et se lie avec ces programmes de générosité OpenSource. J’avais négligé de penser à un marché comme un système de communication entre les peu et les beaucoup.

Je me préoccupe néanmoins des points problèmes “gratuits”, s’ils peuvent être vendus, ce sont un stimuli pour essayer et tricher avec le système d’authentification.

Aussi : Il n’est pas clair si une personne perd tous ses points problèmes, quand quelqu’un résoudra son problème. Si c’est le cas, alors elle n’a plus de voix. L’objectif initial ici est de permettre aux gens d’exprimer leurs voix.

Mais je pense vraiment qu’un système mixé serait bien ici.

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?

Define external redirect: DanaDahlstrom SocialSolution RatingBudget WebDeConfiance

EditNearLinks: UseMod WardsWiki OpenSource TechnologySolutions SilentMajority CamelCase

Languages: