Hey everyone. This has been mentioned on the Discord, but I'm making a thread here.
On the wiki, we seem to have a lot of "unwritten rules" and existing consensus:
And I'm sure there are issues (especially attribution and community stuff) we haven't thought of.
What should go in a Dev Wiki policy?
I would be tempted to say yes, but are you really sure about it? I always interpreted that phrase as "don't fix or improve anything". Whereas the author control rules are less restrictive (unless the author says no).
Ye, thats kinda saying that nobody can touch it for whatever reason. Also as an example, a script has an XSS expolit, but still works, so does that mean nobody can touch it? Also "author control" is kind of an interesting topic, since you can't very well control something you willingly submit to a public wiki where anyone can edit it.
Examples of things that technically "weren't broke" in the past:
The list goes on. Perhaps "if it's not broke, don't fix it" is antithetical to wiki culture? ?
Agreed that "be careful and pay more attention on what u do" is important. Some of the chat scripts here often break, preventing users from entering chat or moderating.
Does anyone want to add something to that effect (link here)?
Thanks for adding it, Kocka. A note about cookbook stuff is also added ("must not offer trivial code or guidance (examples.."). Be back Monday to move the draft.
This just came to mind, but should we make it a thing to not translate changelogs? I don't know how fellow translators feel on this yet but, I hate having to update translated docs frequently.
We could make Changelogs english-only but that's what they basically are already, since translation pages get updated so rarely.
according to last events, i have to bring If it's not broke, do not fix it back. and to suggest to add it explicitly to the wiki policy. with exactly same meaning: do not touch something that has not to be touched.
me personally not a big fan of "break it by rewriting" things. we need some defense against such actions.
I would temper the above suggestion to cover deprecation. Scripts that work but are not representative of current standards and have been replaced should be considered deprecated. Deprecated scripts may receive bug fixes if necessary, but should not be recommended (new installations should use whatever replaced with. Deprecated scripts should not be overhauled significantly to the point where a major version bump could be considered.
Older scripts that should not be used but are potentially in use would be covered under this amendment. Scripts that are broken by an update and need significant changes would not.
Essentially:
