Wikipedia:De kroeg/Archief/20180403

{{#property:Dinges}}

Wordt dit officieel het nieuwe beleid? Dat moeten we dan wel weten. ErikvanB (overleg) 24 mrt 2018 23:41 (CET)

Er is nog geen officieel beleid. Maar er mag wel mee geëxperimenteerd worden door wie dat wil. Het aardige hiervan is dat je Wikidata kunt overrulen als je meent een fout te zien: dan vul je gewoon een hard gegeven in; een andere optie is om dan naar Wikidata te gaan en het gegeven daar aan te passen. Het lastige is dat er bij vrijwel geen enkele bewerking in Wikidata meer een bewerkingssamenvatting beschikbaar is, dus het is lastig om te motiveren waarom je een waarde daar veranderde, met het risico dat iemand je verbetering gewoon weer ongemotiveerd terugdraait. Dat kun je wel doen als je de property in ons artikel vervangt door een waarde: in de samenvatting opgeven waarom je niet akkoord was. WIKIKLAAS overleg 25 mrt 2018 00:26 (CET)

Dankjewel. Ja, hetzelfde probleem (niet kunnen motiveren) had ik wel eens als ik wat vertaalde of een vertaling veranderde voor MediaWiki. - ErikvanB (overleg) 25 mrt 2018 00:32 (CET)

... want dat gaat niet altijd goed. ErikvanB (overleg) 25 mrt 2018 00:58 (CET)

Dat probleem heeft een naam en heeft daarom een simpele oplossing. Natuur12 (overleg) 25 mrt 2018 01:15 (CET)

Ik ben voorstander van het gebruik van Wikidata in infoboxen, maar niet op die manier. Ik doe het liever onzichtbaar voor de eindgebruiker, waarbij ik wel de eindgebruiker de mogelijkheid geeft om Wikidata te overrulen. Dit gebeurt nu al bij Sjabloon:Infobox acteur en Sjabloon:Infobox artiest voor de externe sites zoals IMDb, AllMusic, MovieMeter etc. Als die parameter niet ingevuld is in de infobox, dan wordt die data opgevraagd bij Wikidata en indien beschikbaar gebruikt. Is de parameter niet ingevuld en de waarde niet bekend op Wikidata, dan wordt er niets getoond, net zoals het was voor de koppeling met Wikidata. Zo heb je als gebruiker uiteindelijk de controle. Je zadelt zo iemand die de pagina bewerkt niet op met een of andere vreemde code die hij/zij niet snapt. Mbch331 (Overleg) 25 mrt 2018 08:54 (CEST)

Volledig mee eens. Men mag de gewone bewerker niet opzadelen met de problemen in Wikidata. Er kunnen altijd nog rapportages gemaakt worden binnen de Wikidata gemeenschap, waarbij de verschillen met de taalgemeenschappen nader uitgezocht worden. Als er dan toch ingegrepen wordt vanuit Wikidata is dat dan een gewone mutatie bij Wikipedia NL met motivatie die eventueel teruggedraaid kan worden. Beide gemeenschappen moeten elkaar respecteren.Smiley.toerist (overleg) 25 mrt 2018 11:22 (CEST)

Veel infoboxen op fr.wiki (bijv. fr:Emma González) hebben juist wikidata geheel als bron, en het kan zelfs nog meer uitbegreid fr:Tour La Provence_2018. Wat is het streven voor nl.wiki. Dit of juist niet? Gaat het om het dilemma enerzijds het belang van de gebruiker, die mogelijk de codes niet begrijpt, danwel geeft men de voorkeur aan geverifieerde bronnen in een infobox. Ldhank (overleg) 25 mrt 2018 14:40 (CEST)

Van mij mag er gerust meer data uit Wikidata gebruikt worden in infoboxen, maar niet op een artikel pagina zelf. Ik zie het liever verwerkt in het sjabloon zelf, zodat het overrulen alleen maar hoeft door een waarde in te vullen in de infobox zelf. Mbch331 (Overleg) 25 mrt 2018 14:44 (CEST)

Helaas, ik ben geen programmeur. Uit esthetische overwegingen, en het streven naar wat uniformiteit ben ik infoboxen bij afbeeldingen met portret gaan toevoegen. Hierbij vond ik het gebruik van {{#property:dinges}} beter dan het foutgevoelige overtypen, en ik geef toe het geeft niet de ideale informatie. Maar indien mijn copy/paste acties niet gewaardeerd worden hoor ik het graag. Dan stop ik met de {{#property dinges}}. Overigens waarom zou je wikidata willen overrulen. Creeer je daarmee niet een extra (mogelijk niet geverifieerde) bron? Ldhank (overleg) 25 mrt 2018 15:12 (CEST)

Niet iedereen wil Wikidata bewerken. En als ze Wikidata niet kunnen overrulen zullen ze of de wijzigingen aan het sjabloon terugdraaien, zodat het sjabloon geen Wikidata meer gebruikt of gewoon het hele sjabloon weghalen. Je moet proberen die personen ook tegemoet te komen. Mbch331 (Overleg) 25 mrt 2018 15:45 (CEST)

Parserfuncties (zoals #property) zijn eigenlijk niet bedoeld voor artikelen, maar voor sjablonen. Er wordt nu wel wat mee geëxperimenteerd in artikelen, maar dat zal slechts iets tijdelijks zijn. Het gebruik van #property is niet iets wat in artikelen thuishoort, daar is het nooit voor bedoeld en zal verdwijnen. Beleid over het gebruik van Wikidata is in voorbereiding, maar dat gebruik zal dan betrekking hebben op het gebruik van Wikidata in sjablonen zelf. Zonder dit soort codes dus in artikelen. Romaine (overleg) 26 mrt 2018 05:34 (CEST)

Beleid over het gebruik van Wikidata is in voorbereiding (...) Wie, wat, waar? The Banner Overleg 26 mrt 2018 19:12 (CEST)

Ik zie wel wat in het gebruik van wikidata om lege velden in te vullen. IF empty THEN use Wikidata ELSE use local value. The Banner Overleg 26 mrt 2018 20:29 (CEST)

Dat gebeurt hier en daar al. –bdijkstra (overleg) 26 mrt 2018 20:39 (CEST)

Maak een sjabloon, bijvoorbeeld {{property}}, waardoor we het gebruik ook makkelijk kunnen bijhouden. — Zanaq (?) 26 mrt 2018 19:52 (CEST)

Of gebruik een van de bestaande sjablonen. –bdijkstra (overleg) 26 mrt 2018 20:02 (CEST)

Goed idee. (Misschien is het handig van {{property}} een redirect naar {{wikidata}} te maken). — Zanaq (?) 26 mrt 2018 20:06 (CEST)

Tech News: 2018-13

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• Some of the interface icons and text sizes will change slightly, as part of the updates for improved accessibility and consistency. These icons are used in many features, including Notifications, Recent Changes, Beta Features, Visual Editor, 2017 Wikitext Editor, Code Editor, and others. While editor toolbars, dialogs, and menus will appear slightly bigger; elements on special pages will be slightly smaller. Functionality will not change. [1] [2]
• The deprecated #toc and #toctitle CSS ids have been removed. If your wiki was still using these for fake Tables of Content (ToC) then these might lose their styling. They can be replaced with .toc and .toctitle classes where appropriate. [3]
• TemplateStyles will be deployed to the Wikivoyages on 28 March 2018. [4]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 27 March. It will be on non-Wikipedia wikis and some Wikipedias from 28 March. It will be on all wikis from 29 March (calendar).

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 27 March at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be one hour earlier than usual on 28 March at 15:00 (UTC). See how to join.

Future changes

• From 9 April, the sort order of categories will be distorted for a short time. We are upgrading versions of an internationalisation library (ICU) and using a maintenance script to update existing database entries. This will last anywhere from a few hours to a few days, depending on wiki size. Read more details. [5]
• Changes are coming to search for Serbian projects. Cyrillic and Latin variants of a word and different grammatical forms of a word will be able to find each other. Read more on MediaWiki in Serbian or English.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

26 mrt 2018 22:03 (CEST)

Flagged revisions

Een tijdje terug had ik toegezegd om de discussie over flagged revisions op te starten. (Ping Alexis Jazz) Het invoeren van flagged revisions is geopperd tijdens de peiling over het preventief blokkeren van wifi-spots en mobiel internet. Er schijnt een Engelse en een Duitse methode te zijn maar als ik het over flagged revisions spreek heb ik het over de Duitse methode.

Wat is flagged revisions precies? Momenteel zijn alle wijzigingen die gedaan worden gelijk live te zien. Bij flagged revisions zijn alleen de bewerkingen van gebruikers die een x aantal bewerkingen gedaan hebben (vertrouwde gebruikers) live. Er zijn twee groepen gebruikersrechten gemoeid met flagged revisions. Een groep van gebruikers wiens bewerkingen direct zichtbaar zijn (autopatrol) en een groep van gebruikers van wie de bewerkingen direct zichtbaar zijn en bewerkingen goed kunnen keuren (patroller). Beide groepen krijg je op de Duitstalige wiki toegewezen na een bepaald aantal bewerkingen. Ook kunnen moderatoren de rechten toekennen en afnemen. Een dergelijk systeem heeft natuurlijk een aantal voor- en nadelen.

Voordelen

• Vandalisme is niet direct zichtbaar.
• Promotioneel materiaal of niet neutraal materiaal toegevoegd aan artikelen door beginnende gebruikers en IP-gebruikers is niet direct zichtbaar.
• Ook beginnende accounts kunnen simpel nagelopen worden.
• Gebruikers die ondermaats werk leveren kan een bitje van afgenomen worden. (Die vlieger gaat zowel op voor mensen die slordig markeren als voor mensen die inhoudelijk vaak de mist in gaan.)

Nadelen

• Het is mogelijk extra werk om ook de bewerkingen van accounts na te lopen.
• Correcties door IP-gebruikers en beginnende gebruikers zijn niet meteen live.
• Toekennen en afnemen van rechten is een potentiële bron voor conflict.

Of mensen meer of minder gemotiveerd raken doordat hun bewerkingen niet direct zichtbaar zijn weet ik niet. Dat zal denk ik van de persoon afhangen. Er is een aantal vragen die ik graag wil voorleggen.

Vragen

• Ben je voor of tegen flagged revisions? (Motivatie van de mening is altijd zeer welkom!)
• Bij hoeveel bewerkingen is het billijk om iemand automatisch autopatrol en patroller toe te kennen?
• Wanneer kunnen autopatrol en patroller afgenomen worden?
• Wie kunnen autopatrol en patroller toekennen?
• Zijn er voorstanders van een testperiode/pilot?

Ik kijk uit naar de reacties! Natuur12 (overleg) 19 mrt 2018 17:22 (CET)

We hebben vermoedelijk niet genoeg capaciteit om het extra werk op te pakken. Daarnaast is de kracht van wikipedia juist dat alles meteen zichtbaar is. Verder kan het mechanisme een (vals) gevoel van betrouwbaarheid geven bij de buitenwereld: het moet duidelijk zijn dat wikipedia onbetrouwbaar is. — Zanaq (?) 19 mrt 2018 18:33 (CET)

Veel dank voor het opnieuw opstarten van de discussie Natuur12! En Zanaq, ik wil je je mening niet onthouden, en dus meer een algemene oproep: laten we denken in oplossingen, en mogelijkheden, niet in problemen. Vinvlugt (overleg) 19 mrt 2018 19:24 (CET)

Ik ben het in deze met Zanaq een en voor het tekort aan controleurs is geen oplossing. Voor het tekort aan huidige vandalismecontroleurs is al (bijna) geen oplossing te bedenken, dus laat staan als het ook nog eens gaat om het controleren van iedere bewerking. Voorlopig ben ik hier dus tegenstander van, daarom lijkt het mij ook niet nodig om de andere vragen te beantwoorden, in ieder geval niet voordat er een goede oplossing komt voor het tekort aan controleurs. Dqfn13 (overleg) 19 mrt 2018 21:24 (CET)

Het lijkt mij filteren met een zeer fijn maas waardoor veel te veel edits blijven hangen in de zeef. Als Zanaq gelijk krijgt met het capaciteitsprobleem, gaat het gigantisch mis. Het controleren van edits gaat nu al moeizaam.

Ik zie dan ook veel meer in het Engelstalige "Pending Changes" systeem, dat ingezet wordt als een lage vorm van beveiliging. Daarbij worden ook de edits van nieuwe gebruikers en IP's opgehouden, maar slechts bij geselecteerde artikelen (omstreden onderwerpen en vandalisme-gevoelige artikelen). Het recht om "pending changes" goed te keuren moet specifiek worden aangevraagd. The Banner Overleg 19 mrt 2018 21:32 (CET)

 Voor De controle op nieuwe geregistreerde gebruikers is nu zo goed als nihil. Ik heb mijn filters in 'Recente Wijzigingen' zo ingesteld dat ook bijdragen van deze gebruikers vermeld worden, naast de anoniemen. Je wilt niet weten wat er af en toe voorbijkomt: zie bijv. ook het kopje Theaterencyclopedie.nl. Met het Duitse systeem komen deze pas online nadat iemand anders ze goedgekeurd heeft en zoniet, dan niet. Scholieren zullen ook snel afhaken als ze zien dat hun geklieder niet direct online komt. Wikiwerner (overleg) 19 mrt 2018 21:40 (CET)

 Vraag Maar wat vinden de Duitstaligen ervan? Is de situatie volgens hen verbeterd? Is dat ten koste gegaan van iets? –bdijkstra (overleg) 19 mrt 2018 22:50 (CET)

Volgens mij gaat Flagged-Revisions juist werk uit handen nemen, omdat je meerdere wijzigingen in 1x kunt goed/afkeuren. En dat capaciteitsprobleem hebben we al lang, nu blijft veel zooi gewoon liggen omdat het na verloop van tijd uit het zicht verdwijnt. Mogelijk zal FR dat probleem niet geheel oplossen, maar de oorzaak ligt dan niet in FR, maar in te kort aan capaciteit. En dat moeten we toch op een andere manier tackelen dan vernieuwingen tegenhouden en verders ons hoofd in het zand steken. Edoderoo (overleg) 20 mrt 2018 11:32 (CET)

Meerdere wijzigingen in één keer goed/afkeuren? Je kan maar één wijziging tegelijkertijd zien. Controleren verlangd nu eenmaal zorgvuldigheid. Ik zie veel meer in het strenger aanpakken van vandalen en gebruikers die onevenredig slecht presteren. Dat zou een taak moeten zijn van moderatoren, maar ik zie dat nog niet gebeuren. Verplicht bronnengebruik (als over info twijfel kan bestaan) is ook een goede optie, maar ook daarvoor zal geen 55% meerderheid te vinden zijn. Happytravels (overleg) 20 mrt 2018 12:50 (CET)

sterk Voor, lijkt mij een goed plan! die "flagged revisions" vr groet Saschaporsche (overleg) 20 mrt 2018 16:15 (CET)

@Edoderoo:, hoe wil je vooruitgang maken, als er geen capaciteit is? Nogmaals: er is al een tekort aan vandalismecontroleurs, hoe wil je dan ook nog eens de gewone bewerkingen gaan controleren? Dqfn13 (overleg) 20 mrt 2018 20:17 (CET)

We kunnen zelf bepalen wie we 'autopatrol' maken, bijv vanaf een zeker aantal bewerkingen, evt. samen met een aantal weken bestaan van het account. Dit kan op een vergelijkbare manier als waarop we op aanvraag het terugdraaibitje toekennen na 3 maanden en enige ervaring met vandalismebestrijding. Wikiwerner (overleg) 20 mrt 2018 20:45 (CET)

Dan krijg je dus mensen die gaan wachten totdat zij het bitje hebben. Dat gebeurd nu al met mensen die weten dat ze 4 dagen moeten wachten voordat ze artikelen kunnen gaan hernoemen. Het is mij het afgelopen jaar zeker 3 keer overkomen dat ik als eerste actie bij een "nieuw" account een paginahernoeming zag. Dqfn13 (overleg) 20 mrt 2018 20:48 (CET)

100% foutloze systemen bestaan niet, en dat is het huidige systeem ook niet. Flagged Rev hoeft van mij niet per se, maar het hoeft ook niet per se niet. Trollen en vandalen fietsen toch wel overal doorheen, alleen zal hun impact bij Flagged Revisions iets anders zijn dan bij het huidige "alles staat online voordat iemand het zag"-methode. Edoderoo (overleg) 20 mrt 2018 22:20 (CET)

Het als goed markeren van een bewerking dient om meer redenen te gebeuren dan alleen dat het geen vandalisme is, maar ook om reden dat de informatie feitelijk juist of relevant is. Je ziet nu al dat bij onjuiste informatie vaak niet gemarkeerd wordt. Happytravels (overleg) 20 mrt 2018 22:31 (CET)

Dat lijkt me een veel te hoge lat. Als je eist dat iedereen die markeert ook alle bewerkingen inhoudelijk naloopt aan de hand van externe bronnen, houd je niemand meer over die dat kan en wil doen. Of je krijgt de situatie waar alle aanpassingen die geen makkelijk na te trekken bronvermelding hebben, 'voor de zekerheid' worden teruggedraaid. Ook dat lijkt me niet zonder meer wenselijk. Paul B (overleg) 20 mrt 2018 23:39 (CET)

Bij twijfel markeer je gewoon niet en laat je het aan iemand anders over. Er is niemand die je verplicht te markeren. En van sommige gebruikers moeten gewoon alle bewerkingen gecontroleerd worden. Zie ook reactie hier direct beneden. Happytravels (overleg) 21 mrt 2018 00:28 (CET)

Met als gevolg dat er dus een hoop wijzigingen zijn die helemaal nooit gemarkeerd worden. Dat maakt het onnodig moeilijk voor de vandalismecontroleurs, die nu al alle zeilen bij moeten zetten om alle wijzigingen op vandalisme na te lopen. Wat jij voorstelt is niet werkbaar, en komt niet overeen met de huidige praktijk. Paul B (overleg) 21 mrt 2018 20:28 (CET)

Het systeem 'flagged revisions' lijkt mij meer voordelen dan nadelen te hebben: vandalisme wordt erdoor ontmoedigd en de gemiddelde kwaliteit van de artikelen zal toenemen. Een testperiode van bv. een half jaar lijkt me prima. Los hiervan is mijn vraag of er richtlijnen zijn voor 'markeren als gecontroleerd' (wat we nu ook al hebben). Zelf markeer ik alleen als gecontroleerd als ik zeer sterk overtuigd ben dat de wijziging klopt (dus niet te snel iets markeren als gecontroleerd), maar ik vraag me af of er richtlijnen voor bestaan. Die richtlijnen zullen vanzelfsprekend ook van belang zijn bij 'flagged revisions'. Bob.v.R (overleg) 21 mrt 2018 00:08 (CET)

Ben al heel lang  voor het invoeren van flagged revisions, vooral omdat vandalisme niet direct zichtbaar wordt en dit waarschijnlijk vandalen (op den duur) zal ontmoedigen, de helaas vaak ondeskundige en slechte bewerkingen van absolute beginners evenmin direct zichtbaar worden, en bijvoorbeeld overhaaste toevoegingen (voetballer A zit nu bij club B, hoewel het contract mogelijk pas over twee weken wordt getekend) hopelijk doet afnemen. Flagged revisions zijn in het bijzonder ook een zegen voor gevoelige lemma's over pas overledenen, die immers grote bezoekersaantallen trekken en niet mogen worden ontsierd, gevandaliseerd of verprutst. ErikvanB (overleg) 21 mrt 2018 00:07 (CET)

Sorry dat ik weer het woord neem, maar ik vermoed dat bij 'flagged revisions' goedwillende nieuwelingen zich geremd gaan voelen om veel te gaan bijdragen als ze hun aanpassingen niet meteen verwerkt zien worden. Op de Duitse Wikipedia wacht ik wel eens dagen voordat iemand de moeite neemt een wijziging te controleren, voor mij een reden om er niet vaak te komen. Mocht het systeem voortgang vinden, dan zouden ook ervaren gebruikers die aangetoond hebben goed te presteren de mogelijkheid moeten krijgen om bewerkingen van nieuwelingen automatisch te laten markeren en dat hoeft echt niet na een bepaald aantal bewerkingen. Als je dat alleen aan moderatoren over laaat, dan gaat het niet werken. Daar zijn er voor zoiets veel te weinig van. En nu naar bed. Happytravels (overleg) 21 mrt 2018 00:43 (CET)

Trusten! (maar te laat, vrees ik...) ErikvanB (overleg) 21 mrt 2018 01:58 (CET)

Tegen ErikvanB kan niemand op. Wikiwerner (overleg) 21 mrt 2018 19:26 (CET)

Het niet 'live' laten zien van alle wijzigingen heeft misschien ook een nadeel. Als ik als ervaren bewerker de artikelen lees zonder controleeroogmerk, zie ik dan volledige versie of de gezuiverde versie? Vaak kom ik namelijk als ik iets opzoek, dingen tegen die fout zijn. Dat kan ik dan gelijk aanpakken. Daarom wil ik altijd de volledige versie zien en niet een knop moeten omzetten 'nu ga ik controleren'. Voor wat het markeren betreft: In principe is het beter alleen onderwerpen te markeren waarvan men kennis over heeft. Dan hoef je geen tijd te besteden met uitgebreid bronnenonderzoek. Bij een twijfelgeval ga ik de vermelde bron wel nakijken voor de zekerheid. Zelfs de experten weten niet alles. Duidelijk vandalisme en taalfouten kan iedereen terugdraaien. Ik markeer wel zonder diepgaand onderzoek bij bewerkers die ik vertrouw op hun gebied. Hiermee heb je meer tijd voor andere wikipediawerkzaamheden. Ik apprecieer het werk van de anoniemencontrole. Ik raak echter snel gedemotiveerd als ik artikelen moet controleren waar ik geen kennis van heb en daardoor uitgebreid moet gaan onderzoeken of de wijziging wel klopt. Er komen echter genoeg anonieme wijzigingen voor op mijn grote volglijst en daar hiermee draag ik mijn steentje bij.Smiley.toerist (overleg) 21 mrt 2018 10:58 (CET)

Een controleur/gevestigde gebruiker ziet altijd de laatste versie, met de mogelijkheid deze "af te vinken". Een niet ingelogde/nieuwe gebruiker ziet altijd de laatste afgevinkte versie. Hierdoor weet je zeker dat gewone lezers niet per ongeluk tegen nog niet gezien vandalisme aan kunnen lopen. Maar omdat niet alle ongeflagde wijzigingen vandalisme zijn, zien "anoniemen" dus ook vaak niet de allerlaatste versie, en missen ze mogelijk informatie. Nu mag je er vanuit gaan dat veel bezochte artikelen ook best snel geflagged zullen worden, maar dat is wel het nadeel dat je met het voordeel van "minder vandalisme" krijgt. Ieder voordeel heb se nadeel zei van Hanegem ooit. (of was dat andersom) Edoderoo (overleg) 21 mrt 2018 12:24 (CET)

Nee, dat was Johan Cruijff! Wikiwerner (overleg) 21 mrt 2018 19:26 (CET)

En Van Hanegem claimt nu deze woorden als de zijne. Dqfn13 (overleg) 22 mrt 2018 12:50 (CET)

Dat is natuurlijk een uiterst kromme redenering van De Kromme. Waarschijnlijk riep men al eeuwen voor Van Hanegem dat je je best zou moeten doen om "uit een nadeeltje een voordeel" te halen. Cruijff – en dus niet Van Hanegem – heeft die afgezaagde, lusteloos geformuleerde gedachte echter vertaald in een kernachtige, dwingende, algemene geldigheid suggererende oneliner: "Elk nadeel heb zijn voordeel." Het is alsof Wim Kok claimt dat hij eigenlijk de geestelijk vader van de gevleugelde uitdrukking "Geen gezeik, iedereen rijk" is, omdat hij ergens in de jaren zeventig, tijdens eindeloze vakbondsonderhandelingen, al eens gezegd zou hebben: "Misschien zouden we niet zo veel moeten praten, maar zou iedereen gewoon wat meer geld in zijn portemonnee moeten hebben." Ja duh! Matroos Vos (overleg) 22 mrt 2018 15:11 (CET)

Elke oplossing heeft een probleem...Je kunt natuurlijk afspreken, dat via een of ander kriterium wijzigingen niet eeuwig verborgen blijven, maar dat zijn de details van de implementatie. Voor een heldere discussie of het opzetten van een peiling zou ik het principe van flagged revisions van de details van de implementatie scheiden. Maar goed, een kroegdiscussie is ook een manier om zichtbaar te maken welke parameters evt. een rol spelen. @Natuur: Hou je ergens een lijstje bij van de geopperde stelschroeven? Ik kan me goed voorstellen, dat flagged revisions niet alleen ja/nee worden ingevoerd, maar dat we na een paar keer (b.v. na 3 en 6 maanden) kijken of aan bepaalde deelproblemen tegemoet kan worden gekomen zonder kind en badwater gelijk weer weg te gooien.

Wie weet of de Duitse wiki geevalueerd heeft hoe "Gesichtete Versionen" bevallen? Zwitser123 (overleg) 21 mrt 2018 13:16 (CET)

Heeft het bewezen voordelen? Wat gebeurt er na de introductie? Is er minder vandalisme? Minder animo om dat te controleren? (Ik zag een Russisch artikel - niet dat ik het verstond - dat na een jaar nog niet gecontroleerd was) Minder animo om te schrijven als het toch niet direct zichtbaar is? (Dat heb ik wel als ik kan reageren onder krantenartikelen/weblogs) Afhakende lezers? (eerst al banners en nu nog meer niet-relevante zaken in beeld - daarom zijn addblockers ook zo populair, dat wil een lezer niet) enz. enz. Voordat over zoiets ingrijpends gestemd wordt zal er met feiten uit betrouwbaren onderzoeken over de brug gekomen moeten worden. Ymnes (overleg) 21 mrt 2018 20:07 (CET)

En nu? Dit overleg archiveren voor de volgende generatie zeker? ErikvanB (overleg) 25 mrt 2018 03:20 (CEST)

Daar lijkt het wel aardig op ja, zoals wel vaker: hoop discussie, geen initiatief, geen handeling en we gaan dus weer gewoon verder waar we mee bezig waren. Dqfn13 (overleg) 25 mrt 2018 20:30 (CEST)

Ergens een vervolg aangeven is alleen nuttig als er kans is op enige consensus. Doordat de-wiki al zo lang met flagged rivisions werkt is het ook lastig om te achterhalen of wat ze eerst hadden nu wel of geen verbetering is want tenzij iemand ergens een onderzoekje heeft gedaan zal het blijven bij het opschrijven van herinneringen van 10 jaar terug. Ik zou een peiling kunnen proberen op te zetten maar over de opzet ervan zal ik wel goed moeten nadenken. Het is allemaal wat ingewikkelder dan voorleggen of we we wel of geen sleepnetblokkadades willen om het maar zo te zeggen. Natuur12 (overleg) 26 mrt 2018 16:30 (CEST)

Tja, wat hadden wij voor Markeer als gecontroleerd, waarvan de eerste versie dateert van 2009. Volgens mij hadden wij voordien niks, dus misschien hadden de Duitsers voordien ook wel niks. Wikiwerner (overleg) 26 mrt 2018 20:19 (CEST)

Uitleg over het Duitse systeem staat op de:Wikipedia:Gesichtete Versionen. het blijkt dat ze er al sinds 2008 mee werken. Gek genoeg is er ook een Nederlandse interwiki: Wikipedia:Nagelopen versies. Het blijkt dat de Duitsers het vooral gebruiken zoals wij gebruikmaken van het 'markeren als gecontroleerd', dat wij als een van de weinige wiki's hebben. Je eigen bewerkingen zie je nog steeds direct live, maar de doorsnee lezer niet. Hierdoor is er nog steeds de huidige lage drempel om te bewerken. Een beginner heeft immers niet direct door dat anderen diens bewerking nog niet zien. Wikiwerner (overleg) 25 mrt 2018 21:23 (CEST)

Voorspelbaar: ik ben voor. Na een poosje evalueren is dan wel een goed idee. (allicht dus ook al voor de invoeren statistieken verzamelen om die te kunnen vergelijken met na de invoering) Gedeeltelijk invoeren is ook een overweging als dat technisch mogelijk is. @Ymnes: Een artikel dat na een jaar nog niet is gecontroleerd is niet handig nee. Een overweging kan zijn om wijzingen na b.v. 1 maand een derde status te geven, niet "gecontroleerd" maar de wijziging wel zichtbaar maken voor het publiek. Als het duidelijk vandalisme was geweest was het waarschijnlijk allang gespot. Alexis Jazz (overleg) 27 mrt 2018 08:34 (CEST)