On 10 September 2014 04:58, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 12:54, Andrew Gray andrew.gray@dunelm.org.uk wrote:
- inter-wiki or intra-wiki integration of multiple-venue discussions
rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)
Yeah, that's getting into the "solves a problem I have" area I was thinking of.
A few more of these and experienced users will be demanding Flow.
[Talking well into the future, and free-lancing a little in Danny's area; please do not expect this soon.]
One of the pain points about our treatment of content vs. discussion right now is how to expose to casual editors of a page that discussion is on-going about a particular aspect of an article, or that there has been a lot of argument about an aspect of the page and that this is now 'settled' – not that it can't be changed, but that editors may wish to consider before blindly changing something.
These discussions can range from the very specific (what exact term / wording should we use here?) to the very general (we should take care to use photos of the concept from all 'sides' of the debate). Most often they're about a small chunk of content and proposals to alter, expand or remove it. Indeed, the need to comment on these is flagged quite often when talking about Flow – generally in terms of "we need to copy content into the discussion and back out again", which I think is a solution rather than the core problem we're trying to address, framed by our current way of treating discussions.
Normally these discussions, and their total lack of visibility to all but a handful of editors who read the talk page and all its archives before they make each edit, aren't a problem. It's rare that a page has issues, after all, and very often "common sense" gets you most of the way there, so even without knowing about prior discussion your edits can be uncontroversial.
Sometimes we make edits against these agreed points, and someone previously involved in the discussion notices and undoes the change (or "fixes" it or whatever), and might drop a note on their talk page to that effect. This is effective for very highly-watched pages, but adds a lot of burden to people to monitor their watchlists' articles for changes against their hazy memories of what has and hasn't been discussed. Certainly, editor working on recent changes patrolling won't know the particulars of each article and the local discussions that have been had.
Occasionally, we use HTML comments to shout at potential editors ("Do NOT change his race!" on Barack Obama's article on the English Wikipedia, for instance). These are confusing to newbies (it's a magic fragile syntax that's uncommon), don't always 'work' (lots of people tune out whacky syntax they don't know), and very rarely give an indication as to /why/ some user posted that instruction, when this dates from and whether it's still current, or if it actually has consensus.
To make it easier for editors, we could provide a way to attach discussions not just to an article (Talk:Foo is stuff about "Foo") but as well to a particular item inside Foo – a section, a paragraph, a template, a reference, an image. When you edit, we could show somehow discussions attached to that item.
There have been proposals to use a right-hand bar to show information relevant to the content in view ("see related Wikidata item"; "articles on this subject in other languages use these images"; etc.); that could be a neat place to put relevant discussions' subjects/titles (or even the whole discussion). Alternatively, we could put little markers in a tray/gutter that users can click on to see more of, or put a highlighted ring around content subject to recent discussion when editors change it. There are lots of ways we could consider making a more powerful, more visible way to discuss content.
Making these kind of tool available through VisualEditor would be pretty easy (though getting the design right for all our workflows would need some care, and as always the challenges of getting a reasonable, consistent design for phone, tablet and desktop platforms will need some thought). Doing it in the wikitext editor in a way that makes sense for users might be harder. However, "hard" is not a good enough excuse for us not tackling these kinds of big issues around making editing a simpler, more obvious experience that doesn't need people to have read the talk page and all its archives before making an edit.
Does that sound like a useful change for experience editors? :-)
J.