Help people differentiate "live" (or "original") revisions from imported revisions.
We should make the Import feature in MediaWiki add tags like import and importupload to the imported revisions.
(From a brief TechCom triage meeting, by no means substantial yet or otherwise better, merely an idea). We could derive this information based on the imported username or user/actor type being indicative of an imported revision.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T284512 [EPIC] Empower others to develop new, and extend existing, editing experiences | |||
| Open | None | T188433 Tag all edits by editor used (WikiEditor, API, etc), not just VE | |||
| Resolved | Anomie | T179832 Handling of imported usernames | |||
| Open | None | T183061 Feature Request: Add a tag to imported revisions to easily identify them in edit history |
@Xaosflux generally RfCs are a little more fleshed out, that document the specific problem you want to solve, and how you propose to fix it technically. I think there's probably a decent case to be made for making it easier to identify imported edits, but why web vs API edits? Why would existing solutions like change tags not be suitable to solve this?
Why would they not be suitable for imports, for that matter? Once we have a flexible means of adding flags to page revisions, it makes sense to use that for everything.
As for API edits, I imagine the intent is to differentiate semiautomated edits from fully manual ones, but that's not a great way to do it. Edits through the mobile web interface and mobile apps use the API; VisualEditor probably does too.
The main push from this was for import vs direct - just trying to kill more birds with one stone.
I note that the existing change tags functionality would probably work well enough for imports.
@Anomie - if so, can this task be reformatted to something like "Add tagging functionality and default to the Import function" ?
After brief discussion, TechCom decided to decline this RFC, since it is a feature request, not a technical proposal. TechCom is not opposed to the idea.
To go forward, this would need a product owner and resourcing, then a concrete technical proposal. Perhaps Community-Tech is interested, or Collaboration-Team-Triage. Or this could go via https://meta.wikimedia.org/wiki/Technical_wishlist.