@JFernandez-WMF, should we move this back to Design in Progress, since you are creating updated designs for adding an edit?

Based on the conversation that we've had with Engineering, here's the new proposal for adding an edit, both from the participant and organizer side:

1. Participant/organizer clicks on 'Add edit to this event

2. Once that button is clicked, a dialog comes up prompting the user to insert an edit identifier: revision ID, full diff link, or Special:Diff link

3. After the user adds their edit, they receive a confirmation message.

Pinging @Daimona, @cmelo, @MHorsey-WMF here, how does this sound? I am especially curious about the dialog, is that feasible? Are the formats mentioned there the correct ones?

In T398470#11132920, @JFernandez-WMF wrote:

I am especially curious about the dialog, is that feasible?

Yes, it is. It does mean that the feature is only usable with JavaScript, but I suppose that's fine (we could duplicate the form somewhere on this page and only show it if JS is unavailable, if need be).

Are the formats mentioned there the correct ones?

This is the tricky bit. The key question is: would they be able to associate edits made on a different wiki? There's also a similar pending question that is being discussed in gerrit. If so, we'd also need a wiki selector.

As for individual formats: oldid is fine for sure. Special:Diff link I don't know how useful it'd be -- I'm not sure if there's anything in the UI linking to that page, when I use it I typically need to get the oldid first anyway. Diff link might work if we only allow local edits, but for foreign edits, I'm not sure if we can reliably parse the URL to extract the correct revision ID.

Another thing to keep in mind with diff links is the direction: compare

• https://en.wikipedia.org/w/index.php?oldid=1304588117&diff=prev
• https://en.wikipedia.org/w/index.php?oldid=1304588117&diff=next

Same oldid, but different directions, and therefore they indicate different edits. This could be slightly problematic if we accept the raw revision ID as input, because depending on which of the two directions the link uses, the ID may or may not match the edit that the user wants to add.

thanks @Daimona ! mm okay this is tricky indeed

@ifried do you have any thoughts on this?

@Daimona & @JFernandez-WMF: Responses below to both topics...

• Wiki selector: I assume it would be more technical effort/complexity to have a wiki selector? If yes, I don't think this is essential for the MVP. We could require that editors go to the wiki where the edit was made, and we can have a message like: "Visit the wiki of the event to update your event contributions," with wiki of event being linked to the wiki. If it is adds only a tiny amount of extra effort, we could have a wiki selector. As for post-MVP, I still don't know how essential this is (it would be useful to get user feedback). We may want to eventually add in such support, or we may never find it to be essential.
• User indicating id: Given that two different revisions can have the same old id, is there something else that could uniquely identify the revision?

In T398470#11141849, @ifried wrote:

• Wiki selector: I assume it would be more technical effort/complexity to have a wiki selector? If yes, I don't think this is essential for the MVP.

Bah, I think it would be pretty easy actually, similar to the selector in the registration form.

We could require that editors go to the wiki where the edit was made, and we can have a message like: "Visit the wiki of the event to update your event contributions," with wiki of event being linked to the wiki.

Note that we don't know what that wiki might be, because there could be multiple wikis. All in all, at least in its simplest form, I would totally prefer the wiki selector as it's roughly the same complexity.

• User indicating id: Given that two different revisions can have the same old id, is there something else that could uniquely identify the revision?

No two revisions can have the same oldid, "oldid" being basically jargon for "revision ID". But you can have two diff links that use the same oldid but refer to different revisions, depending on the "diff=" parameter. I'm not sure what to do about that. Maybe just have clear instructions? See also https://en.wikipedia.org/wiki/Template:Diff

Hi @Daimona,

• Great, let's use wiki selector then! Preferable from both a product and technical perspective. Are designs needed, or no?
• As for the user identifying a revision to add: Apologies, I'm still not completely following the technical recommendation. What would be the recommendation for how someone would do this? From my perspective, I think it would be easiest if the user could just copy/paste the full URL of the diff, but it seems like you're saying it could be too hard to parse the URL to extract the correct revision ID... so, I'm wondering what could be possible instead.

In T398470#11145183, @ifried wrote:

• Great, let's use wiki selector then! Preferable from both a product and technical perspective. Are designs needed, or no?

I don't think we'd need exact design, just the text and perhaps a very high-level description.

• As for the user identifying a revision to add: Apologies, I'm still not completely following the technical recommendation.

That's a good sign, because I did not have any recommendation ;)

From my perspective, I think it would be easiest if the user could just copy/paste the full URL of the diff, but it seems like you're saying it could be too hard to parse the URL to extract the correct revision ID... so, I'm wondering what could be possible instead.

I'm not sure if that is the case, I only mentioned it as a possibility (it wouldn't be unsurprising, given the cross-wikiness of it all). Maybe it's fine though, I suppose it ultimately depends on what parts of the URL are configurable / translatable / could generally be different. My thought was that the person working on this task could determine that. Other than that, entering just the oldid is the easiest solution technically speaking, but I do agree that entering the full link would be preferable for usability, if possible.

I created T403727 as a placeholder for the implementation task, including a note on permission checks following discussion with @cmelo.

Hehe, okay, thanks for creating the task and patiently explaining things, @Daimona!

I will add some details to the task.