Extension:Graph/Plans/it

<translate> Tracked in [[<tvar name=1>phabricator:</tvar>|Phabricator]]</translate>
<translate> Task <tvar name=1>T334940</tvar></translate>

Update April 2024

Hello everyone – I’m Marshall Miller; I’m a Senior Director of Product at WMF working with the product managers and teams that focus on the user experience of reading and editing the wikis.  Thank you all for being part of this ongoing conversation and being patient during the frustrating outage of the Graph extension.  I gave the last update about graphs here and on wikimedia-l. I have since talked to many volunteers about their experiences and needs with graphs, and gathered a group of staff members to propose a plan.  I am back with a proposed plan for your feedback and input. I'm posting here on the project page instead of the talk page so that this update can be marked for translation to other languages. There is a new header on the talk page for discussion.

Summary

In short, we at the Wikimedia Foundation propose moving forward with an approach that many community members have suggested: building a new service to replace the Graph extension. This approach will enable editors to create basic visualizations, will require coordination with communities around migrating existing graphs, and will be extensible by developers who want to build and maintain additional functionality.

We’ve needed some time to consider all of the architectural questions and how to resource this work, and now we want to hear from volunteers on whether this sounds like the right approach. This work will be led by Chris Ciufo, the product manager with the Design System team.  You can expect to hear from him going forward.  There’s more information below for those who want to see the details and considerations for this approach.

Since this work hasn’t started yet, there are still several months to go before the new graphs are operational.  We’ll be getting the right engineers involved and start architecting over the coming weeks, making sure we have a strong plan and are ready to iterate on it, and then likely starting this work in July as staff members become available from their previous projects.  We do not know yet how long it will take before the first types of graphs are operational.  We’re happy to discuss ideas that community members have about what, if anything, to do about the graphs continuing to be unavailable during these upcoming months.

Rationale

Chris and I are proposing this approach based on looking at how people have used graphs in the past, how we think they will use them in the future, and considerations on making sure our technology will be secure, scalable, and maintainable going forward.

In looking at how people have used graphs in the past, we see that graphs are a valuable, but not overwhelmingly common tool in the wikis. In English Wikipedia, graphs are used on about 10,000 articles, which is 0.15% of all articles, and across all Wikipedias, they are used on about 178,000, which is 0.28% of all articles.  Outside the main namespace, graphs are used more often, frequently because they are a part of templates that are displayed heavily.  For instance, in Arabic Wikipedia, there was a pageviews graph on every Article Talk page (until they were recently removed).  Importantly, we’ve noticed that the large majority of graphs are relatively simple: bar, line, pie, etc, and use data inline in the wikitext or in the Data namespace on Commons.  The resourcing for graphs should match this moderate usage – sufficient support, but not for complex functionality that isn’t widely used.

Technical discussion

The functionality of the new extension would be more limited compared to the old one, especially in that it won’t support all the visualization types and data sources of the old extension, but this approach represents a fresh start to a more sustainable future with graphs.

In terms of security, scalability, and maintainability, we decided in December that there was not a viable way to fix and continue with the legacy Graph extension.  Among other options, we attempted upgrading to Vega 5 (only to continue to find the same security issues), and we tried wrapping the Vega canvas in a sandboxed iframe (which caused significant performance issues).  This meant that a path forward for graphs would require a new extension.

Here is the brief outline of the approach we’re thinking about:

• The legacy Graph extension would be sunset.
• The Foundation would build a new parser tag extension that supports a limited set of predetermined visualization types, like basic charts and maps, that cover the majority of existing use cases, which editors would specify in wikitext and get displayed as static images on wiki pages.
• Rendering server-side would avoid known or substantial security risks, such as those in the legacy Graphs extension.
• We do not know yet which visualization library or libraries it would use, whether Vega, d3 (which powers Vega), something like Our World in Data-Grapher, or something else.
• The new extension would support graph definition data specified inline or through Commons tabular data (in the Data: namespace), as was supported by the Graph extension. We would try to offer assistance to migrate legacy graphs using these data sources.
• It would be able to be extended with new visualization types by staff or volunteer developers through a controlled, centralized, and code-reviewable process.
• It would be able to be extended to draw data from other sources, such as Wikidata, which it won’t be built to do at the outset.
• It would display graphs on the Wikipedia iOS and Android apps (this was not possible with the Graph extension after Graphoid was decommissioned).
• It would be officially maintained by WMF to address bugs.

In the many conversations around graphs, volunteers have also raised longer term questions about “interactive content”, such as timelines and 3D objects. Rebuilding the capability to serve simple graphs securely will be a large amount of work for staff and volunteers. As part of this, the new extension will be readily extensible by volunteers who have the technical skill to add more sophisticated visualizations and more data sources. This may be an open door to some kinds of interactive content, but the larger topic of interactive content is worthy of separate, continued conversations moving forward.

Moving forward

Moving forward, we want to hear your thoughts on this approach:

• Does this seem like the right way to proceed?
• What are the basic visualization types that are most important to support? Which ones can we do without?
• Which use cases are you concerned about being missed?
• How will communities need to participate or react to these changes?

As we discuss, there are many important questions to sort through. One that is top of mind for me is what will happen with the ecosystem of templates and data sources that has been built around the Graph extension over the last ten years. While we want to make it easy for many of the existing graph specifications to work in the new system, we will need to think through this together.

Thank you for reading this long update and for continuing to be part of this effort. I know many of you have spent a lot of time over the past months discussing graphs and building workarounds. We’re looking forward to continuing the work.

Discussion for this update

Historical details - To be updated soon

Questa pagina è un luogo in cui lo staff e i volontari del WMF possono raccogliere le informazioni necessarie affinché il WMF decida il ruolo che svolgerà nel garantire che le esigenze per cui l'estensione Graph è emersa continuino a essere soddisfatte.

Progress

Phases to fix Extension:Graph

Phase	Tracking task	Status	Completion date
Phase 0: Invite volunteers to review roadmap		File:OOjs UI icon check-constructive.svg <translate> Done</translate>	File:OOjs UI icon check-constructive.svg <translate> Done</translate>
Phase 1: Validate Security of Sandboxing Approach	Initial approach: T222807	Initial approach did not work.
Phase 2: Transition Graph Extension to Vega 5	T165118	File:OOjs UI icon reload-progressive.svg <translate> In progress</translate>
Phase 3: Define maintenance responsibilities and security/incident response
Phase 4: Deploy Graph Extension (Vega 5)
Phase 5: Optimize the Graph Extension's longevity

Tabella di marcia

📍 Fase 0 - Invitare i volontari a rivedere la tabella di marcia

Obbiettivo

Garantire che i volontari comprendano e sostengano sufficientemente le Fasi 1-5 in modo che noi (personale e volontari) possiamo prendere decisioni/compromessi in modo efficiente man mano che emergono durante l'implementazione.

Step

1. Volontari e WMF per discutere la tabella di marcia proposta e migliorarla secondo le necessità.

Fase 1 - Convalida della sicurezza dell'approccio sandboxing

Obbiettivo

Assicurati che l'iFrame sandbox sia sufficientemente sicuro 1) implementando l'estensione Graph utilizzando Vega 5 sul Beta Cluster e 2) pubblicando la documentazione e gli strumenti necessari per i volontari e il personale per valutarne la sicurezza.

Step

1. Completare la patch sandboxing work in progress per fornire l'infrastruttura di base per gli step futuri.
2. Creare una pagina "test box", come estensione o come pagina speciale nel core, che consenta l'esecuzione di JavaScript arbitrario all'interno della sandbox dell'infrastruttura.
3. Distribuire la pagina "test box" nella pagina Cluster beta, con le regole sandbox iniziali appropriate.
4. Testare la pagina "text box" per valutarne la sicurezza e perfezionare le regole in sandbox in modo iterativo.
5. Eseguire qualsiasi analisi di sicurezza statica pertinente rispetto al codice aggiornato prima della distribuzione.

Fase 2 - Transizione dall'estensione Graph a Vega 5

Obbiettivo

Preparare l'estensione Graph per Vega 5 reimplementando le funzionalità di Vega 2 utilizzando la sintassi compatibile con Vega 5 in modo che, in futuro, tutti i nuovi grafici trarranno vantaggio dai miglioramenti di sicurezza, accessibilità e sintassi di Vega 5.

Step

1. Connettere Vega 5 all'infrastruttura sandbox; implementare ulteriori controlli sandbox sul loader di Vega 5, se necessario.
2. (Re)implementare il supporto del protocollo per Vega 5, basato sulle implementazioni di Vega 2, valutandone al tempo stesso la sicurezza e la manutenibilità.
3. Distribuisci Vega 5-in-a-sandbox nel Beta Cluster per consentire ai volontari di eseguire delle valutazioni iniziali.
4. Testare e valutare l'approccio "Vega 5-in-a-sandbox".
5. Condurre ulteriori test di sicurezza con payload specifici di Vega5 per dare seguito al lavoro della Fase 1.
6. Convertire il convertitore Vega 2-to-5 esistente in uno “strumento 2-to-5”, che aiuta i volontari a convertire le specifiche Vega 2 esistenti nella sintassi Vega 5.
7. Implementare un messaggio simile a quello descritto da Pietrasagh che inviti le persone a migrare i grafici basati su Vega 2 a Vega 5.

Fase 3 - Definire le responsabilità di manutenzione e la risposta in materia di sicurezza/incidente

Obbiettivo

Definire quale è il livello di supporto di manutenzione che i volontari possono aspettarsi, chi sarà responsabile di fornire tale supporto e come risponderemo alla sicurezza/risposta agli incidenti in futuro, in modo tale che il personale possa sentirsi sicuro nell'implementazione dell'estensione e i volontari possano sentirsi sicuri di dipendere da essa.

Step

1. Determinare chi all'interno del WMF sarà responsabile della sicurezza/risposta agli incidenti in futuro.
2. Definire un piano di manutenzione e supporto che stabilisca aspettative chiare su ciò che i volontari possono aspettarsi dal WMF in relazione all'estensione del grafico in futuro e quale/i team sarà responsabile della fornitura di tale supporto. Per esempio: l'aggiornamento alle versioni future di Vega e altri compiti elencati nella Fase 5.

Fase 4 - Distribuzione dell'estensione Graph (Vega 5) in un iFrame sandbox con una politica di sicurezza dei contenuti restrittiva per la produzione

Obbiettivi

Offrire ai volontari l'accesso alle informazioni e alle funzionalità che la disattivazione dell'Estensione Graph li ha lasciati senza.

Sviluppare le risorse (documentazione + strumenti) necessarie per supportare gli sforzi di trasferimento dei volontari

Step

1. In collaboration with volunteers, create “Vega 5 porting” page linking both to the upstream 2-to-5 porting documentation as well as specific information relative to Extension:Graph. E.g. changes to protocols, wiki best practices, related templates and modules, etc.
   1. Se appropriato, la documentazione può anche menzionare come accedere all'"ultima versione di Vega 2" del grafico da trasferire da archive.org.
2. Con la community, trasferire i moduli Lua esistenti che generano l'output Vega 2 per emettere l'output Vega 5.
3. Trasferire i grafici Vega 2 esistenti su Vega 5 e offrire strumenti che aiutano a facilitare questa transizione
4. Costruire un catalogo più completo di casi d'uso e su quali funzionalità di Vega si può fare affidamento

Fase 5 - Ottimizzare la longevità dell'estensione Graph

Obbiettivo

Ottimizzare la longevità dell'estensione Graph e supportare la comunità nella creazione di grafici sui progetti Wikimedia.

Step

1. Deprecare e quindi rimuovere il supporto per Vega 2 dalla base di codice, creando categorie o tag linter per contrassegnare eventuali grafici Vega 2 rimanenti.
2. Trasferire formalmente le responsabilità di manutenzione dell'estensione Graph a un team di ingegneri della Wikimedia Foundation.
3. Creare strumenti e processi documentali per facilitare gli aggiornamenti di routine di Vega da parte dell'upstream per rilasci minori/patch/di sicurezza e impegnarsi a rispettare uno SLA appropriato.

FAQ

1. When can we expect to see a timeline for the Roadmap above?
   1. The team expects there to be a timeline to share during the first or second week of November 2023. By this time, we think we will know whether volunteers see any fundamental issues with the roadmap that warrant it being revised.
2. Once re-enabled, will the Graph Extension support pseudo-protocols? Yes. Once the Graph Extension is re-enabled, it will support the protocols already implemented in T335325. Of course, if there are particular ones you think ought to be supported, we'd value you naming them and sharing why on the talk page, as Snævar, Bawolff, Nikki, and Pietrasagh have started doing. Please note: protocol support is a notably fragile part of the Graph Extension. If/when we come to learn this facet of the extension is causing problems, we might need to disable protocol support.
3. How much time – if any – will elapse between the Graph Extension being re-enabled with support for Vega 5 and support for Vega 2 being discontinued? In short, we do not yet know when support for Vega 2 will be discontinued. This is a timeline we (staff + volunteers) will need to define together. With the above said, here is what we are certain about at it relates to Vega 2 and Vega 5 support:
   1. Being able to provide guidance about when Vega 2 support will be discontinued depends on us first learning how the migration to Vega 5 is going.
   2. Non prevediamo di supportare i grafici Vega 2 a tempo indeterminato
4. What can we do to preserve graphs that have not/can not be converted from Vega 2 to Vega 5? Converting graphs of this sort on a server that allows sandboxed rendering exposes security vulnerabilities the current approach is meant to mitigate. More details in T334940#9161842. With the above said, we estimate the graphs that have not/cannot be ported from Vega 2 to Vega 5 to be relatively small and comprised of:
   1. Grafici che utilizzano un protocollo personalizzato (ad esempio Wikimedia API o WDQS) non sono supportati dall'approccio iFrame in modalità sandbox.
   2. Grafici che possono essere trasferiti, ma nessuno ha intrapreso il lavoro per farlo.
5. Perché pensiamo che valga la pena migrare da Vega 2 a Vega 5?
   1. Vega 2 è stata sostituita da Vega 3, 4, poi 5 a monte. La documentazione upstream e di terze parti si riferisce esclusivamente alla sintassi in "Vega versione 3.0 e successive" ed è difficile per i nuovi contributori trovare documentazione pertinente a Vega 2. L'ultima versione upstream (correzione di bug o sicurezza) di Vega 2.x risale a gennaio 2017. Vega 5 è stata rilasciata a marzo 2019 ed è ancora in fase di manutenzione e sviluppo attivi, con l'ultima versione 5.25.0 uscita nell'aprile 2023.
   2. I volontari hanno segnalato problemi con l'accessibilità, la sintassi e la funzionalità generale di Vega 2, secondo questo desiderio del 2023.
   3. Vega 5 has made improvements to the library's expression layer that harden it from a security perspective compared to Vega 2.  It is not perfect, but by introducing a parsed expression grammar it offers a more robust foundation for additional security hardening in the future if it proves necessary.
   4. Maintaining multiple versions of Vega concurrently is unsustainable in the long run. The wiki community is taxed in the attempt to independently support software which is not being maintained upstream. Our efforts are best spent working in cooperation with upstream and third-party developers, and to do this we need to be working from the upstream Vega 5 code base.
6. Cosa potrebbe essere necessario per migrare i grafici da Vega 2 a Vega 5?
   1. Creare un convertitore che migrerebbe i grafici basati su Vega 2 per renderli compatibili con Vega 5. @Jdlrobson ha iniziato a lavorare su un approccio iniziale in T335048#8794138. Il lavoro iniziale necessita di essere leggermente ristrutturato per focalizzarlo nuovamente sull'aiuto al porting manuale, invece del traduttore automatico che era il suo obiettivo originale. Nota: stimiamo che questo convertitore attualmente funzioni per circa l'80% dei grafici, con rendimenti decrescenti su ulteriori sforzi ingegneristici per coprirne di più. Non abbiamo intenzione di continuare a investire significative risorse ingegneristiche aggiuntive qui, ma invece di riutilizzare semplicemente la base di codice esistente come aiuto per il porting manuale.
   2. I volontari dovrebbero aggiornare la sintassi di <graph> caso per caso, aiutati (1) dalla capacità di eseguire le specifiche Vega 2 esistenti e la nuova Vega 5 fianco a fianco, (2) dalla versione parziale di Vega2-to-5 che gestisce l'80% delle modifiche "ovvie" alle parole chiave e altre conversioni meccaniche, (3) dalla guida al porting di Vega2 upstream e (4) ddalla ocumentazione o dagli strumenti aggiuntivi che potrebbero essere creati dalla comunità wiki.
   3. Update the limited number of Scribunto templates on-wiki which generate <graph> output in Vega 2 format to instead output Vega 5.  This requires both lua and Vega expertise, but fixes a larger number of Vega 2 uses on wiki at once.

Proposte

Per ripristinare in modo sicuro l'accesso alle informazioni e alle funzionalità che la disattivazione dell'estensione Graph ha lasciato le persone senza e promuovere la collaborazione tra volontari e personale necessaria per farlo, noi (il WMF) ci impegniamo a:

Riattivare l'estensione Graph in un iFrame sandbox con una politica di sicurezza dei contenuti restrittiva.

1. Una volta riattivata, l'Estensione Graph continuerà a funzionare con Vega 2 per un periodo di tempo ancora da definire. Nota: dovremo definire insieme questa finestra.
   1. Dopo questo "periodo di tempo ancora da definire", il supporto di Vega 2 verrà interrotto e l'uso dell'Estensione Graph richiederà ai volontari di creare grafici con Vega 5.
   2. Non appena possibile, rendi disponibile l'Estensione Graph in modalità sandbox nel cluster beta per il test. Vedi: T346292.
2. Investigate the viability of adding logging to increase our awareness of instances where people are exploiting the security vulnerabilities inherent with restoring support for Vega on our platform. See T346414.
3. Publish the technical documentation needed for developers across the Movement to understand how we implemented the sandboxed CSP approach
4. Pubblicare una tempistica chiara per quando tutti voi potrete aspettarvi che tutto ciò accada
5. Nota: è iniziato il lavoro esplorativo per ridistribuire l'Estensione Graph in un iframe sandbox. Vedi T222807.
6. Condivisione aggiornamenti regolari sui progressi che stiamo facendo rispetto agli impegni sopra menzionati su Phabricator e MediaWiki.
7. Supporta i volontari con codice e processi che faciliteranno la transizione da Vega 2 a Vega 5 quando arriverà il momento di questa transizione.

A sostegno di quanto detto sopra, dovremmo dipendere da voi (volontari) per:

1. Diffondere la consapevolezza di questa proposta e degli aggiornamenti che arriveranno quando inizieremo l'implementazione, supponendo che questa proposta vada avanti.
2. Migrare manualmente una parte dei grafici basati su Vega 2 per renderli compatibili con Vega 5. Vedi le "domande 5 e 6 nella sezione FAQ".
3. Potenzialmente, correggere/portare i grafici che hanno tentato di recuperare dati in tempo reale utilizzando metodi che l'approccio sandboxing inibisce.
   1. Nota: la necessità di quanto sopra diventerà chiara una volta che decideremo se ripristinare gli pseudo-protocolli utilizzati per recuperare i dati in tempo reale dall'API dell'azione, dall'API REST, WDQS ecc. e i parametri precisi del sandbox che selezioniamo (domini/porte/http consentiti). Questa decisione verrà presa in T346291.

Ricerca

La ricerca che ha dato vita alla proposta per ripristinare in modo sicuro l'accesso alle informazioni e alle funzionalità che la disattivazione delll'estensione Graph ha lasciato le persone senza può essere trovata qui .