Forum:Standardized terminals layout III - The Revenge of the Transcripts

So, after months of debating, proposals, counter-proposals, and stringing people up by their guts, I would like to finish this once and for all. The following is CompleCCity's proposal put in policy form.

=Proposals=

Raw Data

 * Raw data should be pulled directly from the game's files when practical and include the following information, where available: EditorID, FormID, contents, and any additional information pertinent for wiki use (such as model used).

Terminal pages layout

 * All pages containing terminal transcripts should be distinguished by the terminals suffix (or terminal, in case there is only a single one on-location), appended to the location name for the relevant terminal.
 * If the location name is unavailable, such as with generic terminals, a name describing its function is used.
 * Terminals are sorted according to relevancy. If relevance cannot be established clearly, alphabetic order is used.
 * Terminals use descriptive names, derived from their owner, content, function, or editor ID, for ease of navigation.
 * The name as it appears in the game, editor ID, and form ID should be noted.
 * Shared content should only be transcribed once per page and the contents linked to from relevant terminals.
 * Terminals with generic content, such as turret control, safe, door terminals, are linked to under a separate head, rather than transcribed in full.
 * If pages are difficult to navigate due to the amount of terminals, they should be divided into additional pages, distinguished by location (such as The Institute terminals (BioSciences) or H&H Tools Factory (upper floor)).

General guidelines

 * Navigation and usability are key. If the page is cluttered and the table of contents cannot be understood at a glance, the page requires revision.

=Administrative=

Proposal commentary
As can be seen above, the policy is effectively reworded CCC's work. It's a bit legalese, but should allow us to manage the terminal pages with a proper standard this time. Tagaziel (talk) 16:16, 29 March 2016 (UTC)

Votes

 * Yes Tagaziel (talk) 13:53, 30 March 2016 (UTC)
 * No Ant2242 (talk) 22:28, 29 March 2016 (UTC)
 * Yes GarouxBloodline (talk) 15:06, 31 March 2016 (UTC)
 * Yes -- UserCompleCCity Signature1.png -- You like to talk to me? -- cCContributions --

Comments
What does "when practical" mean to you? We need it. All of it. I believe that it is best if we just use the same format as the FO3 and FNV terminals. I don't see any missing parameters in this format.
 * Raw Data
 * Terminal pages layout
 * I agree with the terminals suffix. I believe that it is about damn time we actually overview properly.
 * I disagree on the "relevancy" portion. It should be on a beginning to end basis. That is the first terminal likely encounters followed by the next and so on. This is what the articles currently express.
 * I also disagree on changing the names of the terminal. We cannot do this, period. However we could add in parenthesis a description when needed to distinguish from generically named terminals. IE "Terminal (SRB terminal 1A)"
 * If we need to add the Form ID and Editor ID how should we do so? Are we going to create a table template? Are we just going to add it to the specific "Note:" section?
 * If there is only one "shared content" on the page then yes. However if there is multiple unique terminals with the same "shared content" then Absolutely Not. All terminals presented must be as is in game, with our notes on what their parameters and locations are.
 * Absolutely Not!
 * Umm.... -_- ... How we separate terminals is By Location. It is the most efficient way to account for the terminals in game, and present them in a manner easiest to access and digest.
 * As a side note, the H&H Tools factory terminals is fine. Only needing a parameters check and a page move. (Both of which are projects in and of themselves, as we cannot just do this on one page and leave all the redirects.) The Institute terminals however might best be split, however lets wait a bit I am still trying to find several of them. (Format and missing content is being added.)
 * General guidelines
 * The newly parenthesized headers should cover this completely. As for "cluttered TOCs" that is up to Bethesda, as we cannot remove or add terminals that are not in said location.

--Ant2242 (talk) 22:28, 29 March 2016 (UTC)

Weren't there some edits/adds intended? Shouldn't those be implemented before all people vote and the poll closes? And "relevancy" should be changed to "relevance". -- -- You like to talk to me? -- cCContributions -- 14:12, 31 March 2016 (UTC)
 * To my current understanding, this is to get the policy foundation set up. What was discussed otherwise, that is not included here, were my proposed guidelines for the policies, from the prior discussion forums. Should the policy go up, I will be implementing what we have discussed, as well, and I will put them up on a forum for additional criticism, before they become official. GarouxBloodline 15:08, 31 March 2016 (UTC)