Gemeenschap wensenlijst enquête 2023/Edit-recovery functie

Edit-recovery functie
Het herstellen van niet opgeslagen bewerkingen die verloren zijn gegaan tijdens het bewerken.
Groep:	Community Tech
Teamleden:	Joydeep Sengupta, Dayllan Maza, Harumi Monroy, MusikAnimal, Sam Wilson, Karolin Siebert, Sandister Tei, Sammy Fox
Hoofd:	Joydeep Sengupta, Dayllan Maza and Karolin Siebert (Product Owners)

De functie Edit Recovery (voorheen bekend als Auto-save) was de #8 wens in de wensenlijst enquête 2023. Deze functie slaat wikitext en andere bewerkingsformulierinformatie op tijdens het typen, en maakt het mogelijk deze te herstellen nadat de browser per ongeluk is gesloten, of een stroom- of netwerkstoring of browsercrash is opgetreden. Er zijn meer dan eens verzoeken voor deze functionaliteit gedaan.

Deze pagina geeft een overzicht van de benadering door Community Tech om in de behoeften te voorzien die in het voorstel van deze wens zijn uitgedrukt, evenals het overwegen van eerdere discussies over het verzoek.

De functie is op alle wiki's ingeschakeld en u kunt het aanzetten door naar uw Voorkeuren te gaan. Feedback op overlegpagina.

Nuttige links:

• Community Wishlist Survey 2023/Editing/Auto-save feature oorspronkelijk voorstel op de wensenlijst
• mw:Help:Edit Recovery - eindgebruiker helppagina
• mw:Manual:Edit Recovery - technische documentatie

Achtergrond en probleem

Geschiedenis

Er is functionaliteit als Edit-recovery gevraagd in de 2016 enquête en vervolgens in de 2022 enquête.

Daarnaast werd in 2012 een ticket ingediend voor een functie auto-save in localStorage en werd een patch gestart. De grootte van localStorage was beperkt tot ongeveer 5MB en kon alleen tekenstromen bevatten; De patch werd in 2017 niet meer gebruikt.

In 2014 werd een ticket ingediend voor deze functie met een poging om automatisch opslaan toe te voegen met behulp van IndexedDB. Deze patch werd ook in 2016 niet meer gebruikt.

Er is een discussie geweest dat sessionStorage verloren gaat wanneer men naar een nieuw tabblad gaat zodat localStorage een verbetering zou zijn. Het probleem met localStorage is dat er een grootte limiet is, en door meerdere keren automatisch opslaan zou het waarschijnlijk overschreden worden.

Een andere optie is om de serverzijde van de auto-save data te opslaan, waar er geen groottebeperking zou zijn en het herstellen van gegevens ook op een ander apparaat kan worden gedaan.

In 2022 heeft Community Tech een onderzoek gedaan om de StashEdit API als mogelijke oplossing te onderzoeken. Dit betekent een autosave-levensduur van ergens tussen de 5 minuten en een half uur. Als alternatief kan een nieuwe databasetabel worden aangemaakt, in welk geval de levensduur tot 90 dagen kan zijn.

Opties bij implementatie

Voor deze wens hebben wij naar een aantal manieren gekeken om het te realiseren. Een primair onderscheid in deze was de locatie van de automatische opslaggegevens: als deze alleen op het apparaat van de gebruiker worden opgeslagen (wat we 'client-side' noemen) of worden overgedragen naar de Wikimedia-servers ('server-side'). Zie hieronder de juridische bezwaren met betrekking tot de eerste.

Voortbouwend op edit stash —  tijdslimiet onvoldoende

Terwijl een gebruiker een wikipagina bewerkt, wordt elke drie seconden de paginatekst als 'bewerkingsvoorraad' naar de server gestuurd. Deze functie bestaat zodat wanneer de pagina uiteindelijk wordt opgeslagen, deze sneller te bekijken is omdat de wikitext al naar HTML is omgezet. We vroegen ons af of we deze functie konden benutten door het mogelijk te maken om de opgeslagen wikitext op te halen bij het heropenen van een bewerkingssessie. Dit zou a) inhouden dat de tijd wordt verlengd waarvoor de opgeslagen bewerkingen worden opgeslagen (nu slechts vijf minuten); b) het wijzigen van de stashedit API zodat deze de wikitext teruggeeft gegeven de unieke hash van de inhoud; en c) het opslaan van die hash in localStorage in de browser. Afgezien van het feit dat het geen goed idee is om een bestaande functie te hacken om iets heel anders te doen, zou deze methode beperkt zijn tot het opslaan van autosave-gegevens voor ongeveer een half uur, wat niet genoeg is.

Nieuwe databasetabel en API —  Gecompliceerd en privacyproblemen

Er zou een geheel nieuw database schema en API kunnen worden gemaakt om de gegevens te bewaren. Dit zou de meest flexibele en krachtige zijn, waardoor autosaves met gebruikers kunnen worden gekoppeld en voor onbepaalde tijd kunnen worden opgeslagen (zoals Phabricator het doet). Dat brengt echter met zich een grote complexiteit in de ontwikkeling, evenals zorgen over de toegang tot gegevens (zie hieronder voor de juridische kwesties) en de zorg dat dit een 'ontwerp' wordt met een andere naam. De bewaartijd van de gegevens zou beperkt zijn tot 90 dagen.

Volledig client-side —  privaat, bewaking tegen verlies van verbinding, eenvoudiger

Browsers hebben drie hoofdmechanismen voor het opslaan van gegevens: sessionStorage, localStorage en IndexedDB. De eerste heeft een redelijk groot opslagquota, maar is alleen van toepassing op de 'pagina sessie' en wordt dus verwijderd nadat er een tabblad wordt gesloten. De tweede heeft een veel kleinere quota die wordt gedeeld tussen alle gebruikers van localStorage en dus ook niet geschikt is. Het laatste, indexedDB, is het meest nuttig, omdat het veel gegevens kan opslaan en blijft bestaan zelfs als de browser wordt gesloten of crasht, enz. Dit is het meest veelbelovende systeem om te gebruiken voor autosave, hoewel er nog steeds problemen zijn die moeten worden overwogen (zoals hoe de gegevens betrouwbaar te verwijderen nadat ze niet meer nodig zijn).

The other aspect of implementation that we considered was where to build the feature: in MediaWiki core, or in an extension (either new or existing). We settled on Core, for a number of reasons:

Extension  

There was no existing extension that was an obvious good fit for Edit Recovery, so the option was to create a new one. An extension would be suitable if the codebase will become large or have other dependencies, but we didn't think this very likely. It could also make deployment more complicated, as it'd have to undergo security review and the full new-deployment process.

MediaWiki Core  

Features added to core should be applicable to every MediaWiki installation (including non-Wikimedia ones), regardless of what extensions it has installed. They may also be used by extensions, and so having them in core means that those extensions don't need to have extra dependencies on other extensions.

Legal considerations

In previous work around this topic, concerns have been raised about the possibility of people using a private data storage feature for undesirable purposes (for example, sharing an account username and password and then passing data via the autosave feature).

Community Tech asked WMF Legal to weigh in on this, and their analysis was that there are not any strict legal reasons to not build such a feature, but that a few points need to be kept in mind:

• A time limit on the time that the data is stored, with a maximum of 90 days (in line with other private data retention within Wikimedia).
• A way for Trust and Safety to access the data for a given user, if a court requests it (this is common in other systems with this sort of feature, such as email drafts).
• For all of a user's data to be able to be deleted if they request it.

These concerns do not apply if the data is stored client-side, because the data stays on the user's device and is their own responsibility.

Not a 'drafts' feature

One aspect we're very clear that we want to avoid is that it end up being a system for maintaining private drafts of pages. There is a long history around that topic, but the autosave wish is specifically around shorter-term recovery of in-progress edits.

Feature details

Summary: It is possible to close an in-progress edit form (via closing the window, the browser crashing, etc.) and have all data restored when you re-open that same page for editing again (at any later time).

• A page is identified by its title (so if a page is moved during an editing session, the recovery happens at the old name).
• A section of a page is identified by its number (so if a section is added or removed by a different user, the recovery might happen for the wrong section, or not happen at all). It's not possible to edit a section of an old revision.
• While editing, all edit form values are saved to the browser's IndexedDB storage. This is done after every one-second pause in typing, or any time a non-typing field (checkbox etc.) is changed. All core content types are supported (Wikitext, JavaScript, JSON, & CSS), and extensions may provide or remove support for edit recovery as they see fit.
• If a page (or section) is opened for editing and there is saved recovery data, it is loaded into the form.
• The edit-recovery data (for a page and all of its sections) is deleted in a few different situations:
  • after a page is published;
  • when the Cancel link is clicked;
  • when the user logs out;
  • when the user switches from wikitext to visual editing (Visual Editor has its own edit-recovery system);
• After edit-recovery data is loaded the page will show the normal 'are you sure' warning when the user tries to navigate away (even if no further changes have been made).
• If an editing session is underway for a page, and the user navigates away (or opens a separate tab) to edit an old version of the page, then the recovery data is not loaded and no changes to old revisions will be stored.
• Still to be decided: What happens when someone edits the same page at the same time in two different tabs?

Updates

16 oktober 2024: Update over het herstellen van bewerkingen

Allen bedankt voor de waardevolle feedback over de functie Edit Recovery! We hebben enkele belangrijke verbeteringen aangebracht op basis van uw opmerkingen, zie de overlegpagina. Voorheen herstelde de functie automatisch wijzigingen als u het bewerken hervatte en gaf u vervolgens de optie om ze als volgende stap terug te draaien. Met deze update wordt eerst gevraagd of men de wijzigingen wilt herstellen of niet. Nu hebben redacteuren meer controle over hun werkwijze.

Voor een visuele demonstratie van deze wijzigingen, zie de onderstaande afbeeldingen:

• 
  Vorige versie: Wijzigingen werden automatisch hersteld, redacteuren moesten de wijzigingen verwijderen als ze die niet wilden.
• 
  Nieuwe versie: De bewerkers worden op de hoogte gesteld van niet opgeslagen wijzigingen en hebben de keuze om deze wijzigingen te doen of ze te verwijderen.

16 september 2024: Feedback gevraagd over Edit-Recovery

Hallo gemeenschap, de functie Edit-Recovery is actief in Special:Preferences, Editing sinds het voorjaar van 2024, en op basis van de feedback, willen we vragen hoe de functie verder verbeterd kan worden.

Nu gaat Edit-Recovery ervan uit dat een gebruiker zijn bewerkingen wil uitvoeren bij het herladen of opnieuw openen van een pagina, en vraagt gebruikers om hun bewerkingen te verwijderen. Echter, op basis van feedback op onze overlegpagina, zouden sommige gebruikers er de voorkeur aan geven dat Edit-Recovery aanneemt dat een gebruiker zijn bewerkingen niet wil uitvoeren, en in plaats daarvan zouden ze moeten worden gevraagd om bewerkingen uit te voeren.

Het team Community Tech vraagt op dit moment om input van de community over de vraag of Edit-Recovery werkt zoals verwacht, of dat gebruikers liever willen dat Edit-Recovery gebruikers aanspoort om bewerkingen te herstellen.

Geef uw feedback op de overlegpagina. We hopen uiterlijk woensdag 26 september 2024 een beslissing te nemen.

October 25, 2023 – Edit-Recovery is nu in Beta beschikbaar voor testen

Hallo gemeenschap, we hebben een paar updates. De wens Edit-Recovery (voorheen de functie Auto-save) is nu beschikbaar op Beta Cluster, en u wordt hierbij uitgenodigd om het te testen.

Begin met het bewerken van een pagina op een Beta-site, bijvoorbeeld [https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page simple.wikipedia.beta.wmflabs.org, maar publiceer uw verandering niet. Wacht 5 seconden en sluit de tab. Open de tab opnieuw. Uw bewerking moet zijn hersteld!

We werken aan het zichtbaarder maken van de functie met een element zoals een melding bij het herstellen van bewerkingsgegevens, met de mogelijkheid om de herstelde gegevens te verwijderen.

Vragen en feedback zijn welkom.

Bedankt, team Community Tech. ––– STei (WMF) (talk) 17:28, 25 October 2023 (UTC)

July 4, 2023 – Investigations and your input

The CommTech team is reviewing any investigations, discussions, patches that have happened around this wish to determine what is next.

We have would like you to answer some questions as follows:

• Hoe lang moeten we de gegevens opslaan voor de automatische opslagfunctie (met inachtneming van juridische zaken, aangezien de juridische gevolgen worden verminderd door de hoeveelheid tijd die we bewerken te verlagen)?
• Wat moeten we opslaan in de database om de functionaliteit van auto-save te laten werken? Dat wil zeggen:
  • Bewerkingen
  • Revisies
  • Pagina's
  • Tekst

Laat uw reacties achter op de overlegpagina als u wilt reageren.

Meer gebruikers/stemmers pingen over de feedback ronde. ––– ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (overleg) 10:50, 4 juli 2023 (UTC)

Meer gebruikers/stemmers pingen over de feedback ronde. ––– ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ STei (WMF) (overleg) 16:33, 5 juli 2023 (UTC)