Contributing to the Computer Dictionary Project
Help Make it Better
The Computer Dictionary Project is an Open Source project released under a Creative Commons license. This means we operate as a "Gift Culture." In gift cultures, social status is determined by what you give away, not by what you control. So there are many ways a person can contribute to the Computer Dictionary project. You can participate directly by adding new terms, markup, editing, proofing, testing (reporting bugs), checking, answering questions, proposing ideas and much more.
To begin with, we suggest you subscribe to the Computer Dictionary mailing list. Tune-in to the discussion to get an idea of what is happening and to hear how others make contributions.
You may also want to get a local, working copy of the latest source code. The source code is stored in our Subversion repository.
Once you are subscribed to the mailing list and have your local working copy, we suggest you briefly review the Bug & Issue Tracker to get an idea of the type of issues people post.
Things to do
There is always something to do. The first place to check is our Issue Tracker. If you have something to do and cannot find it in the issue tracker, then post your idea to the mailing list to see what others think. If you feel your idea is worth pursuing, then add it to the issue tracker. Happy hacking.
Dictionary Guidelines
To avoid confusion and maintain some level of consistency throughout the glossary database a number of guidelines have been applied. The guidelines are generally taken from recognized sources of authority. However, even sources of authority tend to contradict one another, so the guidelines below will indicate which authority takes precedence on the given issues.
What gets defined
What is a term?.
"A word or expression; specifically, one that has a precisely limited meaning in certain relations and uses, or is peculiar to a science, art, profession, or the like; as, a technical term. "Terms quaint of law.'' --Chaucer." -- Websters.
What is computing?
"the branch of engineering science that studies (with the aid of computers) computable processes and structures [syn: computer science]" -- WordNet.
Therefore, what gets defined are all terms used in context of computing. All terms and product names, both non-proprietry and proprietary.
Organization
The glossary database is arranged according to the 7-BIT Printable ASCII table that represents 128 different character values (0-127).
We have used this method of organization because ASCII enables us to define the order or characters such as periods, commas, hyphens, forward slashes, backward slashes, etc.
Spelling
The project uses American Spelling (US English), for content of the Web site and glossary database.
The dictionary that takes precedence is Mirriam Websters Online Dictionary.
Style
The style used in the glossary follows the Chicago/Turabian style. The best reference resource is therefore The Chicago Manual of Style.
The Chicago Manual of Style takes precedence for all issues of style unless expressly stated otherwise on this Web site. An additional style reference is, "The Elements of Style." However, disputes will always be resolved in favor of Chicago/Turabian style as this is the governing style adopted by majority of the authoring and publishing industry.
In the technology world terms often start as two individual words, later the two words or joined by a hyphen, and finally the hyphen is dropped and the two words are concatenated together into a single word that becomes a term. As a result, terms are often seen used in all three forms; something that is most confusing to authors and editors.
To be consistent we have chose to adhere to the 'one word' method of spelling terms. For example, 'database' as apposed to 'data base.' This is also the most common form in which to find technology terms.
The only exception to this guideline is when a term is purposely hyphenated to make reading easier. For example, 'E-1', '10Base-T,' 'HiPeR-LAN,' or 'HALF-repeater' as apposed to 'E1', '10BaseT,' 'HiPeRLAN,' or 'HALFrepeater'.
Measurement
For consistency we use the International System of Units (SI).
For the purpose of this project we are interested in the "Base Units," "Derived Units," and "Metric Prefixes."
In accordance with Chicago/Turabian style, values and their measure are separated by a space.
For example,"The term E-1 is defined by the European Telecommunications Standards Institute (ETSI) as 2 Mb leased line (or 2.048 million bits per second or 32 channels of 64 Kbps to be exact)."
Plurals
Use of plurals is another area of confusion to authors and editors. As with everything, Chicago/Turabian style takes precedence in this project. One area of specific confusion when it comes to computer terms is with acronyms. Most people mistakenly add an apostrophe and letter 's' to make an acronym plural. The major proponent of this incorrect method is "The New York Times," even though all publishing houses and computer magazines agree that it is wrong.
The correct method is just to add the letter 's' to the acronym. Here are some examples:
- PBXs (not PBX's)
- VLANs (not VLAN's)
- NICs (not NIC's)
- PCs (not PC's)
The possessive of an acronym plural has the apostrophe after the s.
- PBXs'
- VLANs'
- NICs'
- PCs'
The only time we accept an 's is when the acronym is separated with periods. For example, Ph.D.'s.
Indefinite Articles
Uncertainty often arises with regard to proper choice of an indefinite article before abbreviations. Many people mistakenly adhere to what we call 'the first letter rule.' This rule states that, if the abbreviation starts with a vowel then the indefinite article 'An' is used and if it starts with a consonant then 'A' is used. This is not so.
There are a number of methods around that provide a way to determine whether to use 'An' or 'A'. Here follows our method that is based on Chicago/Turabian style and the common style used by technical editors. The general rule is as follows.
When an abbreviation is said as a word 'the first letter rule' can be applied in most cases. If an acronym is pronounced as a string of letters the following can be applied:
- An A
- A B
- A C
- A D
- An E
- An F
- A G
- An H
- An I
- A J
- A K
- An L
- An M
- An N
- An O
- A P
- A Q
- An R
- An S
- A T
- A U
- A V
- A W
- An X
- A Y
- A Z
Bibliographic References
Text
Work Procedures
This the part where we ask people to do and not to do things.
There are a number of working methods that help avert problems:
-
Think about the problem - Give a problem due consideration. Is it local or general. Local problems are easily solved. General problems can take more time.
-
When in doubt, kick-out - When uncertain, it is better, to do nothing and discuss the matter with the community. This way, when you make the change, there is less chance of your work being redone and having been for nothing. It saves your time and others.
-
Submit patches often - Rather than leave your modifications for days, create a patch at the end of your work session and submit it. This way others can check it, discuss it and perhaps add to it earlier.
There are a number of practices followed on the mailing list. They are there to preserve the integrity of the mail archive, reduce traffic, and generally make life easier.
-
Look before you leap - Before posting messages please check the user mail archive to see if somebody has already asked the question you wish to ask and whether or not somebody has replied with an answer. If you are posting a suggestion, remember to check the project issue-tracker, perhaps someone else has already posted the same suggestion.
-
Don't be shy, talk to everyone - Some people are shy and prefer to hold conversations related to project matters in private messages outside the mailing list. Please, reply to the list, remember that others want to listen-in and will comment when they have something useful to say. Posting outside the list means you lose "the power of the community." Also, there are no stupid questions and not knowing something is not a sin. You cannot be a 'guru' on every subject.
-
Keep to the subject - People have a tendency to want to say everything in a single message. The result is that the subject of the message actually covers several subjects. This makes it hard to find messages in the archives and makes the thread harder to follow. If you have two or more issues to discuss, post them in separate messages.
-
Don't change the subject - Don't change the subject of a message unless the topic changes in natural conversation. Changing the topic breaks the thread and makes it hard to follow in the mail archives.
-
Keep it short - Try keep messages short and to the point. If you are replying to a message use 'smart quoting' and quote indicator ( > ) on the original message to attribute the original message to a sender and denote which text belongs to the original message. Trim the original, chances are others have seen the first message and are only interested in the part you are replying to. This makes messages easier to read and dramatically reduces the download payload to everyone on the list.
-
Copyless - if you're posting a message and have reference to a message in the mail archive, link to it, don't copy paste. The same applies to pages or anything-else that can be accessed via a Web Browser.
-
Don't post attachments - attachments should generally go in the issue tracker against a ticket. If you feel it does not belong there, then put it on a href and link to it.
-
Have fun - what more can we say.
