APL Wiki:Content guidelines: Difference between revisions

Jump to navigation Jump to search
Split "Due weight" section off from "What is APL?"
m (Fix content guidelines link)
(Split "Due weight" section off from "What is APL?")
Line 11: Line 11:
* A language that uses the central concepts of Iverson's APL, like [[array]]s as the fundamental datatype, [[glyph]]s to represent [[primitive]]s, infix notation, and [[Evaluation order|right-to-left]] evaluation
* A language that uses the central concepts of Iverson's APL, like [[array]]s as the fundamental datatype, [[glyph]]s to represent [[primitive]]s, infix notation, and [[Evaluation order|right-to-left]] evaluation
* Developments adopted by substantial portions of the community of APLers, such as the [[nested array model]].
* Developments adopted by substantial portions of the community of APLers, such as the [[nested array model]].
The APL Wiki takes no position on what can be called "APL", and this question is not important to its content (when in doubt, a controversial APL such as [[J]] may be called a "language" rather than an "APL" or "dialect"). Instead, an editor should consider the task of balancing how central a concept is to APL against its prominence and placement in the APL Wiki. Even a recent and niche development like [[Reverse Compose]] has a place in the Wiki, but most information about the primitive should remain on its own page and mentions on more central pages should be qualified in order to make it clear the primitive is not available in most APLs. In contrast, a topic like [[Outer Product]] can be mentioned anywhere, and omitting it from related articles like [[Inner Product]] or [[Each]] would be a mistake in emphasis.
The APL Wiki takes no position on what can be called "APL", and this question is not important to its content (when in doubt, a controversial APL such as [[J]] may be called a "language" rather than an "APL" or "dialect"). Instead, an editor should consider the task of balancing how central a concept is to APL against its prominence and placement in the APL Wiki. See [[#Due weight]] below.
 
To be central to the concept of APL, a language needs '''adherence''' to APL principles and '''prominence''' in terms of its user base or in the APL community. Adherence is measured roughly by the definitions above: languages that satisfy more of these definitions, and more closely, adhere better to the concept of APL. Prominence is determined by how many people use a language, how many of these are part of the APL community, and how strong an influence the language has had on the development of APL.
 
Keep in mind that many APL users are not very visible to the outside world and don't publish anything about their usage (especially after the decline of the [[APL conference]]). For example, you are unlikely to see recent material about [[APL2]], but it is still widely used, and it's reasonable to think these users will look to the APL Wiki as a resource. As an editor you aren't expected to know every prominent language in order to contribute, but please think twice before removing material about a language you don't think is prominent. Evidence that the language is still in use might include major companies using it, active support forums, or significant development on the language indicating that it makes enough revenue to support this development. Significant historical use is also a sign, as usage of a particular APL rarely dies out quickly.
 
A language can be prominent even if it is very rarely used, or in extreme cases never implemented. This is the case for research languages that are important in developing features later picked up by more prominent APLs. For example, [[A Dictionary of APL]], while only an incomplete description of how one APL might work, strongly influenced [[J]] and subsequently [[Dyalog APL]]. [[Extended Dyalog APL]], used infrequently in the [[code golf]] community, has also had a significant influence on [[Dyalog APL]]. The APL Wiki should include information about these languages because they will likely continue to influence APL's direction in the future. However, it's also important to make sure that this information, which is of theoretical interest, doesn't interfere with practical content. It should generally be placed lower in articles or sections of articles, and the text should make it clear that this material probably doesn't apply to the reader's APL of choice, usually by specifying which language or languages it is taken from.


== Notability ==
== Notability ==
Line 38: Line 32:


In general, only the APL-related aspects of a topic are notable. [[IBM]] has done a lot of things, but only its effects on APL or on APL developers belong in its APL Wiki article. Anything about IBM which is more generally notable by Wikipedia's standards should be on Wikipedia! This constraint is relaxed somewhat for articles on topics which are not found on Wikipedia. Keep the article focused on APL but it is fine to include expanded biographical or historical information for such topics. Relationships between two topics covered in the APL Wiki, even if they are not because of APL, should be included as well.
In general, only the APL-related aspects of a topic are notable. [[IBM]] has done a lot of things, but only its effects on APL or on APL developers belong in its APL Wiki article. Anything about IBM which is more generally notable by Wikipedia's standards should be on Wikipedia! This constraint is relaxed somewhat for articles on topics which are not found on Wikipedia. Keep the article focused on APL but it is fine to include expanded biographical or historical information for such topics. Relationships between two topics covered in the APL Wiki, even if they are not because of APL, should be included as well.
== Due weight ==
Because the [[#What is APL?|definition]] of APL is not rigorous (a particular language may be more or less APL-like), the notability guidelines above can be interpreted more strictly or more loosely. To determine whether content belongs on the APL Wiki at all, a loose interpretation is better. For determining how content is presented, however, editors should consider not just whether a topic is related to APL but how closely related, or central to APL, it is. Even a recent and niche development like [[Reverse Compose]] has a place in the Wiki, but most information about the primitive should remain on its own page and mentions on more central pages should be qualified in order to make it clear the primitive is not available in most APLs. In contrast, a topic like [[Outer Product]] can be mentioned anywhere, and omitting it from related articles like [[Inner Product]] or [[Each]] would be a mistake in emphasis.
To be central to the concept of APL, a language needs '''adherence''' to APL principles and '''prominence''' in terms of its user base or in the APL community. Adherence is measured roughly by the definitions above: languages that satisfy more of these definitions, and more closely, adhere better to the concept of APL. Prominence is determined by how many people use a language, how many of these are part of the APL community, and how strong an influence the language has had on the development of APL.
Keep in mind that many APL users are not very visible to the outside world and don't publish anything about their usage (especially after the decline of the [[APL conference]]). For example, you are unlikely to see recent material about [[APL2]], but it is still widely used, and it's reasonable to think these users will look to the APL Wiki as a resource. As an editor you aren't expected to know every prominent language in order to contribute, but please think twice before removing material about a language you don't think is prominent. Evidence that the language is still in use might include major companies using it, active support forums, or significant development on the language indicating that it makes enough revenue to support this development. Significant historical use is also a sign, as usage of a particular APL rarely dies out quickly.
A language can be prominent even if it is very rarely used, or in extreme cases never implemented. This is the case for research languages that are important in developing features later picked up by more prominent APLs. For example, [[A Dictionary of APL]], while only an incomplete description of how one APL might work, strongly influenced [[J]] and subsequently [[Dyalog APL]]. [[Extended Dyalog APL]], used infrequently in the [[code golf]] community, has also had a significant influence on [[Dyalog APL]]. The APL Wiki should include information about these languages because they will likely continue to influence APL's direction in the future. However, it's also important to make sure that this information, which is of theoretical interest, doesn't interfere with practical content. It should generally be placed lower in articles or sections of articles, and the text should make it clear that this material probably doesn't apply to the reader's APL of choice, usually by specifying which language or languages it is taken from.


== Verifiability ==
== Verifiability ==

Navigation menu