Wikipedia talk:Delegable proxy/Table

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)

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)

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)

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 (talk • contribs) 00:47, 18 February 2008 (UTC)

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)

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)

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

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). Mangojuice^talk 20:11, 17 February 2008 (UTC)

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)

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)

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)

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)

(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?

• Wikipedia:Delegable proxy/Table

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)

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)

• Wikipedia:Delegable proxy/Table/Row
• User:Ron Duvall/Proxy

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

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)

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.wiki.x.io/w/index.php?title=... and AcceptanceDiff=http://en.wiki.x.io/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)

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)

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)

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)

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)

How do I accept a proxy?

Looks to me like I need to edit the proxy file for the user naming me to accept a proxy. That's actually good, because users will see edits to this file, which they created or edited, by default. Again, the edit should be really simple. It could be like the initial proxy assignment, i.e., the date is automatically added. The diffs would be nice, but I'm not sure they are necessary. What might substitute for filling in those diffs is a link to the revision history of the user proxy file.

Having to add timestamps manually? No. Not good. --Abd (talk) 03:39, 20 February 2008 (UTC)

OK, I've set it so that you can use the {{Wikipedia talk:Delegable proxy/Table/Accept}} template. Try it out. The timestamp is automated, but of course not the diff yet. The diff is preferable if we can figure out a workaround to that REVISIONID issue (there might be another way to do it) but if not, we can just link to the revision history. Ron Duvall (talk) 04:05, 20 February 2008 (UTC)

Revision history should be adequate for now. Latest revisions should show the necessary editor identify confirmation, date, etc. I'll try the accept template. I think the instructions should be a little more explicit.... --Abd (talk) 04:03, 21 February 2008 (UTC)

Cool! How did you get those instructions to be there, then disappear? (If that is standard, then the Acceptance instructions on the Table page don't need to give the instructions as to what to insert ... or is that the source?)--Abd (talk) 04:14, 21 February 2008 (UTC)

See Help:Template, m:ParserFunctions and Help:Magic words. I used #if statements to make the instructions only show up when the acceptance field is blank and when you are in the User namespace. There is all kinds of cool stuff that can be done with templates. The next step is to have a two- or three-click designation process. You go to the proxy designation page, enter your user name and proxy's name into a pair of inputboxes, and click a button; it creates/edits the appropriate page (e.g. User:Abd/Proxy, using a preload to populate it with the appropriate text (i.e. the subst for the Designate template); and you click Save.

Acceptance can be a two-click process. If the proxy has not yet been accepted, then the proxy page will present a very simple interface allowing your proxy to click a button to accept. When he hits that button, it will edit the page, using a preload to automatically add {{subst:Wikipedia:Delegable proxy/Table/Accept}} in the appropriate place. Then he just clicks save, and he's done.

If there is a magic word available such as the exemplary {{{CURRENTUSER}}} mentioned at mw:Extension:Variables, or another way by which we can get such functionality, then the designation page can be set up to detect the user's name and thus not need to ask the user for it. Moreover, we will be able to set up the template that transcludes to the user's own proxy page so that the only user it will present the Accept button to is the proxy. This will help prevent confusion and inadvertent acceptance of other people's proxies.

There should also be a revocation button which either user can use to fill in some "revoked" fields (e.g. RevokedBy, RevokedDate, RevokeDiff, etc.) so that we will have that data easily accessible. When a proxy is revoked or not yet accepted, or other necessary data is missing, the transcluded Row template should automatically appear blank when it's transcluded to the table, so that problems with individual proxies do not mess up the whole table. Also, this will eliminate the need for users to keep adding/removing rows from the table. You should only need to change that table once during your time here under any particular username; after that, you just make changes to your individual proxy subpage. The more we can down on edits to that table page, the better.

We might also automate the process of notifying the proxy that someone has designated him by adding a button that the user can press to insert a section in that proxy's User Talk page, which could be preloaded with a sample message of explanation including the proxy page name. Then he could just click on that, which would take him to the proxy page, which if the aforementioned interface is included, would allow him to click two buttons and be done accepting.

If we make it really easy for people to understand and use, that can help avoid snafus that have to be manually fixed, and help get more people onboard, I think. Ron Duvall (talk) 18:10, 21 February 2008 (UTC)

More technical details

I'm trying to think of the best way to do this. Without having to copy and paste into a spreadsheet and manipulate it that way, we want to enable having separate tables listing (1) all proxies; (2) proxies that have not been accepted; (3) proxies that have been accepted; and (4) proxies that have been revoked. I suppose the way to do it is to set up separate pages for each, and have the Row template either make the row visible or not depending on what page it's being transcluded to. That sounds like a pretty scalable solution.

Each userpage shows up in the list somewhat like this:

{{User:Abd/Proxy}}

We can pass parameters through to the userpage template, e.g.:

{{User:Abd/Proxy|showrevoked=true}}

However, is it possible to possible to pass parameters through the user subpage and into the underlying row template, without having to include it in the raw text of the user subpage? I want to make that user subpage only have essential fields and their values; code should only be in underlying templates. That way, changes can be made to how this thing works without having to make changes to all those user subpages. Ron Duvall (talk) 19:00, 21 February 2008 (UTC)

Whatever it is, it should be as simple as possible to use and maintain, and any necessary maintenance (with some exceptions) should be performable by anyone. I don't see any need to remove users from the Proxy Table. It should display gracefully if the Proxy table is missing or the name of the proxy is removed. Because we want the old acceptance to go away if the user changes the proxy name or removes it, the standard procedure might be that the proxy page is replaced with a new one, with the template appearing the same as if no proxy had appeared before. Separate tables that look at the state of user proxy pages and summarize results could be useful, but they aren't essential. For example, there could be an "unassigned proxy" page -- a user has a proxy page but no proxy named in it (perhaps it was revoked). Then there could be an "unaccepted proxy" page.

I don't want to see unaccepted proxy assignments removed. They indicate an intention. (nominated proxies should also have a simple procedure to deny a proxy (which, to be polite, when possible, should be accompanied by some comment... but that shouldn't be necessary.

In fact, a user should be able to create a Noproxy page that automatically refuses proxy assignments, and that might return a comment advising those who wish to name the user as a proxy what to do. "I'm not accepting any more proxies, but please see (pagename) for a list of my clients who are accepting proxies. Thanks for your trust in me. If you wish to contact me directly, you may do so through my Talk page, as usual, but, due to the volume of such messages, if you think my specific attention should be drawn to something, you may contact any of the proxies on the list referenced above that say, in the list, that they are open to public contact; explain your message to him or her and he or she will decide whether or not to pass it along to me, and respond to you accordingly."

(It might be noticed that this is scalable to any size; it may provide a contact path to anyone who has accepted proxies; with this, the clients, those who are willing, serve as filters for the proxy, enabling the proxy to received filtered communication from a huge population. The proxy-client relationship is a bidirectional filter.)

That message is, of course, too wordy for something to actually use; rather, there would be a pointer to a page with the information....

But this is getting ahead of what we need. Checking for a Noproxy page certainly is not needed now. If, however, proxy notification could be implemented in a simple way (i.e., comment added to proxy Talk), that would be great. Probably what is suggested above (edit opens for proxy Talk, with preset default message, edit summary, and sig in place, so user just clicks on Save Page to notify the proxy. Likewise, acceptance or rejection could similarly involve Talk notification of nominating client.

Conceptually, the essential element is the user proxy page. The rest is configurable, and there can be more than one table pulling up proxy page data in various ways. It shouldn't matter who puts the user in the Table, it could be the client, or the proxy, or someone else assisting. Indeed, anyone could create the user proxy page as well, though this could play havoc with automated verification and we might wish to discourage it (presumably, the person helping would put a diff to the place where the user permission is given). (This is a possibility probably best avoided on Wikipedia. But I can see it with organizations where some users may be thoroughly technically challenged, and yet allowing them representation may be considered desirable -- and where some independent means of validating member identity exists).

This work will be valuable wherever delegable proxy is proposed for organizations using MediaWiki. And the trial here will be valuable elsewhere whether or not it takes off here.--Abd (talk) 20:38, 21 February 2008 (UTC)

Right, I understand the desire to keep it simple (especially where simplicity makes it easier to understand and use), my main concern is that whatever we start with be flexible enough to accommodate changes in the future without a major hassle. I think we're mostly on the right track. Right now, the only things that is ending up on user pages are the template name and the field names and their values. Are the field names acceptable, or do you have recommendations? See Wikipedia:Delegable_proxy/Table/Row/doc#Fields. Ron Duvall (talk) 21:06, 21 February 2008 (UTC)

I think the fieldnames are fine, I just tested the notes field. --Abd (talk) 22:20, 21 February 2008 (UTC) One problem: the reference numbers that display with the diff could get long. Can they be suppressed so that all that is there is a link? or -- for now -- nothing? (I think the display is controlled by the user proxy page, so this might be a problem.) We should get it reasonably well set up, then solicit comment, before we have lots of proxy assignments based on pages that might then need to be edited to change the fields. Before they start breaking the door down and edit conflicts abound when trying to add a proxy .... proxy tables could be in sections to make for easy editing and reading, alpha by username? ... oh! where was I! I think I was dreaming.... --Abd (talk) 22:29, 21 February 2008 (UTC)

Yeah, I keep thinking there's gotta be a way to automatically get all the proxy rows in one place without people having to edit that page themselves. Like I say, a bot could run a "What links here" every hour and add anything that's missing from the table in one fell swoop. That's probably the best thing. Ron Duvall (talk) 23:26, 21 February 2008 (UTC)

I tested the effect of blanking my proxy file. The proxy assignment disappears from the table display, which is good behavior. I don't know what happens if we have a third proxy with the deleted one in the middle. Nothing, I'd guess, no display artifact from the empty reference file. --Abd (talk) 18:42, 22 February 2008 (UTC)

Technical limitations

It might not be possible to do the one-button proxy designation thing, due to technical limitations. I just finished reading Wikipedia:Inputbox in more detail, and the capabilities of that feature seem pretty restricted. However, this does mean I have less work ahead of me, because otherwise I was going to have to figure out how to implement that thing. (Unless they give me permission to implement some of my own coding, which I am willing to do.) Actually, it's probably going to be harder trying to figure out how to get the template system to do what we want, and to deal with the resultant snafus. Ron Duvall (talk) 02:38, 22 February 2008 (UTC)

Now, I put a copy of the Proxy Table at User:The Community/Proxy table. It does not display correctly. This should be looked at. The proxy table should work regardless of where it sits. --Abd (talk) 18:56, 22 February 2008 (UTC)

Well, I think the problem is that the proxy assignments (in each user space) contain file references that are interpreted differently depending on where the table sits.... might be kind of a mess.... i.e., the proxy file itself may need to know, as this is set up, where the table is, making the whole system vulnerable to a problem with that file, defeating the purpose of having proxy assignments in each user space. I don't have time to experiment with this now... maybe later.--Abd (talk) 21:23, 22 February 2008 (UTC)

We can tweak it so that it will work one way, for instance, on any page whose name ends with "Table" or "Proxy table," and another way on other pages. I believe what we're looking for is {{SUBPAGENAME}}. If they made "or" statements a little easier to work with, we might be able to do this, but I think they only work with #ifexpr. See m:Help:ParserFunctions#.23expr:. So, we will have to use nested #if statements. Problem with that is, it's basically going to require another sub-template(s), unless we're going to duplicate code. MediaWiki kinda sucks sometimes. Maybe I'll report it as a bug, but I hate to trouble them over such stuff; I'd rather do it myself, but will they let me, and if so, of whom do I ask permission? Again, though, I'm suspending work on this until we figure out whether we're switching to comma-delimited format. Ron Duvall (talk) 19:47, 23 February 2008 (UTC)

Comma-delimited would be pretty simple, easy to understand, and if the user Proxy file simply has what is to be displayed in the table, it doesn't have to be pretty. Just easy to use, and easy to copy to a spreadsheet. The wikitable is *nice* but then the user file gets complicated. There may still be some simple way to use a wikitable, I'll be checking that out. The proxy table should be movable to any location and still function. (Note that there can be proxy tables intended for special use. So: a special proxy table may have a transcluded user general proxy in it, from the user proxy file, or a special proxy assignment that exists only in that table. Issue proxies, this would implement some of the liquid democracy proposal. It can be a lot of work to be simple, but it's worth it.--Abd (talk) 20:16, 23 February 2008 (UTC)

So what should display for the proxy table, if it's comma, would be "UserName, ProxyName, Acceptance, Notes. (That order is important, and Notes can be expanded to individual fields if needed later. Notes could, for example, contain diffs. But I don't think proof is needed. Username should come from the Proxy table, not from the user Proxy file, which would contain just Proxy, Acceptance, Notes. the Username and Proxyname can be wikified, probably best for convenience. So what would be in the Table would be

[[User:UserName]], {{[[User:Username/Proxy}}

and then in the Proxy file:

[[User:ProxyName]], Acceptance, Notes

--Abd (talk) 20:16, 23 February 2008 (UTC)

Actual proxy table, not merely demonstration of possible one

The proxy table was edited to show an opinion that this was only a demonstration of what a proxy table might look like. Actually, in my view, it's a real proxy table. The proxies shown in it are real. As noted, they aren't binding in any way. There may be, however, many copies of the table, though there should be a central one where users do add the link to their proxy file. But given that the proxy designation is in the proxy file, not in the table, anyone can add a link, if it is done in good faith and without misrepresentation.

Currently, the table shows a proxy loop, the smallest possible. That is normal at this stage, i.e., to be expected. As more users decide to participate, other patterns will appear, and, I'm pretty sure, the particular loop that is shown will open up and change. Besides, if the pizza doesn't show up soon, I might revoke my proxy.

One immediate use that is possible. Want to get a message to someone listed, fast, even if they don't log in and check messages? Find anyone in a proxy loop or chain below the one you want to contact, and ask the person to contact the user directly. if they can. I don't and probably won't give or accept proxies where I'm not provided with a phone number. If a significant number of others also follow this practice, new applications become obvious.

I changed the text in on the Table page to reflect this understanding: this isn't merely an example what a proxy table might look like, it is an example of what one does look like.--Abd (talk) 21:00, 22 February 2008 (UTC)

No-template version of proxy files and Table

see this:

This should work wherever the Proxy Table sits, special proxy tables can be created using the same format (and the same proxy file references unless a user designates a special proxy in one). Subst can be used to create some of the fields, in particular the History link. Most user proxy files won't see a lot of edits, and, in any case, the diff wanted would usually be the latest or the one before that. What do you think? --Abd (talk) 04:18, 24 February 2008 (UTC)

Timestamp

Rather than use a timestamp as a verifying check, would using the edit oldid maybe make it easier to differentiate? MBisanz ^talk 05:58, 24 February 2008 (UTC)

If you can figure out a way to implement it, go for it... Absidy (talk) 07:40, 24 February 2008 (UTC)