Validación de artículo
La Validación de un Artículo (Article Validation; AV) se refiere en general a sistemas mecánicos propuestos por medio de los cuales los editores pueden ser asistidos en ejercer decisiones editoriales correctivas a artículos, manteniendo cualquier creación actualmente abierta o "democrática" y editando artículos.
Actualmente el único mecanismo para "validación" es el modelo abierto wiki, el cual admite a los usuarios alterar, adaptar, reformar o revertir cambios hechos durante una edición anterior.
El modelo wiki es sinónimo de transparencia. Es decir, uno en el cual las medidas correctivas son post-activas (hechas después del evento), y mientras que el modelo wiki ha llevado a un gran éxito en la construcción de una enciclopedia desde el inicio, el crecimiento del proyecto ha excedido el tamaño del núcleo de edición, y en áreas controversiales ha sido visto como un obstáculo para producir una enciclopedia "estabe" o "profesional".
En esencia, AV es un plan hacia la implementación de un mecanismo funcional, el cual cambiaría el modus operandi de Wikipedia más allá del concepto idealista de un modelo completamente abierto, y daría una herramienta importante por medio de la cual editores confiables podrían ser asistidos mecánicamente para repeler el vandalismo. Porque tal cambio podría teóricamente tener un impacto en la mera filosofía por la que Wikipedia ha tenido éxito hasta hoy, es necesario que tal mecanismo sea bien pensado, corregido abiertamente y exhaustavamente explicado.
Característica de Validación de artículo
Esta característica está en MediaWiki 1.5 y se espera que se mantenga en: Wikipedia en 1.5. Véase también Article validation possible problems.
Wikimedia Foundation wiki
Solo los usuarios aprobados por el consejo directivo pueden obtener cuentas. Ver Solicitud de una cuenta en el wiki de la Fundación. Las ediciones no aprobadas o de borrador se almacenan en Meta.
Otras wikis no tienen sistemas de aprobación que afecte a la edición o la aparición de versiones, pero sí tienen algunas medidas de control de calidad (revisión por pares, artículos destacados, listas de stubs / substubs, etc.).
Algunos de ellos están vinculados, entre otras cosas, a los proyectos Wikimedia.
Restricción de HTML
El wiki de la Fundación permite el uso completo de HTML. Los otros wikis permiten el uso limitado de HTML, como lo hace normalmente la MediaWiki software.
Básicamente, la validación del artículo se puede utilizar para tres cosas:
- El wiki de la Fundación
- El otro sitios web
- Publicación estática (por ejemplo, papel, CDs / DVD, WikiReaders)
Se podrían utilizar sistemas de validación similares o diferentes para estos.
Wiki de la Fundación
La wiki de la Fundación funciona de manera diferente porque:
- Permite el uso completo de HTML.
- El contenido de esta wiki es oficial. --Daniel Mayer 16:28, 17 Feb 2005 (UTC)
- Pero algunos contenidos en otras wikis son oficiales y no están protegidas. Brianjd 03:11, 2005 Feb 23 (UTC)
- De echo, no estoy seguro si todo el contenido de esa wiki es oficial.¿Los foros de discusión están autorizados? Brianjd 02:57, 2005 Feb 24 (UTC)
- Estás confundiendo el problema. La Fundación esta basada por las declaraciones realizadas en la Fundación WIki. Los usuarios aqui no están atados a las declaraciones hechas en Wiki. (Con excepción de las políticas de la página). Si no se clarifica qué es oficial, este debate no tiene sentido. Grendelkhan 20:20, 12 Apr 2005 (UTC)
Por qué Meta no debería ser utilizado para ediciones o borradores no aprobados
- Existen dos versiones de cada pagina:
- Ambas versiones deben ser revisadas para llegar a una versión final.
- Las versiones deben ser sincronizadas de manera regular.
- El historial de la pagina se encuentra en dos sitios.
- La versión META no se visualizará apropiadamente, por las siguientes razones:
- HTML no puede ser utilizado de la misma forma (Mire arriba)
- No contiene todas las plantillas.
- Rechaza cambios recientes
Hemos empezado a producir contenidos estáticos (Ej: nuestros Wikireaders). Cuando un contenido estático es distribuido (CD-ROM, papel, PDF), un error mostrado en este tipo de documentos no puede ser corregido por el lector y permanecerá visible...para siempre...Esto puede ser malo para la imagen pública de Wikipedia, y puede poner en duda la validad de todo nuestro contenido.
Esto parece indicar que cualquier contenido distribuido oficialmente por Wikipedia, debería ser revisado uno por uno, o contener una notificación destacada, indicando la naturaleza del contenido( aceptando contribuciones de cualquier persona)
Por otro lado, otros contenidos contienen errores, y la reputación de sus editores normalmente no se ve empañada.
"¿Queremos restringir el uso de HTML por defecto? Mire Wikipedia:Talk:HTML#Restricted HTML?." Brianjd 03:25, 2005 Mar 6 (UTC)
- Algunos lectores se preocupan por la fiabilidad de nuestro contenido, que en ciertas ocasiones es distorsionado por vándalos.
- Este me parece un tema diferente a la confiabilidad. El vandalismo es un crimen, lo otro es exactitud y eficacia.
- Una revisión cuidadosa incrementará nuestra audiencia y mejorará nuestra reputación.
- La validación de los artículos ayudará a evitar que se observe el vandalismo e indicar si el contenido de un artículo es producto o no de vandalismo.
- O pueda que no. ¿Existe alguna diferencia entre validación o eliminación del vandalismo? La mayoría del vandalismo es muy obvia y cualquier editor puede manejarla.
- La validación de artículos puede ser vista como un reto, por lo tanto se incrementa el vandalismo
Base of editors
- Some potential expert editors refuse to edit, because they think their content will be damaged by vandals or non-experts. Providing a checking service might help them feel more confident with the process.
- Some current editors may choose not to participate if the process becomes more complicated.
- On the well-developed wikis, there is an increasing feeling of protectiveness in some areas. A set of editors sometimes forms a protection team, aggressively undoing or edit warring over any changes they dislike, thereby preventing the natural evolution of the wiki process. Providing them with the certainty that at least one approved version is available might help them be more gentle with newbies, or with editors holding a different bias than them.
- Huh? Any examples? Why are these users not talked to, or if they don't respond to that, banned? Brianjd | Why restrict HTML? | 08:33, 2005 Mar 20 (UTC)
- Protection discourages/prevents editing, and is unwiki-like. See The Cathedral and the Bazaar, an essay by Eric S. Raymond.
- The Cathedral and the Bazaar is completely irrelevant to Wikipedia. An open-source program typically has one or few maintainers who accept good contributions, reject bad contributions, release stable versions, and who don't have to fork the entire universe for their variant of an individual program to become widely used. If open-source software was "wiki-like", it would be a disaster. -- Mpt, 2005-12-18
- All versions are currently non-editable and non-deletable. It is only possible to create new versions.
- It is not necessary to hide the most-recent version from viewers.
The advantages of an approval mechanism of the sort described are clear and numerous:
- We will encourage the creation of really good content.
- It makes it easier to collect the best articles on a wiki and create completed "snapshots" of them that could be printed and distributed, for example. This issue is central to Pushing to 1.0.
- People may not want to make small contributions if they think well-written articles, with references, are expected.
- An expert-centered approval mechanism might be considered a hierarchic methodology, in contrast with the bazaar-type open-source projects like Wikipedia, that are known to achieve good results (e.g. Linux) through aggressive peer-review, and openness (With enough eyeballs, all errors are shallow.). It can be argued that the very reason Linux has become so reliable is the radical acceptance, and for some degree, respect, for amateurs' and enthusiasts' work of all sorts. (Note: This argument is currently somewhat backwards - code does not get into the Linux core tree unless the patch is approved by Linus Torvalds, and Linus is only likely to accept a patch if it has been pre-approved by the relevant subsystem maintainers. All patches must actually function as advertised, and are also reviewed for compliance with coding standards. Linux vendors apply their own quality control to the patches they include in their distributed kernels. If Wikipedia wants to model itself on Linux, it needs to be understood that Linux development is not a free-for-all - potential contributions are scrutinised carefully before being accepted)
- Experts have controversies among themselves: for example, many subjects in medicine and psychology are highly debated. By giving a professor the free hand in deciding whether an article is "approved" or "non-approved" there is a risk of compromising the NPOV standards by experts' over-emphasizing their specific opinions and area of research.
- Finding an expert who corresponds to a certain article can sometimes be troublesome:
- Can a Ph.D on applied Mathematics "approve" articles on pure mathematics?, or more strictly, should one be accepted as a approver only if he/she have made research on the specific subject he/she is approving? Who will decide whether a person is qualified for approval?
- Some obscure or day-to-day topics don't have any immediate "expert" attached to them. Who will approve articles on hobbies, games, local cultures etc.?
- Validation implies the necessity of indication of acceptance of an article. The opposite may be more inline with the current wikipedia strategy- that of rejection of versions that are not acceptable. In most cases rejection does not require experts at all.
- Experts are inevitably rare. That means the pool of people suitable to validate articles is small, and this is a scalability issue. The wikipedia is huge, so scalability is very important. In other words, there's no point in having a validation mechanism if nothing ever gets validated (see Nupedia).
¿Eso es necesario?
These are arguments presented for why an additional approval mechanism is unnecessary for Wikimedia Foundation wikis:
- They already have an approval mechanism; although anyone can edit any page and experts and amateurs of all levels can be bold and contribute to articles, communal scrutiny is an approval mechanism, though not as centrally-controlled as peer review.
- Imperfect as they currently stand, they already foster a more sophisticated critical approach to all sources of information than simple reliance on "peer-reviewed" authority. Low-quality articles can be easily recognized by a reader with some or no experience in reading wikipedia, and by applying some basic critical thinking:
- The style may sound biased, emotional, poorly written, or just unintelligible.
- Blanket statements, no citing, speculative assertions: any critical person will be careful in giving too much credit for such article.
- The history of an article shows much of the effort and review that has been brought into writing it, who and how qualified are the writers (Users seem to put some biographical information about themselves on their pages.).
- A sophisticated reader soon learns that the Talk page is often enlightening as to the processes that have resulted in the current entry text.
- Cross-checking with other sources is an extremely important principle for good information gathering on the internet! No source should be taken as 100% reliable.
- Some "authoritative" and "approved" encyclopedias don't seem to stand for their own claims of credibility. See errors in Encyclopædia Britannica that have been corrected in Wikipedia.
- The very idea of an article being "approved" is debatable, especially on controversial topics, and can be seen as an unreachable ideal by some.
Proposed basic requirements
Among the basic requirements of an approval mechanism would have to fulfill in order to be adequate are:
- The approval must be done by experts about the material approved. A trust model?
- There must be clear and reasonably stringent standards that the experts are expected to apply.
- The mechanism itself must be genuinely easy for the experts to use or follow. Nupedia's experience seems to show that a convoluted approval procedure, while it might be rigorous, is too slow to be of practical use.
- The approval mechanism must not impede the progress of Wikipedia in any way. It must not change the wiki process, but rather be an "add-on".
- Must provide some way of verifying the expert's credentials—and optionally a way to verify that he or she approved the article, not an imposter.
Some results we might want from an approval system are that it:
- makes it possible to broaden or narrow the selection of approvers (e.g., one person might only wish authors who have phd's, another would allow for anyone who has made an effort to approve any articles.),
- provides a framework for allowing multiple sets of "approvals", allow not just one set of approvers or one approval rating but different sets to allow for different standards. (I.e. as with consumer products, different safety approvals, scuba diving certifications, etc.)
Here is another proposed system:
- Add a "rate this change!" feature to the software. Anyone is allowed to rate any change on a scale of -3 to 3, with -3 meaning "ban this person", -1 meaning "small errors", 0 meaning "no opinion", +1 meaning "small improvement" and +3 meaning "this is a great contribution". Even a rating of 0 is useful, because it would mean the change was inspected and no egregious errors or sabotage was found.
- The point is just to start collecting the data. After the data is collected, it should be straightforward to figure out a trust rating system based on the data, and probably any sensible method would work.
- approval mechanism
- mechanism whereby articles are individually marked and displayed, somehow, as "approved"
- facet of validity
- one of the following - accurate (fact-checked), neutral (NPOV), well-written (grammar-checked, spell-checked, proper style, clear), and complete (coverage suitable to the subject's importance)
- reviewed version
- article version whose quality has been reviewed by at least one editor (in each facet)
- validated version
- reviewed version whose quality is validated, on the basis of its content and outstanding reviews, by a (qualified) user (while its aggregate review is not negative in any facet)
- reviewed/validated article
- article, at least one of whose versions has been reviewed/validated
- public version
- version of an article showed to users who are not logged in
- The public version need not be any different than the most-recent-edited version. The software can refer back to the most-recent-validated version and color code the differences from it in the displayed version.
- the quantity of it should not be measured - Burg.
- really? It is important that our article on Geology both showcase the depth of our relevant content, and do justice to the importance of the broad subject. I agree that evaluations of completeness should not take place on the same linear scale as evaluations of correcness and quality of writing. +sj+
- the quantity of it should not be measured - Burg.
Who can Validate?
- set up a validation committee (a group of trusted, interested wikipedians) - requires separate "validator access" for those who have been approved to serve on these validating committees?
- any user or group of users satisfying some statistical requirement (combination of time since registration, # of article edits, # of total edits)
- any user or group of users
- Administrators (who are trusted members of the community), and any user who have been marked as trustworthy by 3 administrators.
- automatic validation:
- after a certain # of (qualified?) users have edited the article
- after a member of a certain group has edited the article
- after the version has remained current for some time (therefore assuming the previous edit was legitimate and not vandalism)
- separate validation restrictions for different kinds of validation (e.g., creating factual-validation committees for each major category, based on experience/expertise)
(Note that few of the above presently relate to the level of knowledge about the subject of a 'validator', merely of their longevity or ability in wiki editing. This may not be appropriate for some subjects --VampWillow 11:28, 5 Dec 2004 (UTC))
How to Validate?
- Validation via extra metadata - let users add input about various facets of an article, and summarise that in terms of whether and how thoroughly the article has been validated.
- Validation by committee - have an editorial board which selects topical committees which go around setting a single 'validated' flag on articles once they have reached maturity.
- Weighting and averaging reviews - Require supermajorities among trusted reviewers for key aspects of articles; use a crude trust metric to decrease the leverage of mischievious reviewers.
Suggested validation processes
See Article validation proposals. Also, Flagged revisions on English Wikipedia.
Discusión de las propuestas
- For the Wikipedia page on this topic, please see en:Wikipedia:WikiTrust and its talk page.
I started off writing authority metric as a section of this page, but it was getting a bit long, so I moved it to its own article. Please check it out, it's closely related to discussion above. -- Tim Starling 03:02, 17 Nov 2004 (UTC)
IMHO, validation is 90% social and 10% technical. The social (or, if you prefer, political) part is "whom do we trust--what people, or what institution comprised of people--to certify that an article (as of such-and-such a date and time) is accurate or complete or whatever?" The technical part is "how do we store those certifications in the database and communicate them to the users?" I humbly submit article endorsement as a way to deal with the technical part. Sethg 16:31, 18 Nov 2004 (UTC)
Why not use UCSC WikiTrust?? It's available now as an extension to MediaWiki and automagically color codes edits based on trust metrics.
Two kinds of proposals and their structural relationship
There are two basic, completely different types of "article validation" being proposed.
- Versions:Every article has one "best version", called "public version" in the definition section above. The contributors to that article in particular (and possibly viewers) vote on this.
- Articles: A subset of article are selected as "featured articles" or "reviewed articles" or "vetted articles". The entire community (or a voluntary subset thereof) votes on candidates.
These two different structures are not mutually exclusive. On the contrary, they work well together. They can be connected easily:
- A subset of public versions are selected as "featured public version"s or "reviewed public version"s or "vetted public version"s. The entire community (or a voluntary subset thereof) votes on candidates.
The only ambigiuty is: after a public version of an article is selected as a featured/reviewed/vetted public version, when a new public version is selected by the contributors to that article, does that new public version become the new community-reviewed public version, or does it have to be renominated? I would think that it would be renominated.
That being said, the community selection of a subset of public versions to be vetted public versions does not require software implementation. It is already being done on en via "featured articles" just fine.
The selection of a public version from the article history (or some have proposed branching - which can be done in the vetted public version process) does require software implementation and there are a lot more ways to go about it.
Given the above, I think that both kinds should be implemented, but because a "public version"
- necessarily precedes the vetted public version,
- requires software implementation, and
- is a more open question,
"public version"s should be the focus of these pages. Kevin Baastalk 23:56, 8 April 2006 (UTC)
- Seconded except for needing software implementation. Identification of public versions is possible using talk pages and wikipedia namespace. - Samsara 09:51, 15 April 2006 (UTC)
- Then let me say, rather, that with software implementation, it can be done with considerably less effort, and cannot be disrupted or circumvented. Kevin Baastalk 19:14, 16 April 2006 (UTC)