[DISCUSSION] Technical Content Policy Amendments

Re: [DISCUSSION] Technical Content Policy Amendments

Wed, 12 Oct 2022 12:01:57 +0000

Generally fine with the amendments, save maybe that "substantial or major differences between the versions" is not necessarily rigorously defined, though I know that it is unfeasible to do so beyond case-by-case basis. Admittedly I am having some trouble envisioning the extent of which this can be enforced.

Re: [DISCUSSION] Technical Content Policy Amendments

Wed, 12 Oct 2022 03:46:38 +0000

I am fine with these changes.

Re: [DISCUSSION] Technical Content Policy Amendments

Wed, 12 Oct 2022 02:25:45 +0000

The original version of this policy that was proposed allowed for this, using a phrasing of "open series" to refer to the most recently opened series as well as the one before that in times shortly following a K-Con. However, it was pointed out that "open series" was not an intrinsically obvious term, and we don't officially close series, so there was no good way to formally rule this out. When I was looking at the policy, it occurred to me that coming up with the rules and formalities to clearly define "open series" just wasn't worth the effort for the minor benefit of these 1-series-down-from-most-recent-series moves. Although we all generally know what is being referred to with "open series", it would need a specific definition and locking that down wasn't worth the effort, for the much simpler and clearer "most recently opened series".

Re: [DISCUSSION] Technical Content Policy Amendments

Wed, 12 Oct 2022 01:02:45 +0000

I'm totally fine with most of these amendments. Just a question — right now, there wouldn't be any issue with renaming a piece from Series 8 to Series 7. I'd speculate that while that occurrence is currently rare, it wouldn't be unreasonable for someone to do a 1-series-down move so long as a reasonable number of slots remain open in S7, when this renaming rule is meant to prevent shenanigans in claiming slots in lower series. For a reasonable amount of time after a series opens, someone could run afoul of this rule without even realizing they were doing anything wrong.

Is this worth addressing/patching? I can't think of an easy fix that would make allowances for "honest mistakes". I'd hope someone else can, because as it stands I still support that amendment as written.

Re: [DISCUSSION] Technical Content Policy Amendments

Tue, 11 Oct 2022 19:42:00 +0000

Well, the backend of the component is just the module — so they aren't significantly different things. But ultimately that line is a recommendation, not a full policy change. I don't want to strictly require 1:1 parity, and one or two short sentences not being visible is relatively acceptable. SCP-902, for example, is not significantly impacted by the absence of the following line:

Don't open it, stormbreath. It wants you to. It needs you to. Please, stormbreath, open it. Before it's too late.

And this would not need to use the component to provide an audience-neutral version of the text.

Re: [DISCUSSION] Technical Content Policy Amendments

Tue, 11 Oct 2022 19:29:47 +0000

If the ListUsers component can replicate the functionality of the Wikidot module, why allow the module at all?

Re: [DISCUSSION] Technical Content Policy Amendments

Tue, 11 Oct 2022 19:09:00 +0000

Fine on all of this, honestly was unaware the Adult Content stuff was contained in the Tech Policy or I would have tried to make these changes when posting the new policy.

[DISCUSSION] Technical Content Policy Amendments

Tue, 11 Oct 2022 19:00:16 +0000

The Tech Team is bringing forth a bill to change one existing area of the Technical Content Policy, and add three more. These changes can be seen on this sandbox page and are discussed in further detail below.

Adult Content Pages

(This change is not reflecting in the above sandbox link.)

This section is to be removed in its entirety. The entirety of this section has been deprecated by changes to how adult pages are handled, and the removal of the adult: category means that this is no longer an element of policy that needs to be mandated by the Technical Team. The only portion of the Technical Content Policy that remains relevant is the final line:

The URLs of pages are never permitted to contain adult content.

This line is to be relocated into the Adult Content Warning Guide.

ListUsers Module

The ListUsers module, which calls upon the username of the reader, is a tool that is frequently used on the wiki. However, it allows for the display of different articles or content based on whether a user is logged in or not, which is less than ideal. This can significantly complicate various parts of site function, such as how the article is tagged or should display. Furthermore, it could potentially allow an entirely different article to be displayed to users who are not logged in, which would be the most prominent and frequently seen version of the article, but functionally immune to voting.

This policy is to limit the degree amount that ListUsers is used, and make sure that articles are not significantly different to a user who is not logged in. It is written in a way that should not effect existing content on the wiki.

Link Shorteners

You cannot see the end destination of a shortened link or QR code and QR codes can have security exploits or download malicious files. Further, there is no use for them on the Wiki, as the character limit is 200,000, more than sufficient to handle long links. As such, the Tech Team moves to ban these.

Page Renaming

The first half of this section is more of a guide, and seeks to codify the basic rules that we have around moving pages into new urls. Nothing here is new, except for the list of steps, which simply seeks to provide reference for the best case procedure that Tech Team members try to follow when they need to rename pages.

The section in the green box, however, is a new line of policy. It seeks to prevent a rather unpopular form of slot sniping, in which a user who doesn't have a near complete or finished article simply moves an article they have already posted into a newly opened slot. This extant article is able to sneak into the slot and will normally have a high rating, so it will claim the slot in a manner that our users frequently find unfair. The proposal in the green box seeks to limit this while not restricting other cases of slot renaming. It will be put to a vote separate from the other sections.

This thread is open to all staff and will last for one week. The 04 version of this thread can be found here.