Abstraktní Wikipedie/Aktualizace/2023-02-08

Aktualizace Abstraktní Wikipedie

Další myšlenky ke zpráva od kolegů z Google.org

Během stáže získali stipendisté Google.org podrobný vhled do projektu Wikifunkcí a Abstraktní Wikipedie. S cílem poukázat na možné problémy a diskutovat o možných alternativách některých přístupů projektu sepsali podrobné hodnocení projektů Wikifunctions a Abstract Wikipedia. Tým si hodnocení přečetl a napsal důkladnou odpověď. V prosinci jsme zveřejnili kompletní dokumenty:

O hodnocení informoval magazín The Signpost a mimo jiné se o něm diskutovalo v jednom z dílů podcastu Between the Brackets. Dnes chceme poskytnout zhuštěné a nepříliš odborné shrnutí textů. Dokumenty byly dlouhé a technické. Chápeme, že dvoustránkové shrnutí čtyřicetistránkové diskuse bude zjednodušené a přehlédne mnoho potřebných drobností, ale pro všechny, kteří se chtějí ponořit do detailů, jsou k dispozici celé dokumenty.

V hodnocení je popsáno mnoho návrhů a podnětů na změnu projektu a jeho závěrem je osm rozsáhlých doporučení. Velkou část návrhů z hodnocení jsme přijali. Některé z nich již byly realizovány, jiné jsou úkoly na naší projektové radě a čekají na realizaci.

Hlavní sporné body se týkají závěrečných osmi doporučení. Souhrnně lze říci, že doporučení navrhují, aby Nadace považovala Wikifunkce a Abstraktní Wikipedii za samostatné projekty. Dále doporučují výrazně zúžit rozsah obou projektů.

Hodnocení pro Wikifunkce doporučuje upustit od funkčního modelu, na kterém stojí naše vícejazyčné uživatelské rozhraní. Dále doporučují omezit postupy, které umožňují přidávat funkce i osobám, které nejsou vývojáři, a zaměřit se na jediný programovací jazyk Lua namísto toho, aby bylo možné používat více jazyků.

V případě Abstraktní Wikipedie hodnocení doporučuje upustit od myšlenky spoluvytvářet s komunitou jedno nebo více řešení pro generování přirozeného jazyka a navrhuje vybrat buď existující systém pro generování přirozeného jazyka, nebo přijmout systém, který uvedl jeden ze stipendistů během stipendia. Namísto vytvoření univerzálního úložiště funkcí, které by komunitě umožnilo experimentovat a vyvíjet řešení, se doporučuje, aby projektový tým rozhodl a natvrdo vytvořil jediné řešení, které by bylo systémem vně wiki integrujícím příspěvky redaktorů.

To se podobá raným kritikám Wikidat, která čelila velmi podobnému návrhu: mnoho hlasů prohlašovalo, že rozhodnutí umožnit komunitě vytvořit a udržovat ontologii Wikidat, namísto výběru existující ontologie nebo najmutí týmu ontologů, by Wikidata odsoudilo k zániku. Kvůli setrvání na tomto rozhodnutí jsme přišli o některé významné finanční prostředky.

Vývojový tým Abstraktní Wikipedie a Wikifunkcí odmítl obě sady doporučení.

Jedním z hlavních důvodů zamítnutí některých bodů bylo to, že hodnocení skutečně hodnotilo "technický plán", a nikoliv současný stav vývoje. Například jedno z doporučení je zaměřit se výhradně na jazyk Lua namísto povolení různých programovacích jazyků, protože implementace druhého z nich by trvala dlouho. Ale vzhledem k tomu, že jsme tuto funkci již implementovali, přijetí doporučení by nás zpomalilo a museli bychom zahodit již vykonanou práci.

Některá doporučení byla zamítnuta na základě hodnot Wikimedia. Považujeme za zásadní mít projekt, do kterého mohou lidé přispívat a který mohou používat ve svém vlastním přirozeném jazyce. Považujeme za důležité umožnit přispívat i neprogramátorům, a to nejen kvůli rozmanitosti, ale také jednoduše proto, že v mnoha jazykových komunitách je okruh potenciálních přispěvatelů s příslušnými dovednostmi velmi omezený. Potřebujeme lidi, kteří budou vytvářet a udržovat funkce pro generování přirozených jazyků v mnoha jazycích. Umožnění přispívat širšímu souboru dovedností toto potenciální úzké místo snižuje. Proto Abstraktní Wikipedie potřebuje Wikifunkce a zároveň Wikifunkce těží z Abstraktní Wikipedie jako případu užití. Je to symbiotický vztah.

V současné době neexistuje žádný symbolický systém generování přirozených jazyků, který by pokrýval 300 jazyků, jak to již dělá hnutí Wikimedia. Nemůžeme s jistotou zvolit existující řešení, ani nové řešení vyvinuté během stáže. Ve skutečnosti se do vývoje Abstraktní Wikipedie zapojila jako dobrovolnice profesorka Maria Keetová z univerzity v Kapském Městě v Jihoafrické republice. Kritizovala jak stávající populární systémy pro generování přirozených jazyků, tak i ten, který byl vytvořen během stáže, protože by s jazyky Niger Congo B nefungovaly dobře. Návrh stážistů byl aktualizován tak, aby lépe podporoval potřeby těchto jazyků. To se nám podařilo, protože naše architektura není úzce svázána s externím systémem generování přirozených jazyků.

Nevíme a většinou ani nemůžeme vědět, zda dosud neimplementované jazyky mají vlastnosti, které by se pro daný systém staly zásadním problémem. V univerzálním, flexibilním systému bude mít komunita pravomoc takový problém vyřešit. Výběrem jakéhokoli jediného řešení bychom výrazně zvýšili bariéru pro nápravu problémů. Místo přispívání do wiki bychom potřebovali, aby vývojáři přispívali jinam, např. v případě SimpleNLG do upstreamového projektu v Javě přes git nebo v případě Grammatical Framework do projektu napsaného v Haskellu. A co je nejhorší, komunitami, které by takové rozhodnutí nejspíše negativně ovlivnilo, by byly ty, které jsou již nyní nedostatečně zastoupeny.

Nejsme proti použití stávajícího systému pro generování přirozeného jazyka. Budeme podporovat a již podporujeme komunitu ve využívání existujících řešení (úzce spolupracujeme s Grammatical Framework, který je kolegy doporučován). V tuto chvíli se však nebudeme zavazovat výhradně k některému z existujících řešení. Místo toho bylo od počátku v plánu umožnit komunitě vytvářet, udržovat a vlastnit své přístupy, umožnit komunitě využívat a kombinovat dostupná řešení a společně s komunitou abstraktní Wikipedii spoluvytvářet.

Doufáme, že toto shrnutí osmi doporučení a našeho rozhodnutí pomůže pochopit, co budujeme a proč jsme se tak rozhodli.

Jaký je dobrý název pro proces, který je třeba zlepšit?

Python má PEP (Python Enhancement Proposal), Java JSR (Java Specification Request) a mnoho wiki má RfC (Request for Comment, Žádost o komentář, inspirováno IETF) nebo podobné termíny. Wikifunkce se budou zdokonalovat i po svém spuštění a my budeme potřebovat proces pro diskusi o těchto vylepšeních, ať už na wiki, v mailing listu nebo v Phabricatoru. Tento proces potřebuje jméno!

Nebudeme dělat žádné velké hlasování, ale rádi bychom vás požádali o nápady na název a o to, zda máte nějaké preference nebo obavy. Některé interní návrhy byly

Community System Change (CSC, volně Komunitní systémová změna)
Little Lambda chat (LLC, volně Malá Lambda diskuze)
Food for thought (FFT, volně Podnět k zamyšlení)
Wikifunctions Lambda Delta (WILD, volně Wikifunkce Lambda Delta)
Wikifunctions System Consultation (WSC, volně Konzultace systému Wikifunkcí)
Functional Model Proposal (FMP, volně Návrh funkčního modelu)

Máte-li také návrhy, jak proces změn formálního modelu Wikifunkcí zpočátku spustit a strukturovat, dejte nám vědět. Očekáváme, že se to v průběhu času výrazně změní, ale pravděpodobně máme dostatek zkušeností, ze kterých můžeme vycházet.

Týdenní aktualizace vývoje pro 3. února 2023

Minulý týden jsme měli dvouměsíční fix-it týden, což je týden bez schůzek zaměřený na opravu chyb a splácení technického dluhu. Mezi příklady vykonané práce patří:

Oprava drobných chyb, např. oprava problému s fixWidth nebo odstranění zbytečných kontrol
Zlepšení pokrytí testy, např. v serializéru nebo v komponentě řetězce, nebo opětovné zapnutí dočasně vypnutých testů, např. pro mapování prázdných seznamů
Přejmenování komponent a funkcí, aby byly přehlednější a konzistentnější, např. přejmenování 'obecná chyba' na 'nespecifikovaná chyba' nebo přidání prefixu pro komponenty.
Refaktoring, např. restrukturování kompletních adresářů, sjednocení dialogových oken metadat do jediné komponenty nebo zobecnění stávajících funkcí
Nahrazení komponent modernějšími komponenty, např. našeho vlastního 'čipu' tím z Codexu