Template talk:OBD File Header: Difference between revisions
Jump to navigation
Jump to search
(gee, this took longer than expected) |
m (fixing wiki link that was external instead of internal) |
||
| Line 1: | Line 1: | ||
I am rolling back the synopsis thing for the following reasons. | I am rolling back the synopsis thing for the following reasons. | ||
#Expecting an army of contributors to promptly fill in brand new templates is typical wishful thinking and as such should be discouraged. We are a small community, so don't start an overhaul unless you are ready (both in terms of free time and knowledge) to take it to completion ''on your own''. The followup to your initiative (or the lack of a followup) is under ''your'' responsibility and no, responsibility is not about excuses, let alone blaming others for poor team spirit. In short, when adding features to an existing database, compulsive behaviour is Right Out (and we've been through this [ | #Expecting an army of contributors to promptly fill in brand new templates is typical wishful thinking and as such should be discouraged. We are a small community, so don't start an overhaul unless you are ready (both in terms of free time and knowledge) to take it to completion ''on your own''. The followup to your initiative (or the lack of a followup) is under ''your'' responsibility and no, responsibility is not about excuses, let alone blaming others for poor team spirit. In short, when adding features to an existing database, compulsive behaviour is Right Out (and we've been through this [[Special:Permalink/9290|BEFORE]]). Think before you act, seek advice from a potential contributor or from anybody you can explain your plan to (formulating a plan to someone else typically helps to expose its flaws and more generally leaves you some time to cool down), think again, then act, and then think some more. | ||
#Regardless of etiquette, the "synopsis" as it was implemented was a mistake. The center of the header was reserved for the TOC, and the synopsis was interferring with it, badly. You should definitely check the impact of your edits on the whole database (i.e., the consistence of your ideas with the previous design and use of the template) before you wash your hands and walk away. | #Regardless of etiquette, the "synopsis" as it was implemented was a mistake. The center of the header was reserved for the TOC, and the synopsis was interferring with it, badly. You should definitely check the impact of your edits on the whole database (i.e., the consistence of your ideas with the previous design and use of the template) before you wash your hands and walk away. | ||
#Even if we agree that all OBD entries deserve ''some'' kind of summary, there's nothing systematic about the length of such overviews: some instance types hardly need an explanation, or they may make sense only when considered together with their parents, and some instances store so much different data that it's impossible to provide decent information about them in just a few sentences. So in the big scheme of things, systematic synopses are a delusion; overviews are highly specific to the nature of the entity being documented. Therefore, it is more apt to provide overviews in free form, below the templated header and before the actual documentation. It is also possible to review the features of the subcomponents of a complex instance type immediately after section headers and before the respective fragments of documentation. Plain wikitext is a much more flexible didactic tool than a fancy header, and moreover such free-form overviews already are (or were) present on some OBD pages, meant precisely to introduce the features and purpose of the instance types, in moderately technical terms. | #Even if we agree that all OBD entries deserve ''some'' kind of summary, there's nothing systematic about the length of such overviews: some instance types hardly need an explanation, or they may make sense only when considered together with their parents, and some instances store so much different data that it's impossible to provide decent information about them in just a few sentences. So in the big scheme of things, systematic synopses are a delusion; overviews are highly specific to the nature of the entity being documented. Therefore, it is more apt to provide overviews in free form, below the templated header and before the actual documentation. It is also possible to review the features of the subcomponents of a complex instance type immediately after section headers and before the respective fragments of documentation. Plain wikitext is a much more flexible didactic tool than a fancy header, and moreover such free-form overviews already are (or were) present on some OBD pages, meant precisely to introduce the features and purpose of the instance types, in moderately technical terms. | ||
::[[User:Geyser|geyser]] 05:54, 9 September 2008 (CEST) | ::[[User:Geyser|geyser]] 05:54, 9 September 2008 (CEST) | ||
Revision as of 03:23, 8 May 2017
I am rolling back the synopsis thing for the following reasons.
- Expecting an army of contributors to promptly fill in brand new templates is typical wishful thinking and as such should be discouraged. We are a small community, so don't start an overhaul unless you are ready (both in terms of free time and knowledge) to take it to completion on your own. The followup to your initiative (or the lack of a followup) is under your responsibility and no, responsibility is not about excuses, let alone blaming others for poor team spirit. In short, when adding features to an existing database, compulsive behaviour is Right Out (and we've been through this BEFORE). Think before you act, seek advice from a potential contributor or from anybody you can explain your plan to (formulating a plan to someone else typically helps to expose its flaws and more generally leaves you some time to cool down), think again, then act, and then think some more.
- Regardless of etiquette, the "synopsis" as it was implemented was a mistake. The center of the header was reserved for the TOC, and the synopsis was interferring with it, badly. You should definitely check the impact of your edits on the whole database (i.e., the consistence of your ideas with the previous design and use of the template) before you wash your hands and walk away.
- Even if we agree that all OBD entries deserve some kind of summary, there's nothing systematic about the length of such overviews: some instance types hardly need an explanation, or they may make sense only when considered together with their parents, and some instances store so much different data that it's impossible to provide decent information about them in just a few sentences. So in the big scheme of things, systematic synopses are a delusion; overviews are highly specific to the nature of the entity being documented. Therefore, it is more apt to provide overviews in free form, below the templated header and before the actual documentation. It is also possible to review the features of the subcomponents of a complex instance type immediately after section headers and before the respective fragments of documentation. Plain wikitext is a much more flexible didactic tool than a fancy header, and moreover such free-form overviews already are (or were) present on some OBD pages, meant precisely to introduce the features and purpose of the instance types, in moderately technical terms.
- geyser 05:54, 9 September 2008 (CEST)