Wikipedia:Wikiproject/Projectgroep/Gids

In een peiling heeft de gemeenschap van gebruikers duidelijk gemaakt dat de toepassing van deze sjablonen ongewenst is. Ze heeft niets met de kwaliteit van artikelen te maken en de toepassing van deze sjablonen wordt als ongewenst gespam gezien.

Dit project vertoont geen activiteit, en is in de archiefcategorie voor Wikiprojecten opgenomen. Dit project kan in principe altijd weer geactiveerd worden, haal dan dit sjabloon weg en voeg het project toe op Wikipedia:Wikiproject.

Deze pagina probeert een complete gids te zijn voor het organiseren en draaiende houden van een Wikiproject. Deze pagina beperkt zich noodzakelijk wel tot de gewone en goedbegrepen aspecten van Wikiprojecten. Individuele projecten ontwikkelen vaak minder gewone functionaliteit die afhangt van de eigenaardigheden van de scope van dat project of de activiteiten; de beste manier om ze te ontdekken is te kijken naar wat succesvolle Wikiprojecten doen, omdat het onwaarschijnlijk is dat deze gids ieder mogelijk idee aanreikt waar een project gebruik van kan maken.

De gids gaat vooral over eigenlijke Wikiprojecten — dat betekent, Wikiprojecten wiens doel het is om artikelen binnen een bepaald gebied te verbeteren. Onderhouds Wikiprojecten, zoals beginnetjes-sorteren, disambiguatie, en andere opruimtaken hebben een heel andere structuur en organisatie van activiteiten, dus het meeste van de adviezen die hier gegeven worden is niet op hen van toepassing.

Wat is een Wikiproject?

De definitie van een Wikiproject spitst zich toe op de haar functie binnen:

Een Wikiproject is een verzameling pagina's gewijd aan het beheren van een bepaald onderwerp of een groep onderwerpen binnen Wikipedia; en, tegelijkertijd, een groep redacteuren die de genoemde pagina's gebruiken om samen te werken aan de encyclopedie. Het is geen plaats om encyclopedische artikelen te schrijven, maar een bron om het schrijven en verbeteren van artikelen te coördineren en te organiseren.

In andere woorden is een Wikiproject een centrale plaatst voor redacteuren om samen te werken aan een bepaald aandachtsgebied. het project kan richtlijnen ontwikkelen, verschillende processen beheren, actielijsten bijhouden en fungeren als forum voor het bespreken van het interesseveld van de betrokken redacteuren.

Maar wat "maakt" een Wikiproject? Het is verleidelijk, gezien de definitie hierboven, om een Wikiproject primair te zien als de som van zijn artikel-gerelateerde activiteiten; in andere woorden, om het als paraplu te beschouwen voor sommige "pagina's gewijd aan het management van een specifiek onderwerp of familie van onderwerpen". Maar uit ervaring blijkt dat een Wikiproject om te slagen meer moet zijn dan een verzameling processen en richtlijnen. Wat een succesvol Wikiproject maakt is niet het zich noemen van "Wikiproject"; nee, het is dat een Wikiproject meer functioneert als een verzameling van editors dan van artikelen.

Een Wikiproject is fundamenteel een sociale constructie; zijn succes hangt af van zijn mogelijkheid om te functioneren als samenhangende groep editors die samen naar een gelijk doel werken. Veel van het werk dat leden moeten doen om een succesvol Wikiproject—kwaliteits beoordeling en review zeker, maar bijna alles buiten het eigenlijke schrijven van artikelen—te laten slagen is vervelend, vaak ondankbaar en meestal niet gewaardeerd. Om effectief te zijn, moet een Wikiproject niet alleen interesse in de onderwerp van het project kweken, maar ook een moreel bij zijn deelnemers. Alleen wanneer groepssamenhang kan worden behouden—waar, in andere woorden, projectleden willen delen in het minder opwindende werk—kan een Wikiproject de energie en richting genereren om systematisch en niet incidenteel excellente artikelen te maken.

Beginnen

Het advies dat hier gegeven wordt is in eerste instantie bedoeld voor projecten die net opstarten-of een nieuw leven wordt ingeblazen-maar ook voor editors die misschien wel een nieuw Wikiproject willen beginnen; in elk geval kan iedereen betrokken bij Wikiprojecten er misschien interessante zaken in vinden.

Is een project nodig?

De eerste vraag die je moet stellen als iemand een idee heeft voor een nieuw Wikiproject is: "Is een afzonderlijk Wikiproject de beste aanpak?" Het antwoord hangt af van twee belangrijke factoren.

Ten eerste, is het onderwerp breed genoeg om het de extra administratieve rompslomp waard te laten zijn? We kunnen natuurlijk ook voor elk artikel dat we willen een eigen project starten; maar, even natuurlijk, dat doen we niet, omdat het veel eenvoudiger is om gewoon samen te werken op de overlegpagina. In het algemeen, als er minder dan een paar dozijn artikelen binnen de verwachte reikwijdte van het project liggen, zou het misschien efficiënter zijn om binnen een groter project te werken dat ze omvat. Tegelijk zou het aantal potentiële deelnemers overwogen moeten worden; als u als enige in een specifiek gebied werkt, is het maken van een project het zeker niet waard.

Ten tweede, als het onderwerp breed genoeg is dat enige manier van formele organisatie de moeite waard is, is een onafhankelijk Wikiproject het beste antwoord? De beste manier om dit te beantwoorden is door naar andere projecten over gelijksoortige onderwerpen te kijken, en bij het "hoofd" Wikiproject voor het bredere onderwerp. In sommige gevallen is er een afzonderlijk Wikiproject voor elk verschillend onderwerp, als dat zo is, is het maken van een nieuwe een goed idee.

Maar in andere gevallen zijn de projecten niet afzonderlijk, maar zijn er task forces van het centrale Wikiproject voor dat gebied; in dat geval is het benaderen van het centrale project—dat meestal een meer ontwikkelde structuur heeft om met subgroepen te werken-met het idee gewoonlijk de efficiëntere aanpak. (Dit is ook van toepassing op inactieve projecten die weer leven ingeblazen wordt; het "hoofd" project zal het inactieve project meestal willen adopteren als een nieuwe task force, in welk geval de leden aanzienlijke hulp kunnen bieden bij het draaiend krijgen.) Als dit het geval is, is het lezen van de rest van deze gids hoogstwaarschijnlijk niet nodig; het grotere centrale project zal je helpen te integreren in de specifieke setup die het al heeft.

Eerste begin

Als u hebt vastgesteld dat u een nieuw Wikiproject wilt maken, moet u er een basis pagina voor maken. De naamconventie voor Wikiprojecten is ze te plaatsen in de Wikipedia: space bij "Wikiproject projectnaam"; bijvoorbeeld, als u een project over tulpen zou beginnen, dan zou je de pagina Wikipedia:Wikiproject/Tulpen beginnen.

Een mogelijke schets voor een nieuwe Wikiproject pagina wordt hier gegeven; de bewoording zal naar gelang het onderwerp moeten worden aangepast.

Welkom bij het tulpen Wikiproject!

; Doel
* Het verbeteren van Wikipedia's dekking van tulpen.
* Het maken van richtlijnen voor artikelen over tulpen.

; Gebied
* Het project omvat alle artikelen over tulpen en het kweken ervan en gebruik.

== Leden ==
# {{Gebruiker|MyName}} (geïnteresseerd in alles over tulpen)

== Open taken ==
* ...

== Categorieën ==
* [[:Categorie:Tulp]]
* ...

== Sjablonen ==
* ...

== Gerelateerde projecten ==
* [[Wikipedia:Wikiproject/Planten]]

[[Categorie:Wikipedia:Wikiproject|Tulp]]

Een andere mogelijkheid is om {{Wikiproject}} te gebruiken, door het maken van een nieuwe pagina met {{subst:Wikiproject|projectnaam}}; dit maakt een iets complexere lay-out. Als laatste is er de mogelijkheid een al actief Wikiproject te vinden—idealiter een met een gelijk gebied als het nieuwe project-en dan de structuur van die projectpagina meteen te kopiëren. Deze methode kan aanzienlijk knipwerk van onnodige secties opleveren, vooral wanneer een erg groot project als model wordt gebruikt; de grootste projecten ontwikkelen veel complexe strucuren die veel te stram voor een kleiner project zouden zijn.

In het algemeen moet een nieuwe Wikiproject pagina zo simpel mogelijk gehouden worden, en moet vanzelf groeien. Hoewel het verleidelijk kan zijn een pagina met dozijnen sjablonen en banner te maken, is dit meestal een slecht idee; een klein project kan meestal zich meestal niet met meer gebieden tegelijk bezig houden, en een erg ingewikkelde structuur kan potentiële nieuwe leden afschrikken-vooral als ze voor het eerst aan een Wikiproject meedoen!

Werving

Een van de belangrijkste aspecten van het actief houden van een Wikiproject is het werven van editors. Elk Wikiproject moet nieuwe leden werven om verloop goed te maken; elk project dat dit nalaat zal uiteindelijk in elkaar storten.

Hoe werf je dan die waardevolle medewerkers? De meest effectieve methode is door directe uitnodiging. Als er andere gebruikers zijn die actief zijn op het gebied van het project, zou u ze kunnen herkennen door naar de geschiedenis en overlegpagina's van artikelen te kijken; en u kunt ze dan beleefde berichten sturen om hun te vragen naar het nieuwe project te kijken, wat vaak nieuwe leden oplevert.

Daarnaast kun je ook in De kroeg een bericht posten dat je een project opgestart hebt over een bepaald onderwerp.

Aan de slag

Als een project is begonnen leden aan te trekken wordt het een urgent probleem om iets voor ze te vinden om te doen. Mensen binnen boord houden is moeilijker dan ze aan te trekken; verveelde editors zullen snel afhaken.

Taaklijsten

De normaalste—en simpelste—manier om de aandacht van projectmedewerkers op bepaalde artikelen te vestigen is het maken van een centrale lijst van open taken. Voor projecten kan dit vaak een eenvoudige sectie op de Projectpagina zijn (soms gebruik makend van een actie-sjabloon, hoewel dit extra subpagina's vereist die meestal niet nodig zijn).

Er zijn een aantal verschillende zaken die gewoonlijk opgenomen worden op taaklijsten van projecten:

Aankondigingen

Algemene aankondigingen van belangrijke discussies en grotere taken die ondernomen worden. Dit hoeft niet nodig te zijn voor een klein project — waar zulke punten beter op de overlegpagina van het project aan de orde kunnen worden gesteld — maar wordt belangrijker als het project groeit en het verkeer op de overlegpagina's groeit.

Etalagekandidaten en de review ervan

Een van de belangrijkste zaken om aan te kondigen binnen het project; vooral voor een nieuw en kleiner project kan een succesvolle etalagekandidaat het moreel opkrikken—maar dit zal vaak de assistentie van meerdere projectmedewerkers vragen om te slagen.

Reviews

Verzoeken voor reviews; dit kunnen project-specifieke reviews zijn, als het project zo'n proces gebruikt, of geselecteerde punten uit de hoofd review pagina als het dat niet heeft.

Gewenste artikelen

Artikelen die nog niet bestaan maar die gemaakt zouden moeten worden. Deze kunnen vaak uit de bestaande lijsten of uit gelijksoortige sjablonen worden uitgezocht die met het gebied van het project te maken hebben.

Opruim- en uitbreidingsverzoeken

Deze kunnen handmatig worden toegevoegd, of worden samengesteld uit bestaande opruimcategorieën.

In tegenstelling tot de eerste drie categorieën - waarvan de grootte meestal beperkt is - kunnen de laatste twee snel groeien. Het is gewoon om in dat geval "overloop" lijsten aan te maken waaruit de punten zonodig die op de hoofdlijst kunnen afwisselen, en de centrale lijsten te beperken tot een paar dozijn van elk type. Bijvoorbeeld kan er een complete lijst van artikelen die gemaakt moeten worden staan op een subpagina (zoals Overleg Wikipedia:Wikiproject/Parijse metrostations/actie/schrijven of Overleg Wikipedia:Wikiproject/Projectgroep/actie/Verzoeken); deze lijst kunnen groeien tot honderden punten, die onmogelijk in een gewoon sjabloon passen. In dit geval wordt er een zowel een selectie als een link naar de lijst op de takenlijst van het project gezet, om het overzichtelijk te houden.

Beoordelen

Kwaliteit

EA

A

B

C

D

Beg

Zie voor een overzicht van de beoordeling van artikelen de Artikel beoordeling FAQ.

Een van de meest gebruikte methoden die Wikiprojecten gebruiken om hun werk te volgen en te ordenen is hun artikelen te beoordelen aan de hand van de kwaliteitsschaal (rechts staat het overzicht); sommige projecten kunnen meer niveaus toevoegen, zoals op de Engelstalige Wikipedia het The Beatles WikiProject die heeft.

Een heel klein aantal minder-actieve projecten kan een handmatige lijst van beoordelingen bijhouden; maar als het aantal artikelen groeit wordt een speciaal proces nodig. De eerste stap hiervan is het maken van een subpagina (soms een "beoordelingsafdeling" genoemd) voor het beoordelings werk; deze kan er verschillend uitzien, soms meer formeel dan anders (zie bijvoorbeeld de (en) Military history en (en) Tropical cyclones pagina's). Maar de essentiele informatie—die van de hand-samengestelde lijst—vraagt een betere aanpak: bot-geholpen beoordelingen.

Bot-geholpen beoordeling

Het bot-geholpen beoordelingsschema werkt door het invoegen van beoordelingen in een banner op de overlegpagina van het Wikiproject. Als we het voorbeeld van het Wikiproject tulpen van hierboven volgen, kan de laatste regel in het sjabloon die tabel afsluit worden vervangen door een subst naar het {{Project}} sjabloon:

{{subst:Project|Beg}}

(Zie voor resultaat met parameter|Beg de Overlegpagina van deze Gids)

(Merk op dat een andere aanpak om een goed sjabloon te maken mogelijk is; zie hieronder voor meer details.)

Dit zal sjablooncode maken die het het projectsjabloon mogelijk maakt een "klasse" parameter mee te geven (bijv. {{Wikiproject tulpen|klasse=B}}) om de beoordelingsrating aan te geven; het invoegen van de parameter doet twee dingen:

• Het tonen van de bijbehorende rating in de banner zelf.
• Het zet de overlegpagina in de bijbehorende categorie.

De sleutel tot het proces zijn deze laatste categorieën. Een volledige beschrijving van hun structuur wordt hieronder gegeven; in essentie houdt een bot categoriën van een bepaalde structuur bij (zoals (en) en:Category:Military history articles by quality), en maakt een uitgebreide index van beoordelingen voor elk deelnemend project. Hier hoort een werklijst bij, statistieken, en een veranderingslogboek.

"Belang"

Belang

Top

Hoog

Midden

Laag

Sommige projecten maken ook (en) belangrijkheids beoordelingen. Maar er moet gezegd worden dat deze controversieel zijn (omdat het onbelangrijk noemen van artikelen tot conficten kan leiden); met als resultaat dat sommige projecten belang niet beoordelen, terwijl andere alleen belangbeoordelingen voor een beperkt aantal artikelen gebruiken.

Beoordelingen in de praktijk

Zie (en) en:Category:WikiProject assessments voor de lijst met actieve beoordelingsafdelingen.

Review

Another very common process for a WikiProject to undertake is the peer review of articles. This is usually not a true peer review in the academic sense, but is instead a review by project members; such peer reviews are invaluable in obtaining constructive commentary on an article, and are particularly helpful for articles which are headed towards featured article candidacies. Project peer reviews are usully more helpful than Wikipedia-wide ones, both because there is a greater chance of encountering a reviewer with some knowledge of the topic, and because it is much easier for project members to notice new requests without the need to filter out the vast majority of ones not related to their area of interest.

For very small projects, an informal system of requesting reviews on the project's primary talk page may suffice; as a project grows, however, it is usually appropriate to create a dedicated page for the peer review process (such as the military history or biography ones). This page typically includes a brief section of instructions, followed by transcluded subpages for the individual reviews; these subpages are also linked from the project banners, where the presence of a link is controlled by a template parameter (often peer_review=yes). Editors will request a peer review by following a three-step process:

1. Add the appropriate parameter to the article's project banner.
2. Follow the displayed link to a new subpage—having the same name as the article—and add a link to the article (usually in a third-level header) along with any remarks or special requests.
3. Add a transclusion of the newly created subpage to the list of requests on the main peer review page.

The amount of time an article will spend being reviewed will vary, both according to the initial condition of the article—articles which are judged to be ready for FAC may be quickly nominated there, ending the review—and the attention the request receives; for moderately active peer review pages, archiving older reviews after a few weeks is usually a good approach.

One useful convention which has been adopted by many WikiProjects' peer review departments is that of having reviewers create a sub-section with their name to use for their comments. This allows extensive commentary and back-and-forth discussion to take place without the need for complicated indentation tricks to keep multiple reviewers' comments identifiable.

See Category:WikiProject peer reviews for a full list of active WikiProject peer review departments.

Technische noten

Interne navigatie sjablonen

This section discusses internal navigation templates for WIkiProjects; for navigational templates used in articles, see Wikipedia:Navigational templates.

As a WikiProject grows, it begins to acquire large numbers of subpages for various specialized purposes (such as assessment and peer review work or task forces); the largest projects can have dozens of subpages. The best way to ensure that all of these subpages can be easily located is to create a navigational template linking to them.

Most projects follow a fairly standard design for the template. It is placed as a right-floating bar, listing subpages (and usually corresponding talk pages), one per line. Here, for example, is part of the code for the navigational template used by the Lithuania WikiProject:

{| cellpadding="0" cellspacing="0" style="float: right; clear: right; border: 1px solid #aaa; 
padding: 5px; margin: 0em 0em 1em 1em; max-width: 300px; background: white;" 
! style="background: #99FF66; padding:5px; text-align: center;" | 
[[Image:Lietuvos-Lithuania 5.png|left|50px]] 
[[Wikipedia:WikiProject Lithuania|Lithuania<br/> WikiProject]]
|- 
|
{| cellpadding="3" cellspacing="0" style="font-size: 90%; width: 100%; background: ivory;"
|- style="background: #CCFF99; "
! colspan="2" style="text-align: center; border-top: 1px solid black; " | 
General information
|- 
| [[Wikipedia:WikiProject Lithuania|Main project page]]
| [[Wikipedia talk:WikiProject Lithuania|talk]]
|- 
| [[Template:WikiProject Lithuania|Project banner]]
| [[Template talk:WikiProject Lithuania|talk]]
|-
| [[Wikipedia:WikiProject Lithuania/Tips|Top 10 tips]]
| [[Wikipedia talk:WikiProject Lithuania/Tips|talk]]
|-
| [[:Category:Extremely short Lithuania articles|Extremely short articles]]
| [[Category talk:Extremely short Lithuania articles|talk]]
|- 
! colspan="2" style="text-align: center; border-top: 1px solid black; background: #CCFF99; " | 
[[Wikipedia:WikiProject Lithuania/Assessment|Assessment]]
|- 
| [[Wikipedia:WikiProject Lithuania/Assessment/Summary|Summary]]
| [[Wikipedia talk:WikiProject Lithuania/Assessment/Summary|talk]]
|- 
| colspan="2" align="center" | 
{{Wikipedia:Version 1.0 Editorial Team/Lithuania articles by quality statistics}}
|}
|}

Note the inclusion of the project's article assessment statistics at the bottom of the template; for larger projects with many more subpages, adding these may unacceptably lengthen the template, but this works quite well for smaller projects.

Another common feature for on navigational templates can be seen at the bottom of the navigational template used by the Military history WikiProject:

...
|-
| colspan="2" | 
<small class="editlink noprint plainlinksneverexpand">
[{{SERVER}}{{localurl:Template:WPMILHIST Navigation|action=edit}} edit] · 
[[Special:Recentchangeslinked/Template:WPMILHIST Navigation|changes]]
</small>

The key is the "changes" link; when the template is properly constructed, Special:Recentchangeslinked can be used to view, at a glance, any changes made to any of a WikiProject's pages.

The visual layout of project navigational templates tends to vary by project, with three stripe colors, two stripe colors, or colored boxes being common.

Project categorieën

As WikiProjects have become more common, the need for a standard system of categories for the projects' internal use has become apparent. WikiProjects usually expand their category namespace as they grow; but (using the example of WikiProject Tulips again) there are several possible categories that can be created:

• A top-level category for the project; it should have the same name as the project itself—in this case Category:WikiProject Tulips. The category should be placed under one of Category:WikiProjects's subcategories (e.g. Category:Science WikiProjects) instead of under Category:WikiProjects directly. If there is a "parent" WikiProject with a category (e.g. Category:WikiProject Flowers), the new category should be made a subcategory of that as well. It is generally not a good idea to place articles directly into this category; for all but the smallest projects, they will quickly overwhelm the internal pages, making them quite difficult to locate.
• Once the project begins to develop article-related processes, such as assessment or peer review, it is appropriate to create a subcategory for the various articles being tagged into them; the conventional name for this is formed by appending "articles" to the project name (e.g. Category:WikiProject Tulips articles). This can have a number of different subcategories:
  • Article assessment requires a Category:Tulips articles by quality (and, optionally, a Category:Tulips articles by importance), which must also be a subcategory of Category:Wikipedia 1.0 assessments. These will have further subcategories that follow the levels of the assessment scales, such as Category:A-Class tulips articles and Category:B-Class tulips articles for quality assessments.
  • Peer reviews and collaborations will usually require pairs of categories for current and archived articles (e.g. Category:Requests for tulips peer review and Category:Old requests for tulips peer review).
  • Task forces usually have at least one category for each task force; for an example of this, see Category:Military history articles by task force.
  • The articles category might have other subcategories containing such things as stubs, merged articles, articles needing attention, and so forth; an example of this type of management can be seen at Category:WikiProject The Beatles articles.
• Many projects also create a category for the project's members; this would generally be named either Category:WikiProject Tulips participants or Category:WikiProject Tulips members. The category should be a subcategory of Category:Participants in WikiProjects, and may sometimes be be populated through a userbox.
• The largest WikiProjects will often acquire a number of other categories for organizing things such as templates or archives.

Further examples of category trees in actual use can be found by browsing Category:WikiProjects; a few examples showing many of the features described above are Category:WikiProject The Beatles, Category:WikiProject Biography, and Category:WikiProject Military history.