This proposal and T149664: Next steps for edit review look very similar. Could they be merged?

Quim asks:

This proposal and T149664: Next steps for edit review look very similar. Could they be merged?

The titles of these make them sound similar. But I'm not sure they are. @cscott's proposal talks about solving "the edit review problem," but I'd like to hear more about what he means by that. E.g., is it declining participation? Backlogs? Moves to reduce burdens on reviewers by barring new editors? I'd attend a session about any of those.

As Scott says, the offsite session session that inspired his proposal focused a lot on various ideas around pre-publication review. To a lot of people's ears, that is the opposite of what this session wants to focus on, which is pretty specifically newcomer-friendly edit review. There is a lot to be said about both those topics, I think. But maybe Scott and I should talk. How long are these sessions anyway?

In T150078#2780204, @jmatazzoni wrote:

How long are these sessions anyway?

Last year we went for 80 minutes in order to provide good time for deep discussions. We haven't discussed whether we want any changes there yet.

@Qgil, just checking: what does "Missing active discussion" mean? Thanks.

In T150078#2780204, @jmatazzoni wrote:

Quim asks:

This proposal and T149664: Next steps for edit review look very similar. Could they be merged?

The titles of these make them sound similar. But I'm not sure they are. @cscott's proposal talks about solving "the edit review problem," but I'd like to hear more about what he means by that. E.g., is it declining participation? Backlogs? Moves to reduce burdens on reviewers by barring new editors? I'd attend a session about any of those.

I think I agree that these two proposals are not quite the same, although they are related. I think I would distinguish them as "front end" versus "back end". As I read this proposal, it is concentrating on one particular use case (newcomers) and trying to imagine specific processes for them -- not necessarily even changing their edit experience, but using tools like ORES to identify newcomer edits and more effectively direct existing resources like Teahouse or patrollers.

My proposal is trying to look at the more general problem, and determine if there are specific functionalities we could build into our platform to support edit-review-merge workflows *in general*, concentrating on things we can't quite do yet. That is, can we decide how we want to represent an not-yet-reviewed (or not-yet-applied) edit in the backend, or how to represent review status in the database? Can we build general tools for displaying a proposed-but-not-applied edit as something more friendly than a wikitext diff? Can we build better "merge"/"rebase" functionality which can be used to prevent edit conflicts or allow reverting edits other than the most-recent?

For me, the "edit review problem" is just that the core mediawiki code doesn't currently have any notion of "unreviewed/unapplied edit", "edit review", or "merge". So I'm interesting in building out functionality that all the different review-related workflows (like the newcomer workflow in this proposal) can *use*.

On the other hand, I could definitely splitting sharing a long 80 minute session between T150078: Newcomer-friendly edit-review tools: help imagine what that looks like and T149664: Next steps for edit review (and other related proposals, if any). I think the specific newcomer workflow envisioned by this proposal could inform the tools proposed for T149664, and conversely some of the tools or representations proposed for T149664 may allow some further out-of-the-box thinking for newcomer-friendly workflows that might be possible.

I think it wouldn't be helpful to try to talk about a better technical solution to FlaggedRevisions at the same time as product-focussed things like "how do we make it easier for newbies to understand what a good edit is before they click save?" and "how do we make it easier for reviewers to notice that they're looking at a change by a newbie and should go easily/give supportful advice?"; they're pretty radically far apart. Maybe two different sessions?

On the other hand, I could definitely splitting sharing a long 80 minute session between

We had an hour on this in Seattle and just got started. I think it could be two sessions—I'd definitely go to yours. I would, however, request that you make the title of "Next steps for edit review" more specific, to differentiate it from this one.

In T150078#2786998, @jmatazzoni wrote:

@Qgil, just checking: what does "Missing active discussion" mean? Thanks.

This is now explained in more detail at https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Call_for_participation#Proven_interest

In T150078#2787973, @Jdforrester-WMF wrote:

I think it wouldn't be helpful to try to talk about a better technical solution to FlaggedRevisions at the same time as product-focussed things like "how do we make it easier for newbies to understand what a good edit is before they click save?" and "how do we make it easier for reviewers to notice that they're looking at a change by a newbie and should go easily/give supportful advice?"; they're pretty radically far apart. Maybe two different sessions?

Yes and no. I don't think it's helpful to erect arbitrary walls, so that we foreclose the possibility of having (say) better FlaggedRevisions[*] when contemplating how to avoid the newbie-edit/immediate-revert cycle. Right? Newbie edits wouldn't be immediately reverted if they weren't immediately applied to the flagged revision everyone is reading. So we need some communication between the two "sessions" (if that's what they are) so we don't try to solve hard problems with inadequate existing tools in session #1, while building fancy tools which don't actually address the hard problems in session #2.

I do agree that the facilitator should attempt to structure the conversation for balance and to avoid ignoring either side of the problem. But I'm not sure I agree that they should be deliberately held at arm's length from each other.

([*] This is granting your framing of T149664 as a "better technical solution to FlaggedRevisions", which is a narrowing I'm not sure I agree with... but we can have that discussion over in T149664, not here.)

*Anyway*, I guess what I'm advocating is a more-holistic view of the problem, and perhaps some flexibility in the summit schedule to accommodate that. Here's a strawman, taking up a slot-and-a-half (80 minutes + 40 minutes):

• 20 minutes to present/discuss T150078: Newcomer-friendly edit-review tools: help imagine what that looks like
• 20 minutes to present/discuss T149664: Next steps for edit review
• 40 minutes of breakout groups. 2+ groups work on ideas for T150078, 2+ groups work on ideas for T149664
• 40 minutes for the breakout groups to report, and synthesis/summary/wrap up discussion

That might be too much intermingling and structure. It's just a strawman! But something like that could ensure that the discussions inform each other, while still providing dedicated conversation for each (in the introduction and in the breakout groups).

That might be too much intermingling and structure. It's just a strawman!

That agenda sounds pretty ambitious to me. I am constantly amazed by how little meaningful meeting of the minds can actually happen in an hour—especially when everyone in the room is coming from a different knowledge level and background.

I think this proposal addresses a very important and timely subject. We have new tools that help us distinguish between good and bad faith edits. The default use-case for these tools is to make it easier to prevent and correct vandalism—that's considered by many to be a more immediately important task, and to some extent it's simply what we're used to doing. Using these tools to provide support to good faith editors requires more than just pointing those editors out. If that's what this proposal aims to discuss, count me in.

+1 to @Capt_Swing's comment. Maybe we can use the session to lay out the current tooling and where the gaps are. It would be great to highlight new projects that might fill in those gaps and how those tools re-imagine the boundary work for Wikipedia & other Wikimedia Projects. From just vandal-fighting to including newcomer support.

In terms of room capacity and configuration, what would be your preference?

• The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
• A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
• A big room in classroom configuration (up to 70-80 people, chairs and tables) and optional video recording (i.e. only recording the initial introduction but then relaxing things during the discussion, or no recording at all).
• A smaller room, flexible configuration, optional video recording...

I don't think we need to record the session. And I'd expect no more than 20 or so people. So probably either of the last two options would be find for me. Thanks!

In that case, this session is appropriate for the Unconference.

@jmatazzoni Hey! As developer summit is less than four weeks from now, we are working on a plan to incorporate the ‘unconference sessions’ that have been proposed so far and would be generated on the spot. Thus, could you confirm if you plan to facilitate this session at the summit? Also, if your answer is 'YES,' I would like to encourage you to update/ arrange the task description fields to appear in the following format:

Session title
Main topic
Type of activity
Description Move ‘The Problem,' ‘Expected Outcome,' ‘Current status of the discussion’ and ‘Links’ to this section
Proposed by Your name linked to your MediaWiki URL, or profile elsewhere on the internet
Preferred group size
Any supplies that you would need to run the session e.g. post-its
Interested attendees (sign up below)

• Add your name here

We will be reaching out to the summit participants next week asking them to express their interest in unconference sessions by signing up.

To maintain the consistency, please consider referring to the template of the following task description: https://phabricator.wikimedia.org/T149564.

@srishakatux, FYI, this is reformatted as requested.

To the facilitator of this session: We have updated the unconference page with more instructions and faqs. Please review it in detail before the summit: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. If there are any questions or confusions, please ask! If your session gets a spot on the schedule, we would like you to read the session guidelines in detail: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We would also then expect you to recruit Note-taker(s) 2(min) and 3 (max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be available in all the session rooms! See you at the summit! :)

Etherpad with session notes: http://tinyurl.com/reviewstream17

For archiving:
https://docs.google.com/document/u/2/d/175H5rkaHMFQTWw-U991_G1MpCUVEJACzoQJgPbFchog/

Notes of this session look great! :) Could you also copy the relevant notes and summary from these notes into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and link it from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes

Note-taker(s) view these instructions: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29

Note-taker(s) of this session: Follow the instructions here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines#NOTE-TAKER.28S.29 After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Your_Session and also link this from the All Session Notes page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/All_Session_Notes. The EtherPad links are also now linked from the Schedule page (https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Schedule) for you!

That session is now over. Notes: https://docs.google.com/document/d/175H5rkaHMFQTWw-U991_G1MpCUVEJACzoQJgPbFchog/edit#

Can someone please move the notes over to mediawiki.org?

@jmatazzoni are there any action items from this task or planning to use this space for further discussion? If not, I would close this task as resolved!