Wikiversity:Delegable proxy

Please discuss this proposal on the attached Talk page.

What is Delegable Proxy?

Delegable Proxy, as proposed here, is a method for assessing participation in some discussion or process, to better estimate how the process represents a larger community than those who are able to directly participate. More deeply, delegable proxy creates an explicit network of users that, it is expected, may more rapidly negotiate consensus, with information flowing both up and down the proxy hierarchy, while keeping discussions relatively small.

How does it work?

Delegable Proxy works with two lists: a list of "members" of a community or process, and a list of assigned proxies. While some delegable proxy systems propose multiple proxies, it greatly complicates analysis and reduces accountability. The suggestion is that the user ("the client") name the other user ("the proxy") whom the user considers most likely to participate constructively in his or her absence. It is not necessary that the user and proxy agree on everything, and the proxy will not be "voting for" the "client," the one who named the proxy. Rather, this is simply used to estimate consensus better than without a system like this.

If a client's proxy is absent, but the proxy's proxy is present, then all are considered "present" in the expansion. That is, "present" directly or present indirectly. This representational chain isn't limited.

This proposal suggests that users name only one proxy. Proxies should generally be accepted to be considered effective, and naming a proxy should be considered permission for the proxy to directly communicate with the client. Accepting the proxy is giving permission for communication in the other direction. Thus delegable proxy sets up an explicit network. Communities already do this informally, but documenting it brings a number of benefits.

Anyone who wants to understand better how well a discussion represents the whole community of members, may use the member list and proxy table to "expand" participation. That is, they may find that so many users participated directly, but if we consider indirect participation, many more are "connected" with the process, through people they have trusted.

This is not "proxy voting." In processes where the goal is consensus, delegable proxy can provide a means of estimating broad consensus without requiring broad direct participation. Ideally, the goal remains 100% consensus. Delegable proxy provides a means of measuring how close we have come to that goal, and how likely a particular outcome might be to being confirmed if it should be discussed more widely. It is a tool for increasing efficiency without restricting participation. --Abd 18:21, 11 September 2011 (UTC)

Does it change the way we make decisions?

Not unless we decide to set up some system that does this. That is not being proposed at this time. However, a Wikiversity:Assembly is being proposed, to begin as an informal body, with open membership. Everyone who registers as a member of the Assembly is a member of the Assembly, by default. The Assembly, however, will follow more traditional rules for deliberative bodies and may decide upon its own rules. If there is serious disagreement, it is possible to have more than one Assembly. There is nothing wrong with this, because the Assembly is only an advisory body. If it can't settle on some piece of advice, it can present multiple reports, perhaps with delegable proxy expansion of the approvals on those reports. That can be done with multiple Assemblies, if needed.

So then who decides? It's the same as now. Those with the power to act decide, and they are responsible for what they decide. This could be an administrator deciding whether to block or unblock a user, it could be a policy decision of some kind, and if there is revert warring over a policy, an administrator may temporarily protect the policy page, but then there may need to be an edit under protection. An administrator may want advice from the community. The intepretation of that advice remains the responsibility of the administrator.

Further, sometimes we actually !vote, or what we do is close to voting. An example is decisions on promotion of probationary custodians to full custodians. Users decide on their own comments, and may wish advice before doing this. The delegable proxy network may assist users in finding consensus informally, in sharing information about possibilities and history. The Assembly is designed for deliberative process, which includes the collection and documentation of evidence, as well as analysis of it.

How does the Assembly make decisions?

The Assembly only decides, as such, on its own process. It's recommended that it value consensus, but use majority vote for preliminary decisions, where efficiency of decision is important. It may decide to elect a chairperson to handle such immediate decisions. Where possible, decisions should remain open, should circumstances and arguments develop further, and standard deliberative process allows for this. The Assembly makes its own rules. The possibility of multiple Assemblies keeps the Assembly honest. If the Assembly is run fairly, there is no reason to split up.

As to everything else, the Assembly makes reports, with recommendations. These reports are not binding, as such. However, if the reports show true consensus, simply disregarding them would probably be unwise. The Assembly, if it is operating with delegable proxy, has a means to directly reach every member, to recommend direct action through the network, and proxy expansion will, experience may show, allow reasonably accurate prediction of the outcome if direct action is necessary.

The Assembly is only described here as an application for Delegable proxy. Part of this initial project will create an Assembly, but the Assembly will make its own rules. If these are compatible with general Wikiversity process, then Assembly process may be on-wiki. If not, the Assembly may choose to move all or part of its process off-wiki. This, however, may limit its effectiveness. If it is open, then the on-wiki proxy designations may still be used to better understand Assembly process and decisions.

Network? Is this off-wiki?

Most Assembly functions may be on-wiki, but proxy-client relationships are personal, and not limited to on-wiki communication. If a proxy has many clients, the proxy may wish to set up a mailing list for his or her clients. Remember, the Assembly is not a decision-making body. The goal of the Assembly is to negotiate or discover consensus efficiently. That will happen if the communication is distributed into small conversations between people who communicate well with each other, and is then reassembled and negotiated by a few proxies representing as many members as possibly, and possibly discussion may go back and forth through a few cycles of this. That's with difficult choices.

If an Assembly decides to restrict participation in some way, it may decide to "meet" off-wiki, though any mechanism it chooses. Off-wiki assembly meetings, though, should be open and visible to all Assembly members, as shown by on-wiki sign-up. Individual proxy-client communications may be private.

It may seem complicated. It won't be. This is a trial of the concept, however, and participation is completely voluntary.

How do I participate?

To enroll as a member of the Assembly, add your user name to the Wikiversity:Delegable proxy/Table. This does not obligate you to participate, but it will, initially, consent to receiving notices on your user talk page. We may add flags that would disallow notices for those who have named a proxy. If you are not willing to receive notices, and not willing to name a proxy either, then please don't sign up. You will still have ways in which you may participate, I'd assume. It will be up to the Assembly to set actual rules, what is in place now is really just an ad-hoc proposal. (With over twenty years of thinking and writing and wide discussion behind it.)

To name a proxy, add the proxy's username (as a link to the user page, displaying the name) to the Table. You may want to notify the person you name, so they know to consider accepting. Be sure to be logged in! To accept, be logged in and add a timestamp as shown.

There are other ways to handle proxy tables, this is a fairly simple one, and the simplicity means it is completely open and verifiable.

The questions

What about socks?

When delegable proxy was suggested on Wikipedia, and the first proxy assignment was made, the users were immediately checkusered, even though no usage had been proposed at all, it was just an experiment, labelled as such. Checkuser, of course, came up negative, and the two users had long independent histories, quite unrelated until they met and cooperated on this. The last thing a puppet master wants to do is to explicitly connect the accounts! Remember, this system isn't being used to make decisions, just recommendations or estimations of consensus. A few sock puppets will likely have no effect at all, particularly since the goal is consensus. Further, those who use the process could decide to analyze the data in other ways, they could consider, for example, age of accounts and number of edits. If a pile of new accounts has a radically different perspective than more established accounts, they might merit some attention. This is unlikely to be a real problem. It's just what some think of first.

What about proxy loops?

Sometimes people notice that proxy assignments can form loops. The smallest loop would be that A names B and B names A. If A or B always participate, there is no problem with a loop. If they don't, it's easy to notice that and suggest that one or both of them name someone who is more likely to participate. While full participation, directly or indirectly, is obviously desirable in some way, it's not necessary. If I name a proxy and my proxy never participates, however, I'd certainly consider naming someone else! And so should my proxy!

How are proxy expansions accomplished?

People have developed software for this, but it's easy, for relatively small proxy tables, to do it with a spreadsheet. What's needed is the member list, the proxy table, and a list of participants, with positions (if that's relevant). Software solutions have often been proposed, including secret ballot voting, but this always, then, devolves to trusting whoever runs the software. Open proxy tables may be analyzed by software, if we need that, but the results can be verified by anyone.

There is a secret ballot method, Asset voting, that can result in close to 100% representation in an elected Assembly, with little fuss. It can be considered as a first layer of secret proxy assignments in a Delegable Proxy system.

May I invite someone to name me as a proxy?

You may, but be careful. It could be tacky. At this point, if you are interested in helping get this off the ground, name a proxy and invite the person to accept it, and, as well, invite them to name a proxy, not specifying yourself. We may establish a category for users who wish to make themselves available as proxies, and that would be a more neutral way to offer your service. Being a proxy is a service, it's a job, though one where you may adjust your level of commitment, and you can "pass it on" by naming a proxy yourself. Accepting a proxy is giving consent to direct communication.

Imagine a large DP system. You have accepted a thousand proxies. Do you really want to engage in direct communication with a thousand people? Good luck! If it works, fine! In discussions of Delegable Proxy elsewhere, it's been proposed to limit the number of proxies a person may accept. An argument against that is that the practicality of accepting many proxies varies with the nature of the communications traffic it will create, and that any restriction would be artificial, not necessarily matching the needs and capabilities of each person. In a delegable proxy system, the real goal is a communications network, so each "node" in that network may be allowed to adjust the traffic they receive. If you are a proxy and become overwhelmed, suggest to some of your clients that they name someone else, such as someone else who has named you. Spread it out.

The big safeguard in the system proposed here is that proxies don't transfer real power. They are only used to weigh advice and assess the representativeness of participation. Actual decisions are made elsewhere (but perhaps by the same people!). So if someone solicits every new user and somehow gets them to name him or her, but no actual "influence" and "trust" are established, and similarly if someone creates a thousand sock puppets (bold!), not only will this be visible, but it will be useless. Nobody who matters will be fooled. (But Wikiversity may, if the community chooses, establish rules about canvassing for proxies, as with any other kind of canvassing. If any user sees problematic canvassing, they may protest and custodians may act.)

The conditions militating against accepting many direct proxies do not apply to indirect proxies. That, indeed, is the whole point of delegable proxy vs direct-only proxy. It's indefinitely scalable. We might be lucky to see a few dozen editors on Wikiversity participate in this, but the system could handle, in fact, the entire population of the Earth. At least it seems that way! Obviously, nobody has tried. As a proxy, you control your traffic by controlling how many proxies you accept, and whom you accept. If someone gives you more traffic than you want, you can suggest that, if they trust you (and you don't want a proxy from someone who doesn't trust you, it will be a pain in the neck), they could name So-and-So, or could pick any one of your clients, the one with whom they have the best rapport, and who is willing to accept. Or anyone else.

How to invite participation in this system

You may transclude an invitation page on a user talk page, you could use
{{subst:Wikiversity:Delegable proxy/Invitation}}
Please do not do this massively unless the community has approved. Unless you know the user, please don't invite newcomers on registration or the first few edits. The template includes a section header, so if you use "add topic" don't give it a new topic name, accept the edit without one.