Wikipedia: Richtlijnen Software

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken
Afkorting : WP: RL / SW, WP: RSW

Naast de algemene verplichte artikelvereisten , de definities van wat Wikipedia niet is en de aanbevelingen voor goede artikelen, beschrijft deze pagina richtlijnen voor artikelen over softwareonderwerpen.

Wat moet er in een softwareartikel staan?

Wat doet het programma?
De essentiële functie en het doel van het programma moeten duidelijk worden uitgelegd.
Voorbeeld: TomeRaider is een tekstdatabasebrowser voor draagbare apparaten (PDA) en Windows. Met de software kunnen grote bestanden, zoals encyclopedieën of uitgebreide boeken, worden weergegeven op PDA's.
Wie heeft het geschreven?
De auteur, groep en / of organisatie die het programma heeft ontwikkeld, moet worden genoemd.
Voorbeeld: Adobe Photoshop is een commercieel beeldverwerkingsprogramma van het Amerikaanse softwarehuis Adobe Systems.
Wanneer is het geschreven?
Historische classificatie: In ieder geval moet de oorsprong en het begin van de ontwikkeling van een programma worden toegelicht.
Voorbeeld: Het KDE-project is op 14 oktober 1996 gestart door Matthias Ettrich onder de naam Kool Desktop Environment.
Waar wordt het gebruikt?
Het artikel moet beantwoorden voor welk gebruik het programma is bedoeld (bepaalde overlap met het doel) of waar het daadwerkelijk wordt gebruikt. Indien mogelijk is het erg nuttig om de motivatie van de ontwikkelaars van de software te vermelden (antwoord waarom en waarvoor ).
Hoe is het programma beschikbaar?
De voorwaarden waaronder de software beschikbaar is, moeten worden gespecificeerd. Is het bijvoorbeeld freeware , shareware of andere propriëtaire software ? Of is het onder een open source licentie? Zo ja, onder welke?

Hoe schrijf ik goede software artikelen?

Over het algemeen zijn brondocumenten een essentieel onderdeel van een goed artikel. Enerzijds leveren ze neutrale content en anderzijds geven ze aan dat de software wordt geobserveerd.

Bereik van functies

De beschrijving van het scala aan functies vormt in de voorgaande artikelen meestal het grootste deel. Eigenlijk zou het andersom moeten zijn. Een programmabeschrijving die te gedetailleerd is in de stijl van online help ("Het Extra-menu bevat ...") is niet wenselijk. Bovenal moet het artikel de essentiële functies beschrijven en de functies die ongebruikelijk of zelfs uniek zijn voor programma's van dit type.

Distributie / toepassingsgebieden

De absolute penetratie van software is niet bruikbaar te meten, maar er zijn veel aanwijzingen die de omvang van de penetratie aangeven, waarvan de belangrijkste in het artikel moet worden vermeld - dit is een belangrijk onderdeel van het artikel, ook omdat het voor de reader biedt directe meerwaarde, bpsw. of en zo ja in welke context de software in kwestie voor hem interessant kan zijn. Van boven naar beneden, met toenemend belang, zijn dit bijvoorbeeld:

  • Verkoop- en/of downloadaantallen, zoekmachinehits: Bewustzijn is hier slechts in beperkte mate uit af te lezen, maar zeer grote aantallen (> 1 miljoen) in deze gebieden kunnen een indicatie zijn. Is de software onderdeel van een distributie, zoals Linux-distributies (voorgeïnstalleerd)? Dat zou de lage downloadaantallen kunnen verklaren. Sommige Linux-distributies houden ook populariteitsstatistieken bij die de downloads van de afzonderlijke programmapakketten meten.
  • Leaderboards: welke onderscheidingen en beoordelingen heeft de software ontvangen? Kwam het programma op de eerste plaats in een groter gebruiksonderzoek, of werd het als alternatief antwoord gegeven (met andere woorden, er werd al verwacht dat het vooraan zou belanden)?
  • Toepassingsgebieden: Waar wordt de software voornamelijk gebruikt? Voor welke computerarchitecturen en besturingssystemen is het beschikbaar? Welke organisaties/bedrijven zijn gebruikers van de software?
  • Literatuur: Staan er uitgebreide berichten in IT-magazines? Welke boeken zijn er over het programma? Werd het buiten de IT-pers genoemd, werd het zelfs herhaald of zelfs regelmatig?

verhaal

Verder moet zoveel mogelijk over de geschiedenis van het programma in het artikel staan. Wat hier vooral interessant is, is waarom het is gemaakt, wanneer, door wie. Daarnaast dient indien mogelijk een verkorte versiehistorie met de belangrijkste mijlpalen van de programmaontwikkeling te worden opgenomen, waarin staat wanneer welke belangrijke functie is toegevoegd. Naast het noemen van successen, maakt informatie over historische mislukkingen, problemen en hoe ermee om te gaan een artikel los. Ook vermeldenswaard zijn de voorlopers/modellen van een software en welke effecten ze hadden op andere software. Last but not least zijn opvolgers en verdere ontwikkelingen belangrijk voor een goed artikel, zeker bij historische software.

Stilistische conventies en voorbeeldartikelen

Naast de algemene conventies voor mooie artikelen , is het vaak aan te raden om een specifieke infobox te gebruiken voor software artikelen . De beste manier om erachter te komen hoe u deze kunt gebruiken, is door naar de paginabron van andere softwareartikelen te kijken. Er moet op worden gelet dat de informatie in de infobox ook in volledige zinnen in de tekst van het artikel terug te vinden is.

Concrete voorbeelden van goede softwareartikelen zijn de uitstekende artikelen over gratis software , computerspellen en uitstekende artikelen over algemene computerwetenschappelijke onderwerpen die het lezen waard zijn .

Wat te doen bij defecten

Is het mogelijk om de kwaliteitsborging te verbeteren?
In de regel is het het beste om een ​​defect artikel eerst op de betreffende kwaliteitsborgingspagina van het betreffende vakgebied in te voeren en het daar samen met de gespecialiseerde auteurs te verbeteren. Voor het algemene veld van de informatica kan de zorgredactie informatica aan hun kwaliteitszorgkant aan dergelijke zaken doen. Artikelen over computerspellen worden verwerkt in de afdeling kwaliteitszorg van het Wiki-project computerspel .
Is er een dubbele invoer of is het mogelijk om te combineren?
Vul in dat geval het artikel in op de redundantiepagina's en indien mogelijk ook op de kwaliteitsborgingspagina's van het betreffende vakgebied. Zelfs als nauw verwante onderwerpen in verschillende artikelen worden behandeld, is het vaak zinvol om ze in één artikel te groeperen. Een voorbeeld hiervan is het MoviX- artikel, dat alle drie de MoviX-varianten in één artikel beschrijft.
Is het artikel volledig onbruikbaar en/of geen verbetering mogelijk/in zicht?
Een vermelding op de kandidaat voor verwijdering is gerechtvaardigd, vooral in het geval van stilistisch onbruikbare artikelen (bijvoorbeeld pure aaneenrijging van trefwoorden of lijsten), waarvoor geen verbetering te verwachten is vanwege de geringe inhoud van het onderwerp of waarvoor een poging om de kwaliteit te verbeteren is niet gelukt. Hetzelfde geldt voor software-items die promotie-items zijn . In ieder geval moet in het verwijderingsverzoek worden vermeld welke punten uit "Wat moet er in een softwareartikel?" niet zijn vervuld en zo mogelijk moet worden beschreven of, en zo ja, welke pogingen zijn ondernomen om de artikel vooraf.

relevantie

Er is software die geen artikel verdient, ook al is het goed, omdat het praktisch geen oplage heeft. Wat de relevantie van een software inhoudt, is gedefinieerd in onze relevantiecriteria voor softwareproducten .