Jump to content

Talk:Revision review group

Add topic
From Meta, a Wikimedia project coordination wiki
Latest comment: 18 years ago by Dan100 in topic Backend

A look-ahead Pragma[edit]

An Idea that resides in the fringes of my understanding of the Wikimedia architecture:

Can the Revision review functiality have a look-ahead feature that quickly passes pre-approved articles or edits? In this scenario, metadata, (or something) contained in WikiProjectFormat (per w:Template:WikiProject ):

  1. Articles
  2. Categories
  3. Lists
  4. Templates
  5. Users
  6. (keep it simple)

All set up and maintained by the project group, is quickly passed from the Great RC to a Sub_rc for WikiProjects.

A group, or even their bot for that matter watches and snatches from the queue that which it expects. Each item has issued to it a time-to-live or watchdog timer, however you call it. If Human Eyes see it (or a digested report) within so much time - fine. The article or edit goes to it's permanent home in the intended namespace. If the Human maintainers just can't get to the review before the time is up, that also is fine. It can go up to a shelf to be held, back down into the Sub_rc queue or into a bucket as a demerit for the group (not really my idea - for the record).

The thing is, you have notification going on between cooperative processes - Human & machine that is programmed to expedite the expected, through handlers the desirable as determined by each WikiProject group,thus, freeing up resources for well... you know... the other Revision review tasks. Quinobi 06:57, 10 July 2005 (UTC)Reply


I'd be interested in discussing backend stuff, but mostly from a point of authentication. I'm moving in less than a month, so I really don't want to get into a lot of coding until I settle down again. As I mentioned on en, I said I'd fix a few minor things with CDVF and that'd be it for a while. I could trivially add backend communication to CDVF, but the only reason I haven't yet is that I haven't been able to think of a very simple way to authenticate. When I first thought up the idea of CDVF, the RC streams were on freenode, so it just seemed natural to authenticate against freenode registered names. Then, right before I got finished with the first version, the streams were switched to the wikimedia servers, so everyone's anonymous and you can't talk at all. I was also a bit reluctant to leech freenode bandwidth. I really didn't think CDVF would be used by a lot of people — really just those who already used the IRC streams already. Now at least some, if not most, of the people using it don't really have a good handle on IRC at all, so I don't feel right throwing them into learning about IRC, having them download a real client to sign up for an account on freenode, etc.

I do have one potential authentication solution that I just thought of while writing this. Use Freenode, but have someone else register the accounts. That is, someone on Wikipedia requests an account (on my talk page, for instance), then I sign up one for them, send them the username and password. They put it in CDVF, it connects to freenode and authenticates. The person in charge also adds their name to a protected page that is fetched on connecting to get a valid list of trusted users. All the people in that channel would then be the backend. This introduces two issues that are easily dealt with (in my mind):

  • We have one person who says "Yes, this person is OK". Not exactly Wikipedia-like, but then again CDVF isn't Wikipedia.
  • Any administrator could edit the protected list of trusted users, but we all trust admins anyway.

So, what do you all think? This sounds interesting enough (to me) that I'd probably be motivated to code again instead of pack boxes. CryptoDerk 11:02, 10 July 2005 (UTC)Reply

That sounds great. I don't think the two points you raised are show-stoppers - you counter them youself fully. Go for it! Dan100 12:11, 18 July 2005 (UTC)Reply