Wikipedia:De kroeg/Archief/20180813


Nieuwe gebruikersgroep voor het bewerken van wikibrede CSS/JS bewerken

Zie ook Wikipedia:Interfacemoderator. Aanmeldingspagina komt binnenkort. –bdijkstra (overleg) 30 jul 2018 15:17 (CEST)[reageren]
Kortom, mensen moeten nu geen willekeurige admin hacken voor ongein op deze pagina's maar een willekeurige crat of iemand met het nieuwe bitje. Wikibreed nog steeds een erg grote visvijver. Natuur12 (overleg) 30 jul 2018 15:51 (CEST)[reageren]
Nu de rechten daadwerkelijk zijn geïmplementeerd op Wikipedia, moeten we als gemeenschap nu de procedures bepalen. De meeste daarvan hebben te maken met de aanmeldingscriteria. Ik heb even een kort lijstje gemaakt, die waarschijnlijk nog wel wat zal missen:
Optie A Optie B Optie C
Stemrecht Iedereen met minimum editaantal (zoals moderatorverkiezingen) Enkel moderatoren (zoals bureaucraatverkiezing) Enkel adviserend, bureaucraat hakt knoop door (zoals terugdraaieraanmelding)
Voorstemmen 55% 66,6% 75%
Minimumaantal intops Geen 2 (net zoals bureaucraten) Ander arbitrair aantal
Duur verkiezing 1 week (zoals moderatorverkiezingen) 2 weken (zoals bureaucraatverkiezing) Minimaal 24 uur; in ieder geval tot consensus (zoals terugdraaieraanmelding)
Verwijderen bit Stewards (zoals moderator- en bureaucraatbitjes) Bureaucraten (zoals arbcom- en terugdraaierbitjes)
Opiniepeiling voor de verschillende opties? - Kippenvlees (overleg‽) 30 jul 2018 16:11 (CEST)[reageren]
Ik zou voor optie c gaan. Het is bij deze functie vooral belangrijk dat er even goed gekeken wordt of iemand geen wandelend veiligheidslek is en dat deze persoon wat wat hij/zij doet zonder de halve wiki op te blazen. Een peiling zou ik alleen doen als we er in deze kroegdiscussie niet uitkomen. Natuur12 (overleg) 30 jul 2018 16:25 (CEST)[reageren]
Noot: Optie A tot C zijn van mijn kant enkel toegevoegd om makkelijk te kunnen verwijzen naar de verschillende mogelijkheden per vraag en is niet een volledig voorstel van implementatie (zo is 75% voorstemmen niet logisch bij een systeem zoals terugdraaiers dat hebben). - Kippenvlees (overleg‽) 30 jul 2018 16:30 (CEST)[reageren]
Volgens mij is het verstandig(er) om eerst te kijken wie we in aanmerking willen laten komen voor het verkrijgen van deze rechten. De tekst noemt een aantal voorwaarden: gebruiker, zeer vertrouwd, minimaal een basale kennis van CSS en JS, bekend met de privacyverwachtingen en goede kennis te hebben van accountbescherming. Ik begrijp de wens om de accountbescherming hoog op de agenda te hebben, maar vind zelf de kennisvereisten voor JS en CSS (basiskennis) aan de magere kant. Eén tikfoutje in het JS kan flinke delen van de functionaliteit van Wikipedia (tijdelijk) uitschakelen, maar het vinden van dat foutje kan wat hoofdbrekens kosten. Al is het ongedaan maken van de bewerking(en) altijd een optie, wikisoftware biedt die mogelijkheid.
De kwalificatie zeer vertrouwd lijkt mij niet voldoende meetbaar met een methode zoals voor de terugdraaibitjes. Ik denk dat de kandidaten best mogen aangeven waarom zij deze functie willen bekleden en wat zij de gemeenschap te bieden hebben, voordat er over hun benoeming gestemd gaat worden. (Jaarlijkse) bevestiging lijkt me niet nodig, een duidelijk innamebeleid van dit vinkje wel. Op eigen verzoek, bij geen aanwezigheid op de wiki gedurende 3/6 maanden, bij misbruik. Vergeet ik nog iets? Met vriendelijke groet, RonnieV (overleg) 30 jul 2018 17:00 (CEST)[reageren]
Een tikfoutje met een sjabloon kan evenzo flinke delen uitschakelen, en het vinden ervan kan evenzo hoofdbrekens kosten, maar dit laten we open aan alle autobevestigde gebruikers. Bij deze nieuwe gebruikersgroep gaat het echter niet om tikfoutjes, maar om erop te letten dat er geen onveilige code wordt toegevoegd. Basale kennis is in mijn optiek genoeg om iets als dubieus aan te kunnen merken. –bdijkstra (overleg) 30 jul 2018 17:08 (CEST)[reageren]
Een tikfout in een sjabloon treft nooit alle pagina's (al raakt sjabloon:infobox er best veel), maar kan in ieder geval nooit tot het uitvoeren van schadelijke code leiden. Ik weet niet wat bdijkstra als 'basale kennis' ziet, maar in JS zijn heel veel constructies mogelijk waarvan de werking moeilijk te doorgronden valt. Of we het nu over regexen, inherited code of van elders geïnclude code hebben. Het voordeel is dat het in ieder geval mogelijk is om de uitvoerder aan te spreken en een toelichting te vragen. Met vriendelijke groet, RonnieV (overleg) 30 jul 2018 17:28 (CEST)[reageren]
Wat mij betreft zijn er twee criteria; vertrouwen en kunde. De meest basis voorwaarde voor het toekennen van deze permissie is: "vertrouwt de wiki deze persoon met de accounts van alle andere gebruikers" want dat is nl. het permissie niveau die je een kwaadaardige script kiddie er mee geeft (en o.a. waarom het afgesplitst wordt). Enige ervaring met de talen in kwestie en begrip van impact en het effect van wijzigingen komt daar boven op. Ik zou zeggen dat iemand die sysop is, automatisch voor punt 1 kwalificeert, maar nog niet perse voor punt 2. Terwijl een gemiddelde developer in het dagelijks leven, makkelijk voor het tweede punt kwalificeert, maar misschien niet voor het eerste. Die balans moet in een procedure gevat worden. TheDJ (overleg) 30 jul 2018 17:40 (CEST)[reageren]
Ik zie 'basale kennis' als genoeg kennis om binnen korte tijd (~1 uur) te kunnen bepalen of een bewerking potentieel schadelijk is of niet. Dus dat je weet wat regexp/overerving/inclusie is en de nodige details binnen die tijd kan opzoeken en toepassen. –bdijkstra (overleg) 30 jul 2018 17:45 (CEST)[reageren]
Waarom een minimumaantal anders dan 2? –bdijkstra (overleg) 30 jul 2018 16:32 (CEST)[reageren]
Had geen specifieke aanleiding, maar was meer ter overzicht van de mogelijke opties. - Kippenvlees (overleg‽) 30 jul 2018 17:46 (CEST)[reageren]
@Natuur12: nee, geen crats. Straks kunnen alleen lokale interfacemoderatoren, stewards en globale interfacebewerkers de genoemde bewerkingen doen. –bdijkstra (overleg) 30 jul 2018 23:48 (CEST)[reageren]
Ik heb toch ook niet beweerd dat crats dergelijke bewerkingen kunnen uitvoeren? Ze kunnen wel het bitje toekennen, ook aan zichzelf. Of je dan een gehackte crat of een gehackte interfacemod hebt maakt dan niet zoveel uit. Kwestie van het gehackte account het bitje geven, of een wegwerpaccount en de hacker kan z'n gang gaan. Natuur12 (overleg) 31 jul 2018 00:21 (CEST)[reageren]
Ah nu snap ik het. Ik vond je bewoording een beetje verwarrend. –bdijkstra (overleg) 31 jul 2018 08:38 (CEST)[reageren]

Ander balletje. Zou het niet handiger zijn als crats dit bitje ook weer kunnen verwijderen? Anders kunnen we straks een hele afzettingsprocedure opzetten voor dat ene geval in de de vijf jaar waarvan we misschien het bitje weer af zouden willen pakken. Bovendien is verwijderen op verzoek van de bitjesdrager zelf een simpele actie waar je geen steward voor nodig zou moeten hebben. Natuur12 (overleg) 30 jul 2018 16:02 (CEST)[reageren]

Dat is mogelijk, maar het intrekken van bitjes van moderatoren en bureaucraten moet nu ook via de stewards dus je zou op zich dezelfde argumenten ook daarvoor kunnen gebruiken. Op zich ben ik niet erop tegen dat bureaucraten ook die drie bitjes kunnen ontnemen, maar dan lijkt het me logischer om dat dan gelijk volledig te peilen onder de gemeenschap, in plaats van enkel deze gebruikersgroep. - Kippenvlees (overleg‽) 30 jul 2018 16:11 (CEST)[reageren]
Een rogue crat (nou ja, eerder een gehackte) zou in z'n geval elke mod en andere crat af kunnen zetten en zo zijn 10 second of supreme ruler kunnen krijgen. Maar een peiling over alle drie de groepen is geen slecht idee! Natuur12 (overleg) 30 jul 2018 16:15 (CEST)[reageren]
Het plan was om dit ook voor bureaucraten mogelijk te maken, maar zo te zien is dat niet doorgevoerd op wiki's waarin bureaucraten geen modbitjes kunnen afpakken. –bdijkstra (overleg) 30 jul 2018 16:18 (CEST)[reageren]
Dit lijkt me een gemiste kans, en ik denk dat we er goed aan doen om hier alsnog om te vragen/op aan te dringen. Misschien is het anders een optie om eens een stemming op te zetten om de bureaucraten ook modbitjes af te kunnen laten nemen, als er om een of andere reden aan die combinatie gehecht wordt. Met vriendelijke groet, RonnieV (overleg) 30 jul 2018 17:00 (CEST)[reageren]

Dit gebruikersrecht is met reden ingevoerd, en dus moet je ook uiterst voorzichtig zijn wie je de rechten toekent. Eenzelfde procedure als bij de terugdraaiers lijkt me daarom niet opportuun. Zelf zou ik kiezen voor een procedure als bij de misbruikfilterredacteuren, of anders bij de bureaucraten. En over het verwijderen van bitjes door crats: ik zou het persoonlijk laten zoals het nu is. Een extra laag door het aan de stewards te laten kan w.m.b. geen kwaad. Sterker nog, dat vind ik alleen maar goed. Ik snap nooit zo goed waarom wiki's het zelf willen doen. En er is ook geen noodzaak voor, toch? Kwestie van oplossing zoekt probleem, heb ik het gevoel... Trijnstel (overleg) 30 jul 2018 23:08 (CEST)[reageren]

Ik snap nooit zo waarom je werk uit zou besteden wat je als gemeenschap zelf kan doen. Ik snap ook nooit zo waarom het allemaal maar via meta moet. Zorgen dat onze gemeenschap zelf de touwtjes in handen heeft kan wat mij betreft geen kwaad. Er is toch helemaal geen noodzaak om dit allemaal via meta te doen? Natuur12 (overleg) 30 jul 2018 23:28 (CEST)[reageren]
Ik geloof toch niet dat wij (nlwiki mods) verlegen zitten om werk, of wel soms? En waar is het vertrouwen in ons (de stewards) gebleven? Trijnstel (overleg) 30 jul 2018 23:33 (CEST)[reageren]
Niemand zit op extra werk te wachten lijkt me. Waar heb ik gezegd geen vertrouwen in de stewards te hebben? Natuur12 (overleg) 31 jul 2018 00:21 (CEST)[reageren]
Procedure van aanstellen vind ik van belang voor de procedure van ontnemen. Procedure voor aanstellen (stemrecht) wordt optie A of optie C. Kan me niet voorstellen dat we optie B kiezen. Als we volledige verkiezingen gaan houden zoals optie A, dan wordt het meer een technisch-moderator, en zou ik het ontnemen liefst via meta zien gaan. Als optie C, dan wil ik het lokaal regelen. Ligt eraan hoe we de functie zien. Misbruikfilterredacteur is lokaal geven en ontnemen, moderator is lokaal geven en op meta ontnemen, checkuser is op meta geven en ontnemen. Dus is dit bitje vergelijkbaar met misbruikfilterredacteur, moderator of checkuser? Ik lees tot dusver vergelijking met misbruikfilterredacteur. Mvg, Taketa (overleg) 31 jul 2018 00:52 (CEST)[reageren]
Het lijkt een beetje op de discussie destijds bij de introductie van het misbruikfilter. Stemprocedures e.d. Destijds heb ik gezegd dat m.i. technische kennis (over zaken als regular expressions) essentieel is. Terugkijkend is dat ook bewaarheid.
In dit geval gaat het primair om kennis van m.n. javascript (en in mindere mate van CSS), want daar ligt de oorzaak van dit geheel en dan moet het natuurlijk ook nog een te vertrouwen gebruiker zijn. - RonaldB (overleg) 31 jul 2018 01:45 (CEST)[reageren]

Op Wikipedia:Opinielokaal/Reglementen interfacemoderatoren staat een opiniepeiling klaar om vrij snel te starten. Zoals op de peilingpagina ook staat vermeld, is deze bedoeld om te toetsen in welke richting de reglementen moeten gaan. - Kippenvlees (overleg‽) 6 aug 2018 02:35 (CEST)[reageren]

Voetbalfan gezocht, maandag om 20.30u in Almere bewerken

We hebben nog geen foto's in de commons:Category:Suriname national football team en op dit moment is het Surinaamse elftal in Nederland. Vanavond speelt het vanaf 20.30u de laatste oefenwedstrijd tegen Almere City FC (artikel). Is iemand in de gelegenheid om daar heen te gaan en ook een paar foto's te maken? Ymnes (overleg) 6 aug 2018 17:14 (CEST)[reageren]