Wikipedia:Gemenskapens tekniska önskelista

Välkommen till Gemenskapens tekniska önskelista 2018!

Tack för att du deltar!

Kalender

• Lägg, diskutera och bearbeta förslag
  • måndag 3 september – måndag 17 september Klar
• Wikimedia Sveriges team går igenom och organiserar förslag
  • tisdag 18 september – torsdag 20 september Klar
• Rösta på förslagen
  • fredag 21 september – måndag 8 oktober Klar
• Analysera önskelista
  • tisdag 9 oktober Klar
• Resultat presenteras
  • onsdag 10 oktober Klar
• Wikimedia Sveriges team går igenom och utvärderar de mest populära önskningarna
  • onsdag 10 oktober – tisdag 16 oktober Klar
• Presentation av den preliminära utvärderingen
  • onsdag 17 oktober Klar
• Arbete med önskemålen
  • från torsdag 1 november

Vad är Gemenskapens tekniska önskelista?

Wikimedia Sverige vill hjälpa de mest aktiva volontärerna med att lösa tekniska problem som förhindrat ett effektivt arbete. Den utveckling vi fokuserar på i det här projektet beslutas och prioriteras av Wikimedia-gemenskapen, genom denna önskelista. 2017 var första gången vi genomförde detta projekt (se förra årets önskelista), då vi jobbade med att aktivera verktyg som underlättar klottersanering och med att gör det lättare att lägga till källor för webbsidor. Även detta år kommer projektet att vara av ett mindre slag med fokus på att lösa mindre tekniska problem. Detta på grund av vår personalstyrkas begränsade storlek, samt att önskningar från förra året tagit tid under 2018 p.g.a. externa förseningar.

En gång per år ber vi Wikimedia-volontärer att bidra med förslag på tekniska problem som behöver fixas eller nya lösningar som behöver utvecklas och som vårt team bör arbeta med. Efter att vi samlat in förslag under två veckor så är du inbjuden till att rösta på den idé som du är mest intresserad av att se genomförd. Det förslag med flest stödröster blir då vår topprioritet och vi kommer att undersöka dess genomförbarhet.

Idén med Gemenskapens tekniska önskelista togs först fram av Wikimedia Deutschland och vidareutvecklades av Wikimedia Foundation. Vi följer i deras spår med en önskelista för den svenskspråkiga Wikipedia-gemenskapen.

Vad händer under förslagsfasen?

Förslagsfasen pågår de första två veckorna av undersökningen: från måndag 3 september till måndag 17 september.

I förslagsfasen uppmanas bidragsgivare att lämna förslag om funktioner och korrigeringar som de vill se under 2018/2019. Förslag kan lämnas på svenska eller engelska.

Förslagen bör vara avskilda, väldefinierade uppgifter som direkt kommer att gynna aktiva Wikimedia-bidragsgivare. När förslagsfasen öppnas kommer vi att ha ett formulär att fylla i, med följande frågor:

• Vad är problemet du vill lösa?
• Hur hanteras problemet nu?
• Vilka användare påverkas? Wikipedias läsare, bidragsgivare – nybörjare eller erfarna, administratörer, o.s.v. Tänk på att Wikipedias systerprojekt inte omfattas av det här projektet.
• Vilka är de föreslagna lösningarna? (Om det finns någon idé)

Ditt förslag bör vara så specifik som möjligt, särskilt i problemformuleringen. Skriv inte bara att "(x-funktionen) är föråldrad", "måste förbättras" eller "har en hel del buggar"; det är inte tillräckligt med information för att räkna ut vad som behöver göras. Ett bra förslag förklarar exakt vad problemet är, och vem som påverkas av det. Det är okej om du inte har en specifik lösning att föreslå, eller om du har några möjliga lösningar och du inte vet vilken som är bäst. Önskningar från 2017 kan önskas igen, länka gärna till förra årets diskussion, men kolla om förutsättningarna har ändrats sedan sist.

Att lägga fram ett förslag är bara början av processen. Den två veckor långa förslagsfasen är en möjlighet för gemenskapen att tillsammans utarbeta ett förslag som presenterar idén på ett sätt som mest sannolikt kan bli framgångsrikt i omröstningsfasen. När ett förslag lämnas in är alla inbjudna att kommentera på detta förslag, och bidra till att göra det bättre genom att ställa frågor, och föreslå förändringar. Förslag som är dubbletter kan slås samman; mycket breda förslag bör delas upp i mer specifika idéer. Målet är att skapa bästa möjliga förslag till omröstningsfasen.

Den person som lägger fram ett förslag bör räkna med att vara aktiv i den diskussionen, och bidra till att göra förändringar längs vägen. På grund av detta kommer vi att begränsa förslag till tre stycken per person. Om du lägger mer än tre förslag, kommer vi att be dig att välja tre. Presentera dina bästa idéer!

Tänk på att förslag som går ut på att ta bort eller inaktivera en funktion som ett produktteam på WMF har arbetat med är utanför våra möjligheter att påverka. De kommer därför inte att inkluderas i omröstningsfasen.

Vad händer under omröstningsfasen?

Efter ett par dagars uppehåll pågår omröstningsfasen under den efterföljande veckan: från fredag 21 september till fredag 28 september.

Alla aktiva bidragsgivare uppmanas att granska och rösta för de förslag som de vill stödja. Du kan rösta på så många olika förslag som du vill. Du måste vara inloggad för att lägga en stödjande röst. De enda röster som räknas är stödröster; den slutliga listan av önskemål rangordnas efter de som fått flest stödröster.

Livlig diskussion uppmuntras dock under omröstningsfasen, och om du vill lägga till en röst som motsätter sig eller som är neutral med en kommentar, så är du välkommen att göra så. Dessa diskussioner kan hjälpa andra att besluta huruvida de vill rösta på förslagen. Diskussionerna ger också värdefulla bidrag för att styra det arbete som kommer att ske under året.

En rimlig mängd av påverkan är acceptabel. Du har en möjlighet att sälja din idé till så många människor som du kan nå. Känn dig fri att kontakta andra personer i ditt projekt, Wikiprojekt eller användargrupp. Självklart ska detta inte innefatta marionettkonton, och du får inte trakassera folk om att rösta eller att ändra sin röst. Men en välmenande kampanj om att "få folk att rösta" är helt okej.

Vad händer om en massa människor röstat och stött en dålig idé?

Stödröstrankningen skapar en prioriterad lista av önskningar och Wikimedia Sveriges team är ansvariga för att utvärdera och ta itu med de önskemål som är högst prioriterade. För att göra det undersöker vi alla de högst rankade önskemålen, och tittar på både tekniska och sociala riskfaktorer.

De röster som motsätter sig eller är neutrala är till stor hjälp i att peka på potentiella nackdelar. För kontroversiella önskemål balanserar vi röstning med en mer konsensusbaserad granskning.

Önskelista

Automatiserad artikelförbättringsbedömning

Problem

När nya användare, speciellt på skrivstugor, börjar skriva kan det vara svårt för dem att bedöma hur mycket bättre en artikel blir. Ett pilotprojekt har gjorts på engelska Wikipedia med goda resultat som visar att skribenterna blir motiverade samtidigt som kvaliteten på artiklarna höjs.

Vilka påverkas

Alla som deltar i skrivstugor, går kurser i Wikipedia och även användare som har redigerat en liten stund.

Tidigare diskussioner

Inga jag känner till.

Lösningsförslag

Se till att den automatiserade artikelkvalitetsbedömningen (ORES articlequality) aktiveras på svenska Wikipedia (se phab:T202202). Gör en finess som vid sparandet av en artikel för användaren visar hur mycket bättre artikeln har blivit i verktygets kvalitetsbedömning (det vill säga skillnaden i artikelkvalitet på den nyss sparade sidversionen och den föregående). Finessen är antagligen enkel att kopiera till andra språkversioner med kvalitetsbedömning, så arbetet skalar väl.

Föreslaget av

♥Ainali ^diskussion_bidrag 3 september 2018 kl. 22.50 (CEST)

Diskussion

Låter vettigt, kan säkert peppa både nya och gamla användare! Mickeno (diskussion) 4 september 2018 kl. 14.24 (CEST)

Låter intressant och det finns ju inga risker, så bra att införa och prova.Yger (diskussion) 4 september 2018 kl. 17.30 (CEST)

Ett par frågor angående finessen: finns det något liknande sedan tidigare, kanske på någon annan språkversion? När ska indikationen visas, före eller efter sidan har sparats? /Sebastian Berlin (WMSE) (diskussion) 19 september 2018 kl. 15.47 (CEST)

Nej, jag har inte sett detta någon annanstans. Den kan inte visas innan sparandet eftersom att API:et kräver sidversionen som ett in-värde. ♥Ainali ^diskussion_bidrag 19 september 2018 kl. 17.43 (CEST)

Tack, då vet vi. En sak till som vi vill förtydliga angående det här förslaget är att WMF kommer att sköta de tekniska bitar som behövs för att slå på funktionen i ORES (om förslaget blir framröstat). Vi kommer att bistå med att kommunicera med WMF, i den mån detta kräver teknisk kunskap. /Sebastian Berlin (WMSE) (diskussion) 20 september 2018 kl. 14.20 (CEST)

Se även ett liknande verktyg "Article Finder tool" på wikiedu.org, som visar en artikels "completeness" och kvalitet "When you search a keyword, you'll see a list of relevant articles. You can filter the results by quality,..."

https://dashboard.wikiedu.org/training/instructors/finding-articles/article-finder StenS (diskussion) 2 oktober 2018 kl. 13.07 (CEST)

Omröstning

1. ♥Ainali ^diskussion_bidrag 21 september 2018 kl. 00.01 (CEST)
2. Deryni (diskussion) 2 oktober 2018 kl. 19.35 (CEST)
3. --Allexim (diskussion) 7 oktober 2018 kl. 12.48 (CEST)

Automatkonvertera källhänvisningar som enbart består av URL:er

Problem

Samma problem som förra omgången :-)

Vilka påverkas

Samma som förra omgången :-)

Tidigare diskussioner

Förra omgången

Lösningsförslag

Uppenbarligen något i Citoid, men jag förstår inte hur det går till, så det överlämnar jag till utvecklarna

Föreslaget av

Samma som förra omgången, d.v.s. Hannibal (diskussion) 4 september 2018 kl. 13.48 (CEST)

Diskussion

Detta kanske till och med är enklare att genomföra nu när det redan finns konvertering av enstaka URL:er till källmall. Eventuellt finns det någon underliggande funktion som bara behöver anropas ett antal gånger och så är det klart. Om inte annat så finns det i alla fall kod att kopiera någonstans. ♥Ainali ^diskussion_bidrag 4 september 2018 kl. 20.49 (CEST)

Det stämmer att det nu har implementerats kod för att konvertera URL:er från några svenska webbsajter. Det kvarstår dock problem med programvaran som kör hos WMF och nya uppdateringar kommer inte att träda i kraft innan de är lösta. Även om URL:er kan konverteras till mallar kommer vissa värden vara fel. Dessa kommer inte sedan kunna hitta med samma logik eftersom de inte längre är rena URL:er. /Sebastian Berlin (WMSE) (diskussion) 19 september 2018 kl. 15.47 (CEST)

Har någon gjort statistik (t.ex. utifrån en databasdump) över hur många sådana hänvisningar som finns? Det känns som ett så generellt och grundläggande problem, att en lösning borde gå att tillämpa på samtliga språk av Wikipedia. När man har den fullständiga listan över alla URLer som behöver snyggas upp, så kan man gruppera dem per sajt och se om det finns mallar för de vanligaste sajterna (t.ex. IMDb, Projekt Runeberg, etc.). --LA2 (diskussion) 1 oktober 2018 kl. 21.20 (CEST)

@LA2: Vi har tagit fram statistik över webbadresser. Den omfattar visserligen _alla_ url:er inom ref-taggar, alltså både råa och inom källmallar, men den kan kan ge en hänvisning om vilka sidor som är populära. --Alicia Fagerving (WMSE) (diskussion) 2 oktober 2018 kl. 10.40 (CEST)

Omröstning

1. ♥Ainali ^diskussion_bidrag 21 september 2018 kl. 00.01 (CEST)

Hjälp för nybörjare att hitta lediga användarnamn

Problem

När nya användare ska skapa sina konton (vilket händer regelbundet på skrivstugor), blir de ibland tvungna att ägna ganska mycket tid åt att hitta ett ledigt namn. Det orsakar stress för dem och ger en dålig bild av Wikipedia (är det fullt? hur outvecklad är tekniken?).

Vilka påverkas

Såväl nykomlingar som skrivstugeanordnare. (De flesta veteraner tänker antagligen inte på problemet.)

Tidigare diskussioner

? (Jag har för mig att Fluff skrev någon finess som berättade att kontot var upptaget redan innan man fyllt i alla fält och klickat Skapa konto och sen fick tillbaka formuläret tömt, men nu minns jag inte om den inte fungerade eller så, för senaste gångerna jag har testat har det inte fungerat.)

Lösningsförslag

En funktion som föreslår alternativa namn om det namn som man försöker skapa är upptaget, inte baserat på siffror, utan på alternativa ord, eller till och med en slumpfunktion som man kan välja om namnet inte är så viktigt.

Föreslaget av

Hannibal (diskussion) 4 september 2018 kl. 13.48 (CEST)

Diskussion

Ja, jag skrev det för nio år sedan tydligen... Användare:Fluff/cfau.js har inte underhållits sedan dess. /^Fluff?_Fluff! 5 september 2018 kl. 10.30 (CEST)

Denna funktionalitet är nu inbyggd i Special:Skapa konto. Skriver man in ett användarnamn som redan finns, eller ett som är tillräckligt likt ett som redan finns, får man ett meddelande om detta. Det går heller inte att köra finesser på Special:Skapa konto. /Sebastian Berlin (WMSE) (diskussion) 19 september 2018 kl. 15.47 (CEST)

För att förtydliga. Den kvarstående delen av önskan är således att kunna ge förslag på alternativa användarnamn. Att det inte går att köra finesser på Special:Skapa konto innebär att en lösningen måste implementeras direkt i MediaWiki och således måste fungera oavsett språk eller skriftsystem. /André Costa (WMSE) (diskussion) 24 september 2018 kl. 15.34 (CEST)

Kartor i infoboxar

Problem

Det är idag ganska krångligt att lägga till de nya sorters kartorna (de zoom- och panorerbara, möjliga tack vara mw:Extension:Kartographer) i infoboxar. Därför har vi knappt några sådana alls på svenska Wikipedia.

Vilka påverkas

Alla läsare av geografirelaterade artiklar får en rikare upplevelse. Wikipedianer som redigerar dessa får en sak mindre att göra.

Tidigare diskussioner

Wikipedia:Bybrunnen/Arkiv_2017-08#Förslag:_Interaktiva_kartor_som_standardinställning

Lösningsförslag

Bland annat baskiska Wikipedia har bra moduler som skulle kunna importeras och implementeras i någon av de vanligaste infoboxarna. Detta skulle också lösa de farhågor som fanns i den tidigare diskussionen (då de inte dyker upp som en "extra" karta).

Föreslaget av

♥Ainali ^diskussion_bidrag 17 september 2018 kl. 20.20 (CEST)

Omröstning

1. ♥Ainali ^diskussion_bidrag 21 september 2018 kl. 00.01 (CEST)
2. VisbyStar (diskussion) 1 oktober 2018 kl. 21.23 (CEST)
3. Deryni (diskussion) 2 oktober 2018 kl. 19.35 (CEST)
4. ℇsquilo 9 oktober 2018 kl. 11.07 (CEST)

Vitlista för filtrering av "Senaste ändringar"

Problem

Sidan "Senaste ändringar", även om man använder "den nya och förbättrade versionen" med egna filter, dränks stundtals av frekventa, men seriösa, bidrag av betrodda användare vilket gör att misstänkta klotterredigeringar riskerar att försvinna.

Vilka påverkas

Alla som vill använda sidan "Senaste ändringar".

Tidigare diskussioner

Wikipediadiskussion:Gemenskapens_tekniska_önskelista#Återkoppling_om_första_önskelistan

Lösningsförslag

Inför möjligheten till filter där redigeringar av de användare som anges på en personlig "vitlista" kan hanteras på samma sätt som man kan hantera robotredigeringar, till exempel exkluderas från ändringslistan. Det bör helst gå att ha olika vitlistor för olika egendefinierade filter.

Föreslaget av

--Larske (diskussion) 17 september 2018 kl. 23.35 (CEST)

adopterad av Yger (diskussion) 18 september 2018 kl. 08.54 (CEST)(för att inte överfylla Larskes kvot om tre förslag)

Diskussion

Det här finns redan på Wikipedia:Senaste ändringar/EventStreams. Nirmos (diskussion) 18 september 2018 kl. 14.39 (CEST)

Ja, det du refererar till är väl samma som det jag kallade för finessen "Automatuppdaterad SÄ" i mitt inlägg i ovan länkade "Tidigare diskussioner". Den finessen använder jag "hela tiden" och det är precis den funktionaliteten som jag vill ska inkluderas i "den nya filterbaserade SÄ", alltså den funktionen som erbjuder en möjlighet att definiera en massa egna filter och färgmarkeringar. --Larske (diskussion) 18 september 2018 kl. 20.20 (CEST)

Larske: Jag såg den diskussionen efter det att jag hade skrivit mitt inlägg här. Sorry.

Jag kan försöka förklara problemet med att filtrera bort användare på vanliga SÄ. Om man på vanliga SÄ skulle dölja användare efter det att HTML:n har lagts till på sidan, så blir det ingen automatisk "påfyllning" med redigeringar. Exempelscenario: Du begär 50 handlingar. Du har dolt Nirmos. Nirmos står för de senaste 50 handlingarna. Då skulle du se 0 handlingar på SÄ.

MediaWiki:Gadget-RecentChangesStream.js (som visas på Wikipedia:Senaste ändringar/Flöde) har korrekt påfyllning om du väljer att exkludera exakt 1 användare, eftersom MediaWikis API har naturligt stöd för det (rcexcludeuser). Om du exkluderar fler än 1 med den finessen, så blir det samma dumma beteende som jag beskrev ovan.

MediaWiki:Gadget-EventStreams.js (som visas på Wikipedia:Senaste ändringar/EventStreams) har inte det här problemet eftersom HTML:n läggs till i realtid allteftersom nya event droppar in, och i och med det kan man öht inte begära de 50 senaste handlingarna.

Med allt det sagt: Om det som jag kallar "det dumma beteendet" trots allt är acceptabelt (eller bättre än ingenting alls) så går det att skapa en finess som på vanliga SÄ tillåter döljning av användare. Nirmos (diskussion) 18 september 2018 kl. 22.06 (CEST)

SÄ-funktionen behöver inte först begränsa sig till 50 redigeringar och sedan filtrera bort redigeringar från angivna användare. Funktionen har tillgång till hela SÄ och kan väl ta till med råge och "läsa in" till exempel 500 redigeringar och därefter filtrera bort redigeringar från angivna användare och till sist filtrera bort allt utom de 50 senaste om det nu är 50 redigeringar man vill se i sin filtrerade SÄ. (Själv har jag inställningen "500 ändringar och 30 dagar", det vill säga max vad som går.) Det är väl så den hanterar alla andra filtreringar som görs på "bidragskvalitet", "användaravsikter", "användarerfarenhet", "typ av ändring" och så vidare.

Visst kan man bygga ett js-ryggsäcksfilter "uppepå" standard SÄ-funktionen och det är kanske där vi hamnar, åtminstone som en temporär finess, men det bästa vore väl om funktionen att filtrera på användare kunde integreras i standard SÄ-funktionen. Skillnaden är väl att ryggsäcken/finessen svänger du ihop på några timmar medan ett tillägg i standardfunktionen antagligen tar "many moons". --Larske (diskussion) 18 september 2018 kl. 22.45 (CEST)

Efter en första koll av detta är det möjligt att denna önskan är för omfattande för oss på WMSE. Vi får undersöka detta närmre om den blir framröstad. /Sebastian Berlin (WMSE) (diskussion) 19 september 2018 kl. 15.47 (CEST)

Yger, Larske: Det verkar inte som att det här blev valt, så jag skapade en finess för det här. För att använda den:

1. Gå till Special:Inställningar#mw-prefsection-gadgets
2. Skrolla till rubriken "Senaste ändringar"
3. Kryssa i "Lägg till en knapp i övre högra hörnet på ändringslistor som tillåter användare att dölja handlingar från användare de litar på."
4. Klicka på "Spara"
5. Gå till valfri ChangesList (alltså Special:Senaste ändringar, Special:Senaste relaterade ändringar eller Special:Bevakningslista)
6. Klicka på "Dölj användare" uppe i högra hörnet
7. Mata in ett eller flera användarnamn, separerat med radbrytning, till exempel

   Yger
   Larske
   Nirmos
   

8. Klicka var som helst utanför rutan för att stänga den

Nirmos (diskussion) 18 oktober 2018 kl. 05.12 (CEST)

@Nirmos:  Perfekt! Jag såg i natt att du höll på med denna finess och har nu provat den lite. Den uppfyller helt mina förväntningar! --Larske (diskussion) 18 oktober 2018 kl. 07.38 (CEST)

@Nirmos: Knappen "Dölj användare" fungerar utmärkt och är mycket nyttig till exempel just nu när SÄ annars dränks av artikelraderingar. Jag kom just på att det skulle vara ännu smidigare om det fanns en liten knapp på varje rad i ändringslistan, i närheten av användarnamnet eller IP-adressen, kanske sist i eller omedelbart efter, "mw-usertoollinks", som gjorde så att just den användaren adderades till "vitlistan", det vill säga utan att man behöver öppna någon dialogruta och lägga till användarnamnet på listan. Den vanliga knappen för "Dölj användare" uppe till höger måste såklart finnas kvar eftersom den behövs när man vill ta bort någon från listan. --Larske (diskussion) 22 oktober 2018 kl. 22.54 (CEST)

Ganska mycket ett sidospår, men är det inte en svartlista snarare än en vitlista? ♥Ainali ^diskussion_bidrag 23 oktober 2018 kl. 18.29 (CEST)

Funktionalitet för att skapa "interaktiva kurser/guidad tur" för nybörjare och klottrare

Problem

Som komplement till mallen {{Nybörjare}}, som jag tror kan upplevas som lite för "mastig", skulle det vara bra om man, på ett lustfyllt sätt, kunde "tvingas" gå igenom vissa moment/övningar innan man får redigera på Wikipedia.

Vilka påverkas

Alla nybörjare. Alla klottrare.

Tidigare diskussioner

Känner inte till om detta har diskuterats tidigare.

Lösningsförslag

Inför möjligheten att skapa en "snitslad bana" genom ett antal "frågesidor" där man måste "svara rätt" på ett antal frågor för att komma vidare. Det kan vara allt från en sida till många sidor och det kan vara "flervalsfrågor" eller frågor som ska besvaras med en viss text. Belöningen när man lyckats ta sig igenom denna bana kan vara att man tilldelas behörigheten att redigera på Wikipedia eller att man kan få begära att bli avblockerad om man har blivit blockerad för till exempel klotter/vandalism. Innan man svarat rätt på frågorna är mallen {{avblockering}} verkningslös.

Vi kan skapa olika banor för helt olika "use cases" och det är nog bara fantasin som begränsar vad en sådan funktion skulle kunna användas till om den görs tillräckligt "generell".

Föreslaget av

--Larske (diskussion) 17 september 2018 kl. 23.35 (CEST)

Diskussion

mw:Extension:GuidedTour är redan aktiverad på den här wikin. Ett stort icke-tekniskt jobb som hör ihop med det här är dock att först tala om vad turen ska innehålla och i vilken ordning. ♥Ainali ^diskussion_bidrag 17 september 2018 kl. 23.43 (CEST)

Där ser man. Kan blockerade, till exempel klottrare, också genomföra en sådan "guidad tur"? Och kan man som administratör se om vederbörande har lyckats genomföra den med ett "godkänt resultat"? --Larske (diskussion) 17 september 2018 kl. 23.58 (CEST)

Finns det några "guided tours" på svwp? Speciellt, finns det någon "guided tour" för att "skapa en guided tour"? --Larske (diskussion) 18 september 2018 kl. 00.05 (CEST)

Ja, det finns ett par sådana rutor man måste klicka bort när man precis startat ett nytt konto, specifikt att man kan redigera och att man ska lägga till källhänvisningar (efter att man klickat att man vill lägga till källor). Testa gärna genom att skapa ett nytt konto. Jag har inte funnit dem särskilt hjälpsamma, men har inte ägnat särskilt mycket tid åt att konstruera en bättre snitslad bana. Och jag har ingen aning om exakt hur man gör för att förbättra den snitslade banan eller hur man gör en ny.//Hannibal (diskussion) 18 september 2018 kl. 07.58 (CEST)

Omröstning

1. Deryni (diskussion) 2 oktober 2018 kl. 19.37 (CEST)

Möjlighet till automatiska "abuse report mail"

Problem

Den aldrig sinande strömmen av klotter från IP-nummer, framför allt skolor och andra kommunala verksamheter, åtgärdas med blockeringar som successivt eskaleras från enstaka timmar till dagar, veckor, månader och slutligen {{Läsårsblockering 2 år}}. Ibland läggs en uppgift in på IP-numrets diskussionssida om vem som "äger" IP-adressen och en epost-adress till vilken missbruk (abuse) kan meddelas. Jag tror inte att det är så många som använder den möjligheten.

Vilka påverkas

Alla klottersanerare. Alla som klottrar som oinloggade.

Tidigare diskussioner

Känner inte till om detta har diskuterats tidigare. Jag har tänkt på det länge och senast i samband med Användardiskussion:Larske#IP-nummer_och_blockeringar där Episcophagus ställde frågan om vi gör något mer än bara blockerar.

Lösningsförslag

Inför möjligheten att, i samband med blockeringar av IP-nummer, "kryssa i" att ett mail skickas automatiskt till därför avsedd epost-adress med "Svenska Wikipedia" som avsändare och med ett innehåll som medger för mottagaren att spåra vilken användare på skolan (eller motsvarande) som har gjort sig skyldig till klottret och stänga av denna användare från att använda, både läsa och skriva eller bara skriva (action=submit), Wikipedia. Givetvis bör också en länk till redigeringshistoriken inkluderas i meddelandet. Skickandet av detta mail bör också loggas, helst på användaren diskussionssida, men åtminstone i en systemlogg.

Föreslaget av

--Larske (diskussion) 17 september 2018 kl. 23.35 (CEST)

Diskussion

Vi beslöt att utesluta förslaget från omröstningen.

Tack, Larske, för att du med detta förslag uppmärksammar det tråkiga och otacksamma arbetet att hålla uppslagsverket rent från klotter. Dock är det underliggande problemet inte primärt av tekniskt natur, varför vi inte kan ta oss an uppdraget. Att skicka mejl med “svenska Wikipedia” som avsändare är problematiskt, då det är otydligt vem som egentligen skulle vara den ansvariga parten. Det är vidare inte alltid lätt att säkerställa till vilken adress mejlet skall skickas, och det är inte heller givet att sådana mejl faktiskt hjälper. Den kringliggande problematiken är med andra ord för komplex för att kunna åtgärdas med en teknisk lösning.

Om problemet är att man inte personligen vill vara avsändare så skulle Wikimedia Sverige kunna sätta upp en wikipedia.se-avsändaradress som kan användas. Det kräver dock att den svenskspråkiga Wikipedia-gemenskapen kommer fram till regler för vilka som kan ges tillgång till den samt exakt hur den får användas (jfr. med presswikipedia.se). Detta kanske kan lösa en del av problemet.

Vänligen, Alicia Fagerving (WMSE) (diskussion) 20 september 2018 kl. 13.48 (CEST)

@Alicia Fagerving (WMSE): Jag har svårt att förstå och/eller acceptera motiveringarna till att utesluta detta förslag som du framför:

1. Vad betyder att "det underliggande problemet inte primärt är av teknisk natur". Exakt vad anser du vara "det underliggande problemet"? Varför måste problemet vara av teknisk natur, det är väl lösningen som ska vara teknisk för att platsa i denna omröstning. Är det något av det jag skriver under rubriken "lösningsförslag" som inte är av "teknisk natur"?
2. Att "sätta upp en wikipedia.se-avsändaradress" är precis det jag föreslår. Men jag förstår inte varför detta skulle göra det mindre "otydligt vem som egentligen är den ansvariga parten".
3. Att "det inte alltid är lätt att säkerställa till vilken adress mejlet ska skickas" är ett i mitt tycke dåligt argument. På massor av användardiskussionssidor för IP-adresser står "abuse-adressen" på första raden. Se till exempel Användardiskussion:62.101.38.241.
4. Att "det inte är givet att sådana mejl faktiskt hjälper" är en åsikt. Om det är gemenskapens åsikt kommer detta förslag inte att få så många röster, men detta argument/svepskäl från dig tycker jag är att föregripa omröstningen.

Jag tycker att ett förslag är värt en mer seriös behandling än denna. Lös problemet istället för att hitta på en massa argument för varför det "inte går"!

--Larske (diskussion) 20 september 2018 kl. 14.38 (CEST)

@Larske: Jag beklagar att vår motivering var svår att förstå. Jag ska försöka utveckla vårt resonemang nedan.

Formuleringen "det inte är givet att sådana mejl faktiskt hjälper" var otydlig. Vad vi menar är att det i önskemålet varken fanns belägg för (eller emot) att sådana mail hjälper. Att den föreslagna lösningen (kontakta abuse-adressen) faktiskt har en effekt på det underliggande problemet (upprepat klotter från en skola) skulle därför behöva undersökas innan man påbörjar en teknisk implementation av ett sådant verktyg, oavsett om det är ett fristående verktyg eller inbyggt i MediaWiki. (Med det sagt får jag erkänna att vi själva började fundera på implementation innan vi gjorde denna reflektionen, därav analysen av den föreslagna lösningen nedan.)

Vi tolkade din önskan som att det fanns tre problemdelar för den föreslagna lösningen 1) Det är svårt att identifiera vilken abuse-adress som hör till en IP-adress 2) Det är bökigt att behöva lämna Wikipedia för att skicka ett mail när en sådan finns 3) Det är önskvärt att avsändaren är Svenskspråkiga Wikipedia snarare än en enskild användare.

1) Är ett problem som inte går att åtgärda med en teknisk lösning på Wikipedia. Till den ställda problematiken tillkommer att IP-adresser inte permanent är kopplade till samma ägare vilket innebär att adresser man väl identifierat blir utdaterade. Detta samt att vem som helst kan lägga till adresser innebär en risk att fel adress blir beskylld för klottret.

2) Att genom en finess skicka ett sådant mail skulle kräva att autentiseringsuppgifterna för kontot lagrades förhållandevis osäkert vilket omöjliggör en sådan lösning. Alternativet är då istället att baka in det i MediaWiki (vilket då skulle göra detta tillgängligt på alla wikis). Här är vår bedömning, baserat på våra tidigare kommunikationer med WMF, att det inte är en funktionalitet som de är intresserade av att se brett implementerat och som troligen skulle skala dåligt p.g.a. begränsningarna i 1). Det faktum att det är avhängigt mer av interna policybeslut hos WMF än av teknisk utveckling gjorde också att vi inte ansåg att lösningen var lämplig för oss att genomföra/undersöka.

3) Detta var den delen av problemet som vi ser att föreningen relativt lätt kan lösa genom att sätta upp en avsändaradress. Regler för vem/vilka som kan använda denna och hur är dock ett policybeslut som ligger på den Svenskspråkiga Wikipedia-gemenskapen att formulera.

Jag hoppas att det bättre förklarar våra tankar när vi beslöt att utesluta önskan.

Efter reflektion skulle vi kunna öppna upp denna önskan igen men då med förståelsen att det i första steget främst skulle handla om att sätta upp adressen samt tillsammans med gemenskapen försöka utvärdera ifall dessa mail har en mätbar effekt. Om den skulle ha det så skulle man kunna undersöka om det finns någon lösning som vi missat i ovanstående analys.

/André Costa (WMSE) (diskussion) 24 september 2018 kl. 15.24 (CEST)

@André Costa (WMSE): Tack för det utvecklade svaret. Men jag förstår fortfarande inte vad du menar med "Vi tolkade din önskan som att det fanns tre problemdelar för den föreslagna lösningen". Är "problemdelar" lika med delar av det problem som behöver lösas eller problem med lösningen? Jag tycker att du delvis blandar ihop det och det är kanske fel att hantera detaljerade lösningar tillsammans med problemformuleringarna.

1) Det är inte så svårt, men lite tidskrävande, för en person att "slå upp" abuse-adressen i lämplig "whois-tjänst". Hur kan detta vara svårt för ett program att göra förstår jag inte.

2) Jag kan inte bedöma det, du har säkert rätt om autentiseringen. Men det är ju just sånt som inte finns globalt som ni har sagt kan vara möjligt för svwp att göra om det bara inte har avvisats av WMF.

3) Kanske någon skulle vilja använda ett WMSE-mailkonto för att skicka mail, men om det måste göras manuellt är det ändå inget som jag kommer att ta mig tid att göra. Vilka som ska ha rätt att utnyttja kontot för att skicka abuse-mail bör vara samma användare som kan blockera IP-adresser.

--Larske (diskussion) 24 september 2018 kl. 16.44 (CEST)

Omröstning

1. Deryni (diskussion) 2 oktober 2018 kl. 19.37 (CEST)

Ett semiautomatisk stöd för att identifiera vilka valbara teknikfinesser som kan vara av värde för bidragsgivare

Problem

Det vimlar av nya teknikfinesser som lanseras men det känns helt hopplöst förstå om något av dessa kan vara av intresse för "mig". Det är för mycket och för svårt det som presnteras.

Vilka påverkas

Alla bidragsgivare, främst då de aktiva och som inte är teknikexperter.

Tidigare diskussioner

Ing jag känner till

Lösningsförslag

Antingen en matris eller hellre en interaktiv frågesnurra som först frågar vilken typ av bidragsgivare jag är, vad jag gör vad jag kan etc. Och utifrån detta ger tips på funktioner som kanske kan vara intresse för mig, på vilket sätt och vad det skulle innebära att aktivera finessen. "nya teknikfinesser för Dummies"

Föreslaget av

Yger (diskussion) 5 september 2018 kl. 20.23 (CEST)

Diskussion

Utmärkt förslag!//Hannibal (diskussion) 14 september 2018 kl. 12.34 (CEST)

Vi beslöt att utesluta förslaget från omröstningen.

Tack, Yger, för förslaget. Du lyfter fram ett verkligt problem – det finns en uppsjö finesser och tillägg som många användare upplever som rörig och svår att orientera sig i. Ett oerhört tacksamt område att jobba med, men dessvärre inte något vi kan hjälpa med. För att skapa ett semiautomatiskt verktyg, som i förslaget, skulle man behöva på något sätt markera alla befintliga finesser med deras användningsområde och svårighetsgrad, samt säkerställa att framtida finesser markeras på samma sätt av deras skapare. För att inte tala om att det finns många olika sorters bidragsgivare – att samla in information om deras beteenden och behov för att skapa “profiler” för “snurran” är inte en programmeringsuppgift. Hela problemet grundar sig i bristande dokumentation. För att lösa det kan man uppmana finess-skaparna att även skapa bra hjälpsidor till deras verktyg samt att proaktivt kommunicera om utvecklingen – ett svenskcentrerat “Tech News” skulle nog läsas av många. Det finns kanske någon eller några som känner sig manade att inventera finesserna och skapa ett mera användarvänligt register – det finns som vi kan se ett behov – men det faller utanför det här projektets scope. Vänligen, Alicia Fagerving (WMSE) (diskussion) 20 september 2018 kl. 13.43 (CEST)

@Alicia Fagerving (WMSE), Yger: Jag tycker att det är trist att WMSE utesluter ett förslag från omröstningen bara för att det inte "passar" scopet för ett, som det verkar, alltför snävt projekt. Bara för att det inte i alla delar är "en programmeringsuppgift"! Ingen begär heller att lösningen ska vara specad i detalj innan omröstningen ens har börjat. Vad som består av programmering eller annat kan nog ta en stund att utreda. Om det i en senare analys visar sig att det är för svårt eller bör lösas på något annat sätt än som "en programmeringsuppgift" så må det vara hänt. Då kan ni övergå till nästa förslag på prioriteringslistan, men genom att inte ens låta förslaget delta i omröstningen tappar ni bort möjligheten att få gemenskapens uppfattning om hur värdefullt det vore med en lösning på problemet.

--Larske (diskussion) 20 september 2018 kl. 15.05 (CEST)

och det handlar alls inte om bättre hjälpsidor. Utan att istället börja utifrån användaren, att ange tre tips för en nybörjare med och utan tekniks kunskap, detsamma för en användaresom varit här något år etc.Yger (diskussion) 20 september 2018 kl. 15.12 (CEST)

@Larske, Yger:

Att genomföra en inledande undersökning av vilka typer av skribenter som finns, hur de klassificerar sina behov, vilka typer av finesser som skapas och hur de kan klassificeras gentemot de identifierade behoven såg vi som en uppgift som inte var teknisk i sin natur. Därutöver skulle den troligen ta så pass stora resurser i åtagande, från detta relativt lilla projekt, att vi inte skulle ha möjligt att implementera våra slutsatser i ett verktyg inom ramen för årets projekt.

Därför försökte vi istället ge konkreta förslag på sociala/organisatoriska (icke-tekniska) åtgärder som kan försöka komma åt samma problem: 1) en drive för att förbättra den information som finns, 2) tydliga regler för vilken dokumentation som måste finns på plats innan en finess publiceras, 3) en grupp som tar på sig ansvar att informera gemenskapen om nya finesser på ett lättförståeligt sätt.

Det sagt har du en poäng att det skulle vara intressant att veta om gemenskap anser att det är mer värt att prioritera en teknisk än en social/organisatorisk lösning på problemet. Att ha i bakhuvudet är då att risken är stor att tiden inte nödvändigtvis räcker till att både undersöka behovet, genomföra ovan beskrivna analys samt sedan påbörja implementationen.

/André Costa (WMSE) (diskussion) 24 september 2018 kl. 15.25 (CEST)

Men min poäng är att ni alldeles för fort valde att tolka det jag skrev på ett vist sätt. Jag beskrev ju mer ett behov än en lösning, och hade nog väntat mig en dialog för att tillsammans formulera en lösning. Och även det du skriver nu är mycket mer än min tanke avsåg. Jag läser aldrig info om nya finesser för jag förstår aldrig vad det är frågan om och om det är av värde för mig, och det räcker då inte mer mer info om finesserna, utan jag behöver hjälp med både grovsållning och detaljsållning. Tänk om ni för allt som nu levereras med tehnews kunde lägga in, när ni så tycker, en MYCKET kort grej på byrbunnen, med indikation för vem och för vad finessen avser.Yger (diskussion) 24 september 2018 kl. 16.01 (CEST)

@André Costa (WMSE): Tack för det kompletterande svaret. Det kanske skulle framgå någonstans hur stort det tänkta projektet är. Handlar det om 1-2 personer som är specialister på något visst programmeringsspråk som ska arbeta på 25-50 procent under 2-4 månader eller handlar det om 4-6 personer som är generalister som ska arbeta på heltid under 9-15 månader? Jag får erkänna att jag inte har läst beskrivningen av projektet så noga så jag kan ha missat detta. Jag tänkte nog mer i termer av problem som önskades lösta än på problem med att implementera en lösning. --Larske (diskussion) 24 september 2018 kl. 16.18 (CEST)

Uteslutna förslag

Utnyttja generella moduler utan att sprida modulkoden till flera ställen

Problem

Många Lua-moduler löser generella och språkoberoende uppgifter och det är "hål i huvet" att kopiera sådana moduler till olika språkversioner av Wikipedia eftersom felrättningar och underhåll av modulerna måste göras på många ställen istället för på ett enda ställe.

Vilka påverkas

Alla som utvecklar Lua-moduler.

Tidigare diskussioner

Har antagligen redan diskuterats, men jag vet inte var. Jag blev triggad av förslaget "Kartor i infoboxar" från Ainali ovan.

Lösningsförslag

Inför möjligheten att anropa moduler från andra språkversioner. Åtminstone från något centralt ställe liknande Commons eller Wikidata.

Inför en praxis att allt språkberoende samlas i separata "submoduler" som antingen kan sparas lokalt eller i någon central lösning som TranslateWiki.

Föreslaget av

--Larske (diskussion) 17 september 2018 kl. 23.35 (CEST)

Omröstning

Vi beslöt att utesluta förslaget från omröstningen.

Tack, Larske, för detta och det följande förslaget. Vi valde att behandla dem ihop eftersom de bygger på samma konceptuella ramverk. Förslagen tydliggör en stor brist inom Wikimedia-projekten som påverkar många användare världen över. Samtidigt är det – tråkigt nog! – just problemets storlek och universalitet som gör det omöjligt för oss på Wikimedia Sverige att hantera. Problemet är en konsekvens av att de olika Wikimedia-projekten är tekniskt sett väldigt självständiga, och för att åtgärda det skulle man behöva jobba både med MediaWiki, den mjukvara projekten använder sig av samt med hur olika wikis kommunicerar med varandra – vilket skulle innebära en betydligt större tidsskala än vad vi räknat med samt omfattande kommunikation och infrastrukturella förändringar.

Samtidigt är det möjligtvist en tröst är att problemet redan finns på WMF:s radar i och med att samma idé har lagts fram på deras önskelista (m:Community_Tech/Central_repository_for_gadgets,_templates_and_Lua_modules ). Projektet spåras på Phabricator (phab:T121470). Ett nära besläktat ämne som diskuteras på Meta och som kan vara av intresse är Shadow namespaces. På grund av projektets enorma omfattning kan man i nuläget inte säga när det kommer att kunna sjösättas.

Vi beklagar att vi inte gjorde det tydligt att idéer som lyfts och behandlats i de internationella önskelistorna, även om de är värdefulla, kan nekas då de antingen nu behandlas av WMF (eller Wikimedia Deutschland) eller att dessa har nekat dem på goda grunder. Önskningar som lyfts tidigare men som inte sågs som viktiga nog av den internationella gemenskapen, men kan vara det för den svenskspråkiga, är dock välkomna.

Vänligen, Alicia Fagerving (WMSE) (diskussion) 20 september 2018 kl. 13.50 (CEST)

Tack för info. Jag förstår att detta förslag ligger utanför ramen för vad WMSE kan göra och kan bara hoppas att ni i olika sammanhang på andra sätt kan stötta det. --Larske (diskussion) 20 september 2018 kl. 14.41 (CEST)

Utnyttja generella mallar globalt utan att sprida mallkoden till flera ställe

Problem

Många mallar löser generella och språkoberoende uppgifter och det är "hål i huvet" att kopiera sådana mallar till olika språkversioner av Wikipedia eftersom felrättningar och underhåll av mallarna måste göras på många ställen istället för på ett enda ställe.

Vilka påverkas

Alla som utvecklar mallar.

Tidigare diskussioner

Har antagligen redan diskuterats, men jag vet inte var.

Lösningsförslag

Inför möjligheten att anropa mallar från andra språkversioner. Åtminstone från något centralt ställe liknande Commons eller Wikidata.

Inför en praxis att allt språkberoende samlas i separata "submallar" som antingen kan sparas lokalt eller i någon central lösning som TranslateWiki.

Föreslaget av

--Larske (diskussion) 17 september 2018 kl. 23.35 (CEST)

Omröstning

Vi beslöt att utesluta förslaget från omröstningen.

Resultat

Wikimedia Sverige går igenom de olika önskningarna för att se vilka som är genomförbara (inom ramen för den tid och kompetens som finns tillgänglig) samt vilka som förväntas att ge bäst genomslag för den krävda insatsen. Omröstningen (se resultat nedan) ligger till stöd för det slutliga urvalet men utgör enbart ett av kriterierna.

Summering av omröstning

• 4 – Kartor i infoboxar
• 3 – Automatiserad artikelförbättringsbedömning
• 1 – Automatkonvertera källhänvisningar som enbart består av URL:er
• 1 – Möjlighet till automatiska "abuse report mail"
• 1 – Funktionalitet för att skapa "interaktiva kurser/guidad tur" för nybörjare och klottrare
• 0 – Ett semiautomatisk stöd för att identifiera vilka valbara teknikfinesser som kan vara av värde för bidragsgivare

Utvärdering och val av projekt

Tack för ert intresse för årets upplaga av Gemenskapens Tekniska Önskelista! Även i år var förslagen intressanta och inspirerande. WMSE:s utvecklarteam har nu valt ut förslag att arbeta vidare med. Vi har beslutat att genomföra de två förslagen som fått mest stöd.

Bättre kartor i infoboxar

En idé som kan tillämpas i många artiklar och därmed gynna en bred skara användare, såväl skribenter som läsare. Implementationen kommer att bestå av en modul som kommer att kunna inkluderas i mallar (t.ex. infoboxar). Detta innebär att modulen kommer att kunna ha en bred och varierad användning, beroende på behoven, och i förlängningen kanske även kunna implementeras av andra Wikipediaversioner.

Läs mer om våra planer på projektets undersida.

Automatiserad artikelförbättringsbedömning

Projektet har som mål aktivera den automatiska bedömningen av artikelkvalitet som finns i ORES och att skapa en s.k. finess (gadget) som visar kvalitén av en redigering. Själva ORES-delen utförs av WMF, men vi kommer att kommunicera med dem för att hjälpa till att säkerställa att det blir implementerat och att det är anpassat till gemenskapens behov. När detta är klart kommer vi att bygga en finess för att göra det lättare för bidragsgivare att bedöma hur deras bidrag förbättrat uppslagsverket. Det är inte omöjligt att en sådan finess skulle kunna implementeras även av andra gemenskaper.

Läs mer om våra planer på projektets undersida.

Vad händer nu?

Vi räknar med att inleda arbetet i november. Om du är intresserad av något av projekten, lägg gärna dess undersida på din bevakningslista. Där kan du läsa mer om hur vi tänker arbeta med projektet. Vi kommer även att varje månad, eller oftare om det behövs, posta uppdateringar för gemenskapen om hur arbetet fortskrider. Där kan du dessutom hitta en länk till projektets Phabricator-arbetsbräda, vilken används av oss internt för att detaljplanera det tekniska arbetet.

Bägge projekten kommer att koordineras av min kollega Sebastian Berlin.

Vi vill återigen tacka för alla förslagen och den myckna diskussion de inspirerat, samt för allt stöd och alla frågor som ställts. Det är verkligen glädjande att se hur mycket iver och förbättringsanda som finns i gemenskapen; vilken synd att man omöjligen kan förverkliga allt!

Med vänlig hälsning, --Alicia Fagerving (WMSE) (diskussion) 17 oktober 2018 kl. 15.28 (CEST)