Wikipedia talk:Delegable proxy/Table

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Ron Duvall (talk | contribs) at 02:59, 20 February 2008 (copied over). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Notice

A notice has been placed on the page, "Proxies listed below are not currently recognized, as Wikipedia:Delegable proxy is neither a policy nor a guideline." Given that the proxy system would not necessarily bind admins to a certain decision, but could simply provide them with more information (see Wikipedia talk:Delegable proxy/Abd's message), I am amending that notice. One definition of "recognize" is to "be fully aware or cognizant of." In certain discussions, an admin might find it helpful to notice that a participant is a proxy trusted by many established users (which could be suggested by those users being proxies themselves). Sarsaparilla (talk) 19:20, 10 February 2008 (UTC)[reply]

The notice should also let users know that their nomination of a proxy is giving that proxy consent to communicate directly with them, and that acceptance of a proxy is consent to communicate in the other direction. (I would not personally accept a proxy from a user who did not give me, at least, a direct email address, and I definitely would not give a proxy to any user who didn't give me a way to contact the user directly -- i.e., by email or phone.) This is, in fact, a restraint on mass acceptance of proxies from real users. No restraint on accepting sock puppets, which is fine. If a user knowingly accepts proxies from sock puppets, there would be no specific reaction, except we'd now have a prime suspect for puppet master. It would certainly make SSP and Checkuser easier to file! -- and harmless to the innocent. This aspect of direct communication can make high-depth proxy networks very rapid response. On the other hand, nobody should be obligated to follow my personal practice. The relationship of proxy and client is direct, voluntary, and uncoerced. (If it's coerced, we'd want to know about it!) --Abd (talk) 22:40, 17 February 2008 (UTC)[reply]
I respect your personal preference, but do we really want to stress the aspect of off-wiki communication? The fact that emails/phone conversations are hidden from public scrutiny and generally inadmissible as evidence in Wikipedia proceedings could make some leery about the motivations for it. Wasn't a perceived failure to be "open and transparent to all editors at all times" one of the reasons cited for shutting down Wikipedia:Esperanza? Ron Duvall (talk) 22:49, 17 February 2008 (UTC)[reply]
Well, it's not necessary. I'd say that consent to communicate is sufficiently implied, and there is no need to underscore off-wiki communication, it is probably not necessary. Any user or proxy who wants that to be available can make it happen; but for me, the point is that this is an actual and small-scale connection. Jimbo Wales as my proxy isn't going to work, unless he's got the time, which I doubt. If I wanted to name him, he could have a system set up where he recommends some client in his proxy hierarchy, someone he trusts sufficiently for that, and someone who has time to respond to my ranting and raving. Or not, as the case may be. TANSTAAFL. —Preceding unsigned comment added by Abd (talkcontribs) 00:47, 18 February 2008 (UTC)[reply]

Time for more specifics!

Abd, can you please provide some more specifics about what exactly you want this proxy table to include? Ron Duvall (talk) 02:28, 17 February 2008 (UTC)[reply]

User, timestamp, Proxy username, Acceptance (Yes or No), timestamp, Notes
Anything else can be handled with suppementary tables, or is information obtainable from other sources.
The format should be such as to allow anyone to take the proxy table and import it into a spreadsheet for analysis, with the fields being properly distinguished.
I have suggested that the User be the first field to make it a little easier for Users, maybe. But the first field could also be the Proxy name. We don't have enough history of use to have much of an opinion as to which is best, and it may not matter.
It should be one record per user, and be maintained in order as added (So that a new user may add a nomination to the bottom, with no fuss, and the list is maintained in that same order. But it could also be argued that new nominations should be at the top, might be a little easier. Users may cancel a proxy by deleting the record or by adding a later record at the bottom (in which case anyone else may, following this, delete the original record, I'd suggest.
Editing of a user record by anyone other than the user, to change the critical information, should be considered offensive, except, of course, that a proxy may add or revoke acceptance. This would not apply to editors merely formatting the record to conform to a uniform standard (to make it easy to analyze with automated or semi-automated tools).
Notes should not be added or edited except by consensus or in expectation of that, but a user or proxy may add, edit, or delete notes. It's possible that the Notes field can become a series of fields as need arises. For example, SSP in that field could be used to flag a presumptive sock puppet user, but, note, this kind of thing complicates it and creates opening for contention. Nothing reasonably contentious should be in the page, so, if the community -- elsewhere -- concludes, directly or through servants, that a user is a sock puppet, the appropriate remedy would be to delete the record, not to annotate it.
At the head of the table would be instructions for use of the table, and a note that naming a proxy gives consent to the proxy to communicate with the client, (by email or wikiTalk) and that accepting a proxy likewise gives the client consent to communicate with the proxy, and that nomination or acceptance may be revoked at any time, and with it, consent to so communicate.
Okay?
--Abd (talk) 16:11, 17 February 2008 (UTC)[reply]

Ah, I see. How does this look? Wikipedia:Delegable proxy/Table Ron Duvall (talk) 16:51, 17 February 2008 (UTC)[reply]

The format you're suggesting will make it harder to verify entries in the table by hand than it should be. Each table should include the links one would need to verify. What I think would be necessary would be (1) a link to the user's contributions and user creation log, (2) a link to the diff in which the user chose their proxy by adding the table row, (3) a link to the diff in which the proxy accepted. Also, in the interests of making it easy to examine the history of the proxy table, each row should be a transclusion of a user-space page on which a user keeps track of their proxy choice, such as User:Abd/Proxy. This has the added advantage that users cannot add multiple different proxies to the table at all (as opposed to that being an abuse that can be detected and reversed). Mangojuicetalk 20:11, 17 February 2008 (UTC)[reply]
I certainly want to keep it simple. The basic information I proposed should be there. I'm not sure that the links are required, but, no problem. Note that a proxy accepting could add the nomination diff, then the user noticing the acceptance could add the acceptance diff. That would be pretty efficient. Or anyone else could add those diffs. What I expect, though, is that there won't be a great deal of need for diff verification. Misrepresenting a proxy would be a blatantly disruptive act, my interpretation is that it would be grounds for a block (with the usual caveats). --Abd (talk) 21:41, 17 February 2008 (UTC)[reply]
So basically it will take three edits to add each entry to the table – one to add yourself, another for your proxy to accept, and another to put the diffs? If we have it on central page, a bot can go through daily and add all the diffs in one edit. If we have it on transcluded userspace pages, the three-edit-per-entry process would still be required (even if it were done by bot, the bot would have to make separate edits to each page). The other downside of transclusion is that if we make certain changes to the table, all those user namespace pages would have to change. I guess the userspace pages could use a template, so that adding extra fields would not cause issues; deleting or renaming fields might though. OK, let's go ahead with transclusion, although with the increased complexity of making changes in mind, we should take extra care to try to get this in a good form before we begin the experiment. Ron Duvall (talk) 20:33, 17 February 2008 (UTC)[reply]
I'm somewhat reluctant to support a process that uses proxy nominations on user pages. In fact, the more I think about it, I'm opposed. If there is a proxy table (main or special), anyone can quickly look at it to identify a proxy assignment. Users can, if they want to, put up userboxes that say "I support Delegable Proxy on Wikipedia" or the link," and a reasonably presumption might be that they would name a proxy.... though maybe not, and "I am available to serve as a proxy" would also be okay, and convenient. It might have a link to the main proxy table instructions. Simple. Simple. Simple. Did I say "Simple"? --Abd (talk) 21:41, 17 February 2008 (UTC)[reply]
You may be misunderstanding what is meant by Wikipedia:Transclusion. Each row on the table is a transclusion of a user subpage, which itself uses a transcluded template to format the data. Actually, the transclusion could have some benefits. If everyone has the info on their own userpage, it decentralizes the system, making it harder to disrupt with a single attack. Remember that liquid democracy was originally designed for "small, stealthy, distributed teams of anarchist kung-fu badasses." We can have a bot periodically take a look at "What links here" and add rows transcluding newly-created user proxy subpages to the proxy table, similarly to what RFC bot does with RfC. People will still be able to change or revoke their proxy instantly if needed by editing their own user subpage. If vandalism to the proxy table and/or the template becomes a severe problem, we can protect those pages for awhile, without harming people's ability to change/revoke their proxy. All in all, an excellent idea in many ways. And actually, it's probably inevitable that we use transclusion because if there are a lot of people editing the table directly, they are going to run into edit conflicts; and the page history for that central list is going to become extremely long and hard to work with. However, I will admit that it is slightly more complex than not transcluding. Ron Duvall (talk) 21:58, 17 February 2008 (UTC)[reply]

(unindent). All right, already. As long as anyone can download the full table easily, I'm happy. Right now, though, what I get from copying it or downloading it does not have field separators. Maybe I don't know how to do it right, but, ... if I don't know, neither will many users. It should be really, really easy. With the original applications, the table is just a text file, with comma separators between fields. I like that a user names a proxy with a user subpage, that makes it readily accessible for the user. It's also, as you note, distributed, making it much more difficult to vandalize. (I.e., there can be copies of a central table placed just about anywhere, ready to go. If I've got it right.) But if transcluding makes it significantly harder to use and maintain ... no. Okay, take a look at this. How does it look? Any suggestions?

I don't see any reason, at least not yet, for automatic expirations. A notice that at some future time, unaccepted proxies might be removed, would be enough. I'd suggest that if there is a removal, though, the user should be notified. Otherwise it is a pending proxy, the user should not have to do anything about it, nor should anyone else. (Conditions where someone other than the proxy might contact the user should probably be spelled out; an unaccepted proxy, sitting for a certain period, might be one of those.) You forgot to sign: Abd
Yes, transclusion solves that problem for us. Pending acceptance, proxies can simply be left on the user subpage; after they are accepted, then a line can be added to the table transcluding that subpage. Using templates and transclusion will allow us to do all kinds of other cool things too, like automatically group proxies into categories based on certain criteria using if statements. Ron Duvall (talk) 23:05, 17 February 2008 (UTC)[reply]
Editing this table format might be forbidding for newbies. However, I think that this can be made fairly easy with good instructions. There should possibly be field separators that will be included in someone just copying the table from a browser display of it (or saving the page locally. (As it is, I think I'd have to edit the page and copy the raw text, then massage it extensively to take it into a spreadsheet (and with transclusion, I think this would not work). This should be, if possible, a simple copy and paste, or copy and paste into a text file that is then loaded with, say, Excel.) You forgot to sign: Abd
I agree, it is presently in a very raw form that I would not expect a newbie to be able to use. Ron Duvall (talk) 23:05, 17 February 2008 (UTC)[reply]

Ron Duvall (talk) 21:25, 17 February 2008 (UTC)[reply]

Copying it into a spreadsheet

I was able to highlight the whole table and copy and paste it into a spreadsheet (OpenOffice). I'm not talking about copying and pasting the table's wiki markup which you see by clicking "edit this page," but the actual table. Was that what you tried, Abd? By "field separators," do you mean delimiters such as commas? After you copy and paste the table into a spreadsheet, you can then export to CSV or whatever other format you want; but what you have already on the screen at that point is the table with all its rows, columns, etc. as they should be. Ron Duvall (talk) 23:21, 17 February 2008 (UTC)[reply]

Bots

Here's what I see happening, if we were to automate it:

  1. User goes to a page which gives him the option to enter the name of a proxy or no proxy at all. (That would be treated as a revocation.) User enters name of proxy.
  2. A userspace subpage, e.g. User:Abd/Proxy, is generated with two template fields: User=Abd; Proxy=Jimbo Wales.
  3. The proxy accepts by adding to User:Abd/Proxy the following field: Acceptance=Yes.
  4. Our DiffBot™, using "What links here" from the Template, finds the newly accepted proxy and adds four more fields: UserDate=____ __, ____ __:__ __M, AcceptanceDate=____ __, ____ __:__M, UserDiff=http://en.wikipedia.org/w/index.php?title=... and AcceptanceDiff=http://en.wikipedia.org/w/index.php?title=...
  5. A bot then adds the line, e.g. User:Abd/Proxy, to the table.

Procedures would also exist for handling revocations, detecting unauthorized changes, etc. but you get the gist. I'm not sure if #1 is possible but I've been trying to figure out if we can automate at least some of the field fill-ins using something like {{CURRENTUSER}}. If we can get the CURRENTUSER thing to work, then the documentation should be able to give users some text that they can copy, and then click on a link which will start the new page User:Abd/Proxy, and then they can just paste it in and hit "Save page" with no other editing needed except for Proxy=Jimbo Wales. (See, for instance, Help:Magic words, Help:Variable, and http://www.mediawiki.org/wiki/Extension_talk:Variables ). The other cool thing about transcluded pages, by the way, is that everyone can watchlist their own proxy page, so it's easily verifiable by every user that at least their own entry is OK. The proxy can also watch it, and easily see if the user changes anything in the notes, for instances, or makes a comment on the proxy talk page.

I think substitution may be very useful in helping people easily appoint a proxy. Ron Duvall (talk) 00:04, 18 February 2008 (UTC)[reply]

Subst, cont'd

OK, so we're getting closer to having a fast, easy method of adding proxies to your userspace in a way that any newbie can figure out. We should be able to add the diff in the same edit as the template is added. I'm having trouble automating the diff, though, because of a REVISIONID issue. See Wikipedia:Village_pump_(technical)#Using_subst_with_REVISIONID. Of course, creating a fast, easy method of proxy acceptance that doesn't require bot intervention is a whole separate project. But presumably most proxies will be relatively sophisticated users. Nonetheless, I want to make this easy for everyone.

As the table instructions note, all you have to do right now to add your proxy is go to your user subpage, e.g. User:Abd/Proxy, enter this line, and Save page:

{{subst:Wikipedia:Delegable proxy/Table/Designate|''Insert your proxy's name here''}}

Then this line will need to be added to the proxy table:

{{User:Abd/Proxy}}

At that point, you're good to go. It should add the diff for you and everything. The only problem here is that REVISIONID issue above, which is causing the diff to not work properly. Ron Duvall (talk) 05:27, 18 February 2008 (UTC)[reply]

Let's see how many ways I can do it wrong.

I added Abd/Proxy, and I think I followed instructions.

I put the new line before the closing code. I hope that's correct! A newbie might put it at the end, at the top, or just about anywhere unless it is crystal clear.

It's not working right, as you can see in the table. --Abd (talk) 04:21, 19 February 2008 (UTC)[reply]

Yeah, it didn't like the italics. I fixed it. By the way, should there be a link to the actual proxy page (e.g. User:Abd/Proxy) or just a link to the user page, as it is now? Ron Duvall (talk) 05:50, 19 February 2008 (UTC)[reply]

Copied over from Abd's talk page

(snip)

I'm not convinced that the proxy table, as it is, is simple enough. We should play with it a bit. The timestamps aren't right, they actually should show date and time, not a time code. And the diffs don't work.

I'll look at the project page and see what I can do to make it more general. I already did some of this yesterday. I do sense that the first applications to have any effect would be with Article proxies and associated special proxy tables, not necessarily the general proxies that are on the Proxy table page. Article proxies are create formal networks that connect a larger interested community, not necessarily currently active, with the smaller group that may be active on an article at one time. As shown in the little drama above, article proxies don't create special opportunities for meat puppets; indeed attempts to call in one's clients to out-revert an opposing caucus could backfire. However, bringing in more eyes is always helpful. But I certainly don't know the specifics about how it will play out. The reason why I think article proxies might be more important in the short term is that it only takes a small group of editors to make it work.

The diffs don't work because of the REVISIONID issue noted here. The timestamps right now are formatted with the units going in descending order from years to seconds. E.g., 20080219041435 is 2008-02-19 04:14:35. That's a useful format if you want to mathematically compare two timestamps for recency, but not very pleasing to the human eye. We can change it to some other format, or have it appear in some other format, with the assistance of m:Help:ParserFunctions or perhaps Help:Variables. I'll probably get on that a bit later... What format exactly should we use... Ron Duvall (talk) 02:59, 20 February 2008 (UTC)[reply]