User:Yair rand/RTC

From mediawiki.org

By default, editing is "private"[note 1]. Drafts, "editing sessions", whatever. Terminology tbd.

  • Possibly make distinction between non-publically-viewable sessions and sessions started by one person without intending for others to join but not private.
    • Experienced users may wish to work alone without having to worry about vandals or interacting with others, new users might want help. Maybe have a "request assistance" button for newbies allowing an experienced user to join a session.
  • Two different possible approaches here: Collaborative-first, or independent-drafting-first. Which one is used has implications elsewhere.

Users can start "open sessions"(/drafts?), others can join sessions or split them. An article can have more than one session/draft in progress.

  • Probably don't use the word "split".
  • Unsaved sessions do not disappear when everyone leaves. They are public drafts, and left open. Maybe even accessible as if normal open sessions.
    • If only edited by one person, editor can discard draft.

Anyone can save a joint session.

  • It is recorded that they saved it. Transparency is important, don't blame the guy who's half-finished edit got saved before they were ready.
  • All participants towards the change are recorded as authors. The edit shows up in their contributions, etc.
  • Upon clicking save, interface shows line-by-line diff (like the "Show changes" screen), and allows deselecting/un-highlighting any given line. Deselected lines are not saved.
    • If deselected lines were the only ones worked on by a participant, maybe don't show them as contributors to the diff.
      • Could be a problem. Wouldn't this break detailed histories?
        • Maybe not. If diffs can be cleanly separated, a split should be possible, even with overlapping timelines.
        • ...Maybe. Line-by-line, would it include sentences that were added, then completely reworked (original gone) by another user?
    • For groups of lines, think click+drag to un-highlight.
  • Saving does not eliminate the session.

Individual diffs/revisions contain internal "histories", which have full record of editing, and chat logs (described below).

Chat functionality allows wikitext or VE, and allows editing previous comments, with edits preserved. Again, live transparent edits.

  • (Possibly.) Live typing data is shown. Enter pushes it into the lines.
    • Live typing can be manually disabled.
  • Previous chats are accessible from the talk page, in collapsed form. (Flow or regular talk pages.)
  • Chat messages can be "deleted" by admins.
    • Completely transparent, logs, deletion summaries, and all. Deletion happens immediately upon clicking to do so, then prompts summary.
  • Edits to comments are recorded. Refining chat is good, the chat logs will be read by many.
  • History of each chat message is transparent, all the way through.
  • Ideally talk page chat logs are direct fancy transclusions, not copies. (Incidentally, general diff transcluding should have been available a long time ago. Linking makes things difficult. But that's a discussion for another time.)
  • Chat needs a hotkey.
  • Problem: Chat will probably be used on occasion to help out new users figure out how to do things. This needs to be accommodated, but shouldn't clog the article talk page, if the chat was not relevant to the article being edited. Perhaps have a system for having chats only go to the user talk pages.
  • In general, don't allow chats outside of the editing screen.

Should chat exist?

  • More to the point, should chat be separate from talk pages?
  • Maybe just make all talk pages like chat.
    • No. That would mess things up enormously. Chats are quick messages/logs, talk pages are read through thoroughly by people wanting to know about the historical debates.
  • Maybe allow editors to bring talk threads to the chat?
  • If chat "threads", can users target other editors, so if they don't have chat window open (?) it pops up?
  • Doc proposal shows a "Quick conversation" bar separate from topic groups. Sounds good.
  • Chats can probably get "heated" a lot more easily than talk pages. Needs some thought.
  • Relevant topic: Edit summaries (or draft names?) in advance. (Don't even think about calling it a "status".) If a person starts to move a paragraph down a bit, they shouldn't be reported for deleting a full paragraph before they get the chance to paste it.

(Maybe.) Sessions can be named, for specific draft purposes.

  • Think more about naming drafts, especially in context of leaving them open.

Needs a "Merge changes" interface. Unclear how to do that.

(Maybe) When displaying diff afterwards, use Etherpad-style highlighting?

Dealing with vandals.

  • The "report" button "screenshots" chat log and current text of edit and very recent changes (to avoid vandals deliberately tripping users into giving "erroneous" reports).
  • A blocked user is immediately expelled (from editing/chatting, not from viewing), but other intermediate methods could exist.
    • "Suspend", very short term blocks (think 3-10 minutes).
      • Can be specific to the article, and may or may not have a log entry outside the diff. In fact, doesn't even block everything related to the article. Suspended users can still have open an edit window in private.
      • Communities will need to determine policies for this. Personally, I imagine being very lenient, with short suspensions that have associated communication between the suspending admin and the disruptive editor.
      • Suspensions automatically open associated dedicated chat threads, and suspension can be very quickly removed by a button right there in the chat box.
        • (Maybe.) Suspension-associated chat threads can be accessed/joined by others via a "suspended" icon next to the user's name in the edit window.
        • The style should be similar somehow with that of chat used for instructing newbies.
      • Associated action: "full undo", which clears all the user's changes to the article from that session.
  • Blocking/suspension is a *last resort*.

Community

  • Should it be possible to be notified whenever someone starts editing a page on one's watchlist?
  • There is no deadline, but users may be more likely to forget this during group editing. How to reinforce the idea?

Next steps[edit]

There's a lot to be done, including substantial changes to diff structure, a chat system to set up, a lot of UI work to do, and of course the direct VE work. Most of this has no usable results on the way, and a lot of necessary changes may break things.

  • It is no longer true that a revision always has a single author.
  • Revision content now has a huge load of associated data beyond simple "before" and "after". A full record of every little change, the author of every change, a chat log full of distinct messages with their own histories...
  • Pages now have attached live sessions/drafts, which need to be stored somewhere and accessible somehow.

Shipping an unfinished product could have disastrous consequences. Please don't do that without asking the communities first. Potential intermediary steps before full deployment include:

  • Collaborative editing is available only to experienced users (probably only those who specifically enable a beta feature). Not required: Suspension and reporting tools.
  • A small subset of new users have a "request assistance" button available on the edit screen, which allows an experienced user to join the session in a limited way. The experienced user can not edit, but can view the new user's editing live, and can access a chat box. The button only appears when an experienced user is already available to assist them. Requires a special page ("Special:AssistNewbies", maybe) for the experienced users, and a functioning chat mechanism which does not post to the talk page. Not required: Reporting/suspension tools, talk-page chat archiving, multi-person editing (including multiple authors to the revision), and detailed revisions. (Alternative option: set it up specifically for user adoption groups.)




  1. (A previous proposal of mine said the opposite: "Multi-person editing should be the default. Anyone who clicks edit while someone else is editing should "join" their edit screen unless otherwise specified. If a user wants to go into a "private editing" mode, their edits should take lower priority when resolving an edit conflict." Maybe don't take this particular part too seriously.)