Wikipedia:De kroeg/Archief/20221103

Nieuwe artikelen: gebruikers afremmen

Is het technisch mogelijk om gebruikers af te remmen bij het aanmaken van artikelen?

Mogelijkheden (te lezen als en/of):

• Maximaal 1 per uur
• Maximaal 10 per dag
• Maximaal 150 per maand

Over de perioden en snelheden valt te praten en wie offline een reeks artikelen klaar heeft gezet kan ontheffing krijgen, wie aantoonbaar snel en toch goed werkt ook  →bertux 17 okt 2022 12:23 (CEST)

In sommige gevallen gewenst inderdaad. Maar waarom offline? Kan ook in de gebruikersruimte dunkt mij. Wellicht kan het binnen de huidige kaders al gerealiseerd worden door personen die teveel en te snel na elkaar kleine edits doen een hoofdnaamruimteblokkade te geven tot dat er geschikte bijdragen geschreven zijn in het kladblok. In zo'n situatie lijkt me een vergelijkingsoptie (diff) wenselijk tussen twee verschillende pagina's (artikel - kladblok), wellicht bestaat zoiets ook al op Toolforge. Hoe dan ook, het zal nooit een garantie kunnen geven dat men ook echt prettiger (in dit opzicht) gaat bijdragen nadat ze de grenswaarde van dergelijke regelzucht gepasseerd zijn. Démarche Modi (overleg) 17 okt 2022 12:32 (CEST)

Zowel aan de 1 per uur of 10 per dag kom ik al eens. De 150 per maand dat zijn maar een handvol gebruikers die daar aan komen waarvan het merendeel zich bezighoudt met dierenartikels. Voor welk probleem zoeken we precies een oplossing? Themanwithnowifi (overleg) 17 okt 2022 12:37 (CEST)

Misschien is een andere oplossing beter: het strikt verbieden van het ongezien vertalen van een anderstalige Wikipedia. Dat je absoluut verplicht ben om alle overgenomen informatie te controleren op inhoudelijke juistheid. Dát maakt het domweg onmogelijk om heel veel lemma's aan te maken. Het record dat ik van één bijdrager ooit zag was 23 vertaalde lemma's op een dag, en de dag was toen nog lang niet om. Dat strikt controleren dient ook te gebeuren voor Wikidata-gegevens. HT (overleg) 17 okt 2022 12:43 (CEST)

Nou TMWNW, #Vertalingen vaak beroerd, wat te doen? en Wikipedia:De Nulmeridiaan#Kamojang en mensen die vol trots vermelden dat ze 40.000 artikelen hebben geschreven zonder aan te geven dat minstens 20.000 daarvan de collega's handenvol correctiewerk bezorgen en verder ook en vooral de Nalooplijsten waar nog vele honderden *tienduizenden* artikelen van snelschrijvers staan te wachten  →bertux 17 okt 2022 12:45 (CEST)

HT, dat is niet af te dwingen en pakt alleen maar een deel van de probleemgroep aan. Een rem moet technisch mogelijk zijn, zodat de zorgvuldige gebruikers niet verplicht zijn om kleuteroppas te spelen. In elk geval kun je het vertaalaspect beter inbrengen bij #Vertalingen vaak beroerd, wat te doen?. Ik ben dit kopje juist begonnen om het ruimer te trekken dan vertalingen  →bertux 17 okt 2022 12:50 (CEST)

@Démarche Modi: Sommige gebruikers werken offline omdat ze onze gebruikersinterface niet prettig vinden of de boel meteen opslaan in een persoonlijk archief  →bertux 17 okt 2022 12:56 (CEST)

Ja, voor de offline wens kan ik wel begrip opbrengen. Wat we ook doen, we kunnen nooit controleren wat iemand offline doet. Er zal altijd een moment van 'binnenkomst' zijn, van die invoer willen we de kwaliteit waarborgen en dat kan - uiteindelijk - alleen maar door de ongewenst slechte bijdragers eruit te filteren. Althans, voor zover ik de ins en outs van ons project goed begrepen heb. Een van de belangrijkste pijlers is dat iedereen bij mag dragen. Door daar op voorhand een limiet op te zetten gaat volgens mij in tegen ons oerprincipe. Démarche Modi (overleg) 17 okt 2022 13:13 (CEST)

@DM: Nee hoor. Een hoog tempo gaat in 99% van de gevallen ten koste van de kwaliteit en die willen we bewaken. TBP, blokkades, vormeisen en het verbod op open proxy's zijn allemaal zaken waarmee we er in de praktijk voor zorgen dat niet iedereen kan bijdragen. Juist is: iedereen die binnen de lijntjes wil kleuren kan bijdragen. Zelfs voor iets riskants als open proxy's zijn bij dwingende redenen ontheffingen mogelijk

Nieuwe gebruikers die na verloop van tijd dit tempo halen bij goede kwaliteit kunnen altijd ontheffing vragen  →bertux 17 okt 2022 13:26 (CEST)

Louter de proxyblokkade is een voorbeeld dat men niet in staat is om bij te dragen. Die druist inderdaad in tegen dat principe maar is helaas te rechtvaardigen vanwege de hoeveelheid vandalistische bijdragen uit het verleden. De andere voorbeelden volgen op wat een bijdrager heeft gedaan. Wat jouw voorstel betreft ben ik voorstander om te reageren met bestaande maatregelen in plaats van het toevoegen van een nieuwe, zo'n limiet. Maar goed, dat is slechts mijn mening. Wellicht denkt de gemeenschap er anders over omdat het probleem toch groter is dan ik vermoed. Démarche Modi (overleg) 17 okt 2022 14:20 (CEST)

Er wordt vaak geroepen (zoals hierboven door @Démarche Modi) dat bijdragen van proxy-gebruikers zo slecht zouden zijn, maar op de Wikimania van 2019 werd een presentatie over TOR-gebruikers verzorgd, gebaseerd op kwalitatief en kwantitatief onderzoek. De uitkomst van het kwantitatieve onderzoek was duidelijk: while TOR might not be on par with registered users, but similar to IP and first-timers, so TOR editors are bright lights that should be nurtured. Juist op onderwerpen die gevoelig kunnen zijn (geloof, politiek, niet-standaard seksuele voorkeuren,...) schreeuwen gebruikers om mogelijkheden om zo veilig mogelijk bij te dragen aan het delen van kennis. Niet iedereen leeft in een land waar je voor je mening, je gedachten mag uitkomen, en niet iedereen leeft in omstandigheden waarin dat veilig kan. Verder van huis zijn dat onderdrukkende regimes, maar wat te denken van een niet-heteroseksuele jongere in een gereformeerd of islamitisch gezin in Nederland? Blokkades zijn bedoeld als bescherming van de encyclopedie, en zouden als zodanig ingezet moeten worden als daar gronden voor zijn (op basis van het vertoonde gedrag). Het in een tijd waarin steeds meer mensen ervoor kiezen om via hun mobiel te bewerken vooraf blokkeren van ranges van mobiele providers omdat de afzonderlijke IP-nummers misschien wel uitgedeeld kunnen worden aan wisselende gebruikers, past niet bij het open karakter van Wikipedia. Met vriendelijke groeten, RonnieV (overleg) 21 okt 2022 21:01 (CEST)

@RonnieV, je verdraaid mijn woorden. Het enige dat ik deed was reageren op Bertux' argumenten waarbij de proxy blokkade het enige voorbeeld is dat vooraf inbreng tegen wordt gegaan. Nota bene helaas en volgens mij met een reden. Verder heb ik mijn vraagtekens bij je bijdrage, maar die hou ik verder maar even afzijdig. Démarche Modi (overleg) 21 okt 2022 21:25 (CEST)

@Démarche Modi, jij geeft aan dat proxy-blokkades te rechtvaardigen zijn vanwege de hoeveelheid vandalistische bijdragen uit het verleden. Uit serieus onderzoek is gebleken dat de bijdragen vanaf proxy's kwalitatief vergelijkbaar zijn met de bijdragen van niet-ingelogde bewerkers en van beginnende bewerkers. Daarmee valt in mijn ogen de onderbouwing van deze blokkades vooraf weg. Ja, er zijn proxy-aansluitingen die misbruikt zijn om Wikipedia te spammen, maar er zijn ook bewerkers met accounts die Wikipedia schaden. In beide gevallen kan een blokkade na aangetoond wangedrag een bescherming zijn, al geldt in het geval van een blokkade van een dynamisch IP-adres dat je daarmee ook anderen het bewerken onmogelijk kan maken. Dat geldt nog meer bij het blokkeren van ranges louter omdat er een adres in die range zit die over de schreef is gegaan. Dat account kan je wel blokkeren zonder dat anderen daar last van hebben. Al is het aanmaken van een nieuw account ook een mogelijkheid om Wikipedia weer te bewerken. Met vriendelijke groet, RonnieV (overleg) 21 okt 2022 21:57 (CEST)

Wellicht heb ik mijn woorden onvoldoende goed gekozen maar jouw oordeel over mijn woorden zit er naast. Zo was 'helaas gerechtvaardigd' mogelijk beter geweest. Het is niet mijn rechtvaardiging maar die van de gemeenschap of de mods. Ik ben nota bene zelf een bijdrager die vaak achter zo'n proxy zit en kan dan alleen ingelogd bijdragen. Démarche Modi (overleg) 21 okt 2022 23:04 (CEST)

@Démarche Modi: op Speciaal:Diff kan je revisienummers invullen van willekeurige pagina's. –bdijkstra (overleg) 17 okt 2022 13:51 (CEST)

Zoals gezegd, beginnen met stoppen met het agressief promoten van de vertaaltool d.m.v. een popup. Nieuwe gebruikers kunnen daar sowieso niet mee omgaan en ervaren gebruikers maken er sowieso geen gebruik van of weten hem toch wel te vinden. Idealiter gewoon afschaffen. Direct gebruik van Google Translate is sowieso een efficiëntere methode. Google is natuurlijk een controversieel bedrijf met stuitende wereldmacht, maar ik wed dat vertaaltools er allemaal gebruik van maken. Wickey (overleg) 17 okt 2022 13:24 (CEST)

De pijlers 'iedereen mag bijdragen' en 'we willen kwaliteit leveren' botsen al vanaf het begin van dit project. Ik zie het voorstel van Bertux als een poging om een nieuwe afweging te vinden en een mechanisme om dit vorm te geven. Een combinatie van een ontmoedigingsbeleid, met name voor vertalingen, te sanctioneren limitering (zoals Bertux voorstelt, en Wickey ook min of meer) en een of andere stimulans of kader, bijvoorbeeld op de welkomstpagina en verbeterlijst te benadrukken (ja leuk dat je schrijft, maar denk eraan dat het ook leuk moet zijn om te lezen en te onderhouden) lijkt me de beste zoekrichting. Schrijfplezier, leesplezier en onderhoudsplezier verdienen gelijke aandacht. mvg HenriDuvent 17 okt 2022 13:28 (CEST)

@Wickey: Dit kan beter verplaatst naar #Vertalingen vaak beroerd, wat te doen?, zie mijn antwoord aan HT  →bertux 17 okt 2022 13:29 (CEST)

Kunnen we niet beter voor elk nieuw artikel eerst een stemming en een fiatterings-comité optuigen? En een commissie om tegen de uitslag beroep aan te tekenen? Urinoise (overleg) 17 okt 2022 16:10 (CEST)

Ja, dan gaan we gewoon Nupedia uit de mottenballen halen. Dat kreeg in drie jaar tijd 25 artikelen klaar, van een onberispelijke kwaliteit. Maar als de lezer toevallig iets te weten wil komen over een ander onderwerp dan een van die 25, dan heeft hij pech, en moet een paar eeuwen wachten totdat zijn/haar onderwerp aan bod is gekomen. Erik Wannee (overleg) 17 okt 2022 16:48 (CEST)

Urinoise, zie Stropopredenering  →bertux 18 okt 2022 00:06 (CEST)

Hoezo stropopredenering, Bertux? Erik Wannee heeft gewoon gelijk dat Urinoise's idee niet nieuw is en jammerlijk gefaald heeft. Jcwf (overleg) 18 okt 2022 01:33 (CEST)

Maar Urinoise bedoelt het zo te lezen niet als serieus idee, maar als karikaturale overdrijving van de inbreng van Bertux. Encycloon (overleg) 18 okt 2022 10:31 (CEST)

Ik ben voorstander voor een limiet aan het aantal aan te maken artikelen op een dag – waar bepaalde gebruikers na bewezen bekwaamheid eventueel het recht krijgen over die grens heen te gaan – en voor het ontmoedigen van het gebruik van de vertaalmodule. Wat betreft dat laatste kunnen we ervoor kiezen deze verder weg te stoppen, vertalingen eerst in een aparte controlelijst zetten voordat ze in de hoofdnaamruimte terecht komen en/of technische aanpassingen doen die maken dat je gedwongen wordt een integrale tekst materieel aan te passen, dat vereist wat extra onderzoek. Ik volg dus de lijn die HenriDuvent hierboven oppert. StuivertjeWisselen (overleg) 18 okt 2022 10:24 (CEST)

Met een limiet is de encyclopedie niet gebaat. Ymnes (overleg) 18 okt 2022 15:30 (CEST)

Met een limiet verhinder je de massaproductie van ondermaatse artikelen die de gemeenschap onder zware druk zetten  →bertux 18 okt 2022 15:34 (CEST)

Ik snap wel waarom je dat zegt, echter is de huidige situatie waarbij de encyclopedie met ondermaatse inhoud wordt gevuld door snelschrijvers wat mij betreft schadelijker dan de afschrikwekkende werking die het mogelijk op collega's heeft. Daarnaast, 99% van de gebruikers wordt door dit soort limieten helemaal niet geraakt. StuivertjeWisselen (overleg) 18 okt 2022 15:38 (CEST)

Los van de vraag of een limiet zich verdraagt met onze uitgangspunten, ons grootste probleem is niet de aanmaak van nieuwe lemma's maar de bestaande lemma's. We hebben er nu 2,1 miljoen. Ruim geschat zijn daarvan 100.000 acceptabel of beter, dat impliceert dat er 2 miljoen serieus aandacht nodig hebben. Dat is de druk waaronder de gemeenschap gebukt gaat (al meer dan 10 jaar). Het invoeren van een limiet veranderd daar niets aan. Peter b (overleg) 18 okt 2022 15:50 (CEST)

Peterb, het is helemaal niet waar dat de kwaliteit hier echt zo slecht is. Wat een schromelijk overdrijving. Reageer liever op de kwaliteit van commentaar hier vaak in de kroeg. Waarom wordt die niet vaker aan de kaak gesteld? Ymnes (overleg) 18 okt 2022 17:20 (CEST)

Ik geloof ook niet dat het daadwerkelijk zo bar en boos is Peter b. Los daarvan, deze druk wordt alleen maar groter als we de poorten open laten staan voor allerhande nieuwe artikelen, dat voelt in mijn ogen dan toch als dweilen met de kraan open. Dus ongeacht wat we met bestaande artikelen gaan doen lijk het me zinvol om te kijken hoe we ongewenste aanwas van onze encyclopedie kunnen voorkomen. StuivertjeWisselen (overleg) 19 okt 2022 15:28 (CEST)

Het is vrees ik erger dan jullie je kunnen voorstellen. Neem deze categorie. Op zich niets principieels tegen beginnetjes (of zaadjes zoals collega Jcwf ze hieronder noemt). Maar dan wel onder de voorwaarde dat de tenminste drie feiten die genoemd worden in ieder geval kloppen, en dat is bij een hele grote groep van deze 785.354 lemmaatjes waarschijnlijk niet het geval. Peter b (overleg) 19 okt 2022 15:39 (CEST)

Ik denk ook dat het veel erger is dan de meeste collega's zich kunnen voorstellen. De controle schiet hier echt zeer ernstig tekort. De optimistische gedachte dat een slecht artikel automagisch beter wordt doordat collega's zo'n artikel oppoetsen deel ik niet. Ik herinner me een artikel dat bekroond was in een schrijfwedstrijd. Men mag toch aannemen dat de leden van de jury daar uiterst kritisch naar hadden gekeken. Toch haalde ik er na de bekroning nog talloze fouten uit. Sterker nog: een fout die ik destijds heb laten zitten staat er bijna tien jaar later nog steeds in. Muijz (overleg) 26 okt 2022 23:21 (CEST)

Het klopt dat de druk vooral veroorzaakt wordt door de bestaande matige of beroerde lemma's, maar daarom zou ik graag de aanwas van beroerde lemma's remmen. Sommie (jonge) gebruikers kunnen gauw z'n 20 artikels per week maken, hup taalmachine in, plaatsen maar. Sommige van deze gebruikers blijken best gevoelig te zijn voor zachte sturing, mvg HenriDuvent 18 okt 2022 16:57 (CEST)

Een limiet is tamelijk arbitrair, maar kan werken als je het combineert met een maximaal aantal bytes per artikel. Korte artikelen kun je immers redelijk snel opzetten zonder op kwaliteit in te boeten, voor een lang artikel heb je dagen of zelfs weken nodig. In het laatste geval kun je dus nooit meer dan één artikel fabriceren, tenzij buiten de hoofdnaamruimte voorbereid.

Het idee van StuivertjeWisselen om specifiek vertalingen eerst ter goedkeuring in een tussenruimte te plaatsen is interessant. Te vergelijken met het systeem van 'markeren als gezien'. Daarbij komt, dat de tijd al lang voorbij is dat er behoefte is aan zoveel mogelijk nieuwe artikelen. Wickey (overleg) 18 okt 2022 15:58 (CEST)

Ik meen dat de Duitstalige Wiki zo werkt. Erik Wannee (overleg) 18 okt 2022 17:10 (CEST)

Ik voel zelf niet voor een systeem waarbij mensen worden ontmoedigd om veel artikelen aan te maken. Het gaat immers niet om het aantal maar om de kwaliteit. Als iemand het voor elkaar krijgt om veel goede artikelen in korte tijd aan te maken, bijvoorbeeld omdat hij de hele dag niets anders te doen heeft, dan mag diegene dat gewoon doen. Ik pleit eerder voor een systeem waarbij iemand die aangetoond heeft te weten hoe je een deugdelijk artikel maakt, het vertrouwen krijgt om ongecontroleerd artikelen aan te maken. Dat vertrouwen moet je dan wel eerst verdienen, bijvoorbeeld door tenminste x artikelen aan te maken die zonder onderbreking 'goedgekeurd' zijn. Elk deugdelijk artikel levert een punt op. Als er een ondeugdelijk artikel tussen zit, levert dat een flink aantal 'strafpunten' op. Zodra je zo een negatieve score hebt opgebouwd, kun je een bepaalde periode geen artikelen meer aanmaken.

Uiteraard zitten daar de nodige haken & ogen aan, want hoe bepaalt welke persoon hoeveel strafpunten moeten worden uitgedeeld? Het is dan ook maar een proefballonnetje. Erik Wannee (overleg) 18 okt 2022 17:32 (CEST)

Je zou iemand een tijdelijk verbod op het aanmaken van nieuwe artikelen kunnen opleggen wanneer er een x-aantal artikelen per maand van de hand van diegene op TBP belandt. Dat is een objectief meetbaar criterium en treft heel gericht alleen degenen die je daadwerkelijk wilt beperken. Om te voorkomen dat er persoonlijke vetes uitgevochten worden, zouden die artikelen dan wel door minstens twee verschillende collega's genomineerd moeten zijn. — Matroos Vos (overleg) 18 okt 2022 22:56 (CEST)

(algemene reactie op het concept van creatie-limieten) Voor we ingewikkelde regels gaan invoeren... kunnen we voor een nieuwe regel een inschatting doen hoe vaak iemand daar tegenaan zou lopen per jaar (en hoe vaak dat ook echt gewenst is dat die persoon wordt tegengehouden) en of dit de efficiëntste manier is om daar op te reageren, voor we een nieuwe bureaucratie inrichten? Als het nodig is, heb ik er niet direct bezwaar tegen, maar het moet wel de moeite waard zijn. -- Effeietsanders (overleg) 18 okt 2022 23:13 (CEST)

@Gebruiker:Effeietsanders: Even nagekeken voor 2022 (rekening houdend met meer dan 150 artikelen in 1 maand zoals hierboven wordt voorgesteld): 9 gebruikers voldeden hieraan in 2022 voorlopig. Daarbij zitten zes gebruikers die dit maar in 1 maand haalden (Supershift, Sb008 (gestopt), Taketa, Themanwithnowifi, Micnl, Kvdrgeus) en de overige drie daar zitten 2 gebruikers (Rudolphous en FrankB157) bij die enkel over diertjes schrijven en 1 die over muziek en diertjes schrijft (Der Belsj). – De voorgaande bijdrage werd geplaatst door Themanwithnowifi (overleg · bijdragen)

Tech News: 2022-42

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

Recent changes

• The recently implemented feature of article thumbnails in Special:Search will be limited to Wikipedia projects only. Further details are in T320510. [1]
• A bug that caused problems in loading article thumbnails in Special:Search has been fixed. Further details are in T320406.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 October. It will be on non-Wikipedia wikis and some Wikipedias from 19 October. It will be on all wikis from 20 October (calendar).
• Lua module authors can use mw.loadJsonData() to load data from JSON pages. [2]
• Lua module authors can enable require( "strict" ) to add errors for some possible code problems. This replaces "Module:No globals" on most wikis. [3]

Future changes

• The Beta Feature for DiscussionTools will be updated at most wikis. The "reageren" button will look different after this change. [4]

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

MediaWiki message delivery 17 okt 2022 23:45 (CEST)

Peli, er is gewerkt aan de problmen die je noemde bij #Commons thumbs gebroken. Hopelijk heeft het geholpen  →bertux 18 okt 2022 00:13 (CEST)

Hoi Bertux, de hiaten/ drop outs blijven nog in thumb display van lange lijsten. Net nog getest met een andere pc. Raar dat alles wel correct laadt in categorie overview en daarna exact dezelfde items gezocht in special search en sommige tonen zich niet in de tabel of lijst. Lange tabel laadt niet snel, dat weten we ondertussen wel. mvg Peli (overleg) 18 okt 2022 00:58 (CEST)

Als Tech News meldt dat een bug gefixt is in de MediaWiki-software, dan betekent dit dat de bugfix meekomt met de aankomende software-update. Voor deze wiki komende donderdag Californische tijd. –bdijkstra (overleg) 18 okt 2022 17:26 (CEST)

Jan van Luxemburgprijs

De gemeenschap achter de Nederlandstalige Wikipedia is genomineerd voor de Jan van Luxemburgprijs. Deze prijs is ingesteld ter nagedachtenis aan de literatuurwetenschapper Jan van Luxemburg (1936-2012), die mensen wist te inspireren om te lezen. Het Jan van Luxemburgprogramma, dat de prijs toekent, heeft als doel om mensen en programma’s voor het voetlicht te brengen die aanzetten tot lezen en tot liefde voor literatuur.

De nominatie van de Wikipediagemeenschap is als volgt gemotiveerd:

“[Wikipedia] is zo vanzelfsprekend geworden dat velen de onschatbare waarde ervan niet eens inzien. Belangrijk is dat je antwoord krijgt op je vragen, maar net zo waardevol is dat je via de links antwoorden krijgt op vragen die je niet eens bewust hebt gesteld./.../ Wikipedia draagt zo veel bij aan het leesplezier. En vergeet niet dat het vrijwilligers zijn die al die kostbare informatie toegankelijk maken.”

Meer informatie over de nominatie op de website van het Jan van Luxemburgprogramma. Sandra Rientjes - Wikimedia Nederland (overleg) 12 okt 2022 11:33 (CEST)

Goh, wat leuk. Ik had nog nooit van die prijs gehoord en blijkbaar heeft Wikipedia: dat ook niet, althans, niet op moment dat ik dit berichtje schrijf. Dqfn13 (overleg) 13 okt 2022 09:35 (CEST)

(Of een redirect naar hier.)

Terzijde: we maken ook nog kans op de titel Website van het Jaar in de categorie 'Educatie en opleiding'. Encycloon (overleg) 13 okt 2022 16:32 (CEST)

Willen we een Website van het Jaar worden als je flink moet zoeken naar de criteria en redenen voor de voorselectie? De prijs voor Verkiezing van het jaar zullen ze niet winnen.

Gevonden, in de reglementen: De grootste websites uit de Top 100 lijst van Alexa en Similarweb. Wij zullen er dus nog wel wat jaartjes in staan.

Wel leuk, in de FAQ: De opmerkingen van de stemmer worden gedeeld met de genomineerde website na de stemperiode. Hoop dat WMF of WNL ons een inkijkje wil geven  →bertux 13 okt 2022 23:45 (CEST)

Ha, da's een aardige verrassing! Ik heb nog college gelopen bij dhr. J.J.H. van Luxemburg, zoals hij in mijn aantekeningen van destijds wordt aangeduid. Docenten gingen toen nog voornaamloos door het leven. Ik vond net zelfs nog een oud tentamenbriefje met zijn zwierige handtekening, en een uitermate aangenaam cijfer. 't Was inderdaad een buitengewoon belezen en zeer inspirerend man. Het zou natuurlijk mooi zijn als we deze prijs in de wacht slepen, alhoewel ik vermoed dat de andere twee genomineerde initiatieven het prijzengeld vast veel beter kunnen gebruiken... — Matroos Vos (overleg) 21 okt 2022 00:14 (CEST)

De tekst/uitleg bij de nominatie ben ik het zeker mee eens. Ik vind het dan ook treurig dat (zoals ik eerder heb gezegd), als ik in mijn omgeving vraag of mensen bij willen dragen aan WP, ik meestal een reactie krijg als "tijdverspilling", terwijl iedereen er gretig gebruik van maakt. Schilbanaan (overleg) 27 okt 2022 13:54 (CEST)

Twijfel over verdelen in meerdere artikelen

Chemotherapieschema R-CVP en anderen zijn varianten van R-CHOP, en ik heb de meestvoorkomende ondergebracht op CHOP. Als ik met Google naar R-CVP zoek, is CHOP pas het 12de resultaat. Ik ben hier eigenlijk niet tevreden mee en patiënten die op zoek zijn naar info over R-CVP zal het een worst wezen dat het een mildere CHOP is (het is ook een ander schema) en wellicht ook niet weten, en daarom ook CHOP niet eens openen als ze via Google zoeken. De artikelen over de ziekten verwijzen wel naar CHOP en er zijn redirects. Zo laten of RCVP een eigen pagina geven? Suggesties? Schilbanaan (overleg) 26 okt 2022 14:20 (CEST)

Zo ben ik er ook niet blij mee dat op Ziekte van Hodgkin een halve kopie staat van Ann Arbor-stadiëring, terwijl artikelen over andere lymfomen gewoon een interwiki hebben. Schilbanaan (overleg) 26 okt 2022 14:28 (CEST)

Nou heb ik hier echt de ballen verstand van, dus ik geef een advies met voorbeelden van mijn eigen hand. Toen ik tig jaar gelegen bezit was met een artikel over de Grote of Sint-Nicolaaskerk (Oosthuizen) kwam ik ook aan bij het pronkgraf van de familie Van Bredehoff dat er staat. Dat werd zo'n groot onderdeel van het artikel over de kerk, dat ik het afgesplitst heb in een apart artikel. Maar als je dan dus een artikel schrijft over een graf en voor wie het gemaakt is, dan ga je dat ook een beetje uitleggen. Deze biografie over François van Bredehoff werd ook weer veel te groot, dus ook dat werd weer afgesplitst. Zoals je ziet: onderdelen van kunnen prima afgesplitst worden als ze het hoofdartikel gaan overheersen, of als ze wel een onderdeel zijn, maar toch eigenlijk ook weer zelfstandige onderwerpen zijn. Dqfn13 (overleg) 26 okt 2022 14:41 (CEST)

Bedankt voor je reactie Dqfn13, ja dus je begrijpt mijn dilemma goed. Ik ben alleen bang dat het voor de lezer alleen verwarrender wordt om het onderwerp op beide plaatsen te beschrijven, of dat een van de twee wordt overgeslagen.

Ik heb ooit heel de stadiëring bij Hodgkin vervangen door een link naar het afzonderlijke artikel, maar een vandalismebestrijdert vond duizenden bytes weghalen zodanig verdacht dat hij die bewerking domweg terug bleef draaien, daarom uiteindelijk maar een link naar het hoofdartikel geplaatst. Ik denk dat ik het zo dan ook maar aanpak bij alles gebaseerd op CHOP.

Je hoeft er nauwelijks verstand van te hebben, het zijn afkortingen van de medicijnen in het schema: bijv. CHOP is 4 middeltjes, COP (ook wel CVP) is een middeltje minder: zonder de H. Het is wel zo dat R-CHOP en R-COP/R-CVP ten opzichte van elkaar voor hele verschillende vormen van lymfeklierkanker worden gebruikt en ik vind dat (R-)CVP daarom eigenlijk in een eigen artikel hoort. Dat het een afsplitsing is van het oorspronkelijke CHOP is een... historisch weetje, maar geen reden om de boel daarnaar te organiseren. Zal ook even kijken hoe andere taalwikis dit oplossen. Schilbanaan (overleg) 26 okt 2022 16:11 (CEST)

Op enwiki doet men ongeveer hetzelfde, maar een enkele variant heeft wel een eigen pagina. Dus ik moet zelf maar een afweging maken, denk ik...? Frustrerend, ik wil het makkelijk houden voor de lezer, maar een onderwerp op een eigen pagina zetten kan het soms juist verwarrender maken. Schilbanaan (overleg) 27 okt 2022 12:48 (CEST)