Overhauling page creation

An unindexed page list similar to the untyped list would be good.

I think, also, that this overhaul could be accomplished in 2 steps. I've noticed that about half the untyped pages are subpages, and I've forgotten to type those myself. Yet they usually don't need any additional help (except YMMV pages pointed at real people). At the same type, subpages aren't the source of most problems, such as those that land in TRS. But the subpage system needs to be changed with or before the creation system for other pages.

My thought is that the subpage overhaul could be programmed first, separately. If it's likely to be a long time before the main/trope/work/index creation overhaul is done, the untyped pages list could also be turned into a queue since it often contains stubs and badly formatted things.

edited 13th Dec '12 8:25:23 AM by ArcadesSabboth

Oppression anywhere is a threat to democracy everywhere.

Oh, I completely agree that we need the subpage overhaul first, and urgently so.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

This might be unrelated but how easily could the auto-indexing system for Trivia (which I'm guessing is tied to having its own page type) be extended to all subpages and contributor pages? Right now things like WMG have to be indexed manually, and some (YMMV and Tropers) seem to have no indices.

If a new subpage system was set up to provide automatic templates for such pages, could it also index them?

edited 13th Dec '12 8:37:46 AM by ArcadesSabboth

Oppression anywhere is a threat to democracy everywhere.

One assumes. I'm not the one who would be programming it but that would be a very good idea.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Some last thoughts on the create page function (Addressing the first and last bullet points as @100):

• That notification would be a bit more detailed than "Yes, approved", "No, disapproved", yes? I also think that avoiding the "black box" issue can be made easier by making any discussion on borderline cases in a publicly viewable thread or board. @94 could also do something similar.
• I would phrase that differently "This page will be submitted for the [approving group] for approval, since it already existed at one time.

About @94: I think the dividing line whether to use such a panel or no is the duplicate page issue - you need to be familiar with many pages to know whether a given page is a duplicate or no. I also think that the restoration of previously cut pages (last bullet of @100) could be trusted to such a group, although it's mostly optional.

Now about the subpage issue...

I think we can agree upon at this moment that sorting out which of the currently used namespaces can be put off to later. It's likely going to be a non-trivial solution, though.

The biggest problem I see with subpages is that while we had on the first page of the thread a few suggestions about how the URL might look like, none of these easily translates into a good way to wikilink subpages.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

The wikilink markup would need to be expanded, I think. Maybe with a special separator character to denote subpages.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Ok, one option is to simply use Namespace/Page[somesymbol]Subpage here. With [somesymbol], some things that came into mind are @ and /. I think the best symbol to use would be the one that will be used in the URL.

Another questions here is how many levels of subpages we want. Wikipedia apparently allows infinite amounts, but on TV Tropes it's possible that the architecture of the backend would limit the amount of subpage levels we can create. I think that 2 levels is probably best, as several subpages can themselves use to have subpages.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

Okay, I'm officially confused. I don't seem to recall anyone saying that anything other than tropes and Administrivia pages would be forced to go through YKTTW, yet now we're simultaneously saying that "we don't want YKTTW to be seen as mandatory" and considering what types of pages would require YKTTW.

Mod approval could be as simple as a mod creating the page as blank, and I'm not sure under what circumstances TRS would create a new page without YKTTW or mod approval.

Why was autolocking imposed again? Was it just to force proper namespacing? I believe I suggested elsewhere that cut pages could display a reason why they were cut. Except you only have a single dropdown for indexes. The easiest way to "fix indexing" that might not even need your proposal to work is to make them more like Wikipedia's categories. Failing that, I believe I mentioned earlier the idea of automatically bugging the page creator to add the page to indexes (and crosslink more generally, which is the real problem) and, if YKTTW drafts were actual wiki pages, you might be able to allow people to add pages that haven't launched yet to indexes. Depends. Both the subpage overhaul and new page creation system could involve an overhaul of the entire wiki's infrastructure; the subpage overhaul will involve a new method of creating subpages and may require limiting the number of namespaces early. In any case, we need to hash out what the subpage overhaul is first, especially since Fast Eddie defended the notion of numbered subpages last page. I thought all Tropers/ pages were auto-indexed in The Contributors (though I think it might be buggy), and I know Quotes Wiki and Laconic Wiki redirect to their respective namespace lists, which also serves as the index for those pages. While auto-indexing WMG pages might be one solution to the "intersection" problem with WMG (and Headscratchers, and maybe Fridge and Moments, but not tropes), it might be a good thing for WMG to continue to be indexed manually; I suppose you could auto-categorize by medium, but even the medium pages often nest pages in bullet points. Automatic templates are a lot simpler; you just pick a subpage type, and it prefills the article text with the proper format for that type. You could extend the same idea to full-fledged page types, which might be a good idea to prevent badly-written non-YKTTW pages. If you're saying that's who you would appoint to such a panel, I'm familiar with a lot of pages and flagged a few duplicates (though I don't really hang out in YKTTW all that often because Caring About TV Tropes Will Ruin Your Life), but I've never given a hat to any YKTTW because I don't trust myself to be familiar with all the ins and outs of whether or not one is ready, or whether or not there's a really obscure duplicate no one has found yet (heck, just look at how I became the Trope Namer for the term Wick), and I think the closest I've ever come to launching one was Prophecy Twist (from a discussion page) and Viewers Are Morons, waaaaaay back when YKTTW was an ordinary wiki page, and neither of which came from said page. (I don't think I added many of my own namesakes when I created The Sports Guy either.) I think Namespace Sorting has actually done most of the work, if I do say so myself, though I admit subpages are one of the dicier areas where this is concerned. (See: how much work needs to be done before we even know how the subpage system will work.) However, I think the main areas still to be sorted out beyond that are a) figuring out what to do with the "unofficial" and "only one page" media namespaces, b) translations, and c) the Special Cases folder. For some reason I'm thinking there might be some Characters and WMG pages that would require more levels than that. I also feel the need to re-raise the issue of trope/work intersections, where a particular trope has an example page dedicated to a particular work that that work also uses as a subpage. Some particularly popular tropes go so far as to have their own namespace bar icons, like Getting Crap Past the Radar.

in bullet points:

• We are thinking of Administrivia/ and Main/ for the control mechanism. Which namespaces exactly can be controlled with the Namespace List tool I'll explain later. Also, TRS threads often work with sandboxes to circumvent the problems of YKTTW.
• Autolocking was imposed to prevent the indiscriminate restoration of cut pages.
• The index thing, I proposed a list of unindexed pages similar to untyped pages.
• The subpage thing, I assume that Eddie's proposal is basically Page1 being a subpage of Page?
• Tropers/ is indexed by pagetype. With WMG and Headscratchers, there is discussion of changing them away from being wiki pages. I'll address templates and boilerplates later on.
• The panel thing will need further consideration.
• Sandbox.Namespace Sorting is a good start, but not definitive.
• This would be part of the Namespace Sorting.

Now a bit more from me: I thought that the best way to deal with namespaces and subpages is by creating a Namespace And Allowed Subpages, Perhaps The Latter Listed By Namespaces list editable and controllable to mods^note The namespaces and subpages change quickly enough that we can't rely on the development queue and publicly viewable^note Madness will ensue in the namespace migration if it isn't visible which controls the following parameters:

• The allowed namespaces.
• All the subpages enabled for each namespace (optional, might become a long list if we list namespaces and their subpages for each, then we'd need a similar tool to the allowed namespace list, but for subpages)
• The namespace icons
• A checkbox to decide whether they are free to create or need either "Mod, YKTTW or forum thread"
• Banners (in order to banner namespaces/subpages in their entirety)
• Background colours (same reason as for banners, optional)

I also think that creating autoloading templates for certain pages would be useful.

Eta: Deleted a sentence that didn't make sense anymore.

edited 14th Dec '12 6:53:03 AM by SeptimusHeap

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

@Septimus: I agree with all of the above. I would say that, rather than an exhaustive subpage list for each namespace, it would be easier to classify pages by a general type (trope, work, creator, etc.) and then build subpage lists for those types. The namespace concept as it stands is kind of schizophrenic; it can't decide whether it wants to indicate an article type or a media category. I'd rather separate the two concepts entirely, but that might have to wait for a hypothetical TV Tropes 2.0.

I think in terms of data structures because I'm a database programmer.

edited 14th Dec '12 6:51:19 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

OK — I admit that the discussion of subpages and urls mostly confuses me. But. I have a suggestion for urls that might help both the "overlapping page names" and "indexing WMG/Headscratchers/etc." issues.

Currently, subpages are like this:

• Literature.The Hobbit
• Film.The Hobbit
• WesternAnimation.The Hobbit
• YMMV.The Hobbit
• Headscratchers.The Hobbit
• Trivia.The Hobbit
• Characters.The Hobbit
• Main.Hobbits

etc.

The subpages have their own namespaces, and so any time you want separate subpages for works or tropes that share names, you get problems. But what if they were instead something like this:

• Literature.The Hobbit
• Film.The Hobbit
• Literature.The Hobbit[symbol]YMMV
• Literature.The Hobbit[symbol]Trivia
• Film.The Hobbit[symbol]YMMV
• Film.The Hobbit[symbol]Trivia
• Main.Hobbits
• Main.Hobbits[symbol]Subpage

This first of all automatically separates subpages of same-named-pages, and sorts WMG and Headscratchers by medium, which may make auto-indexing possible for them. If you want a franchise to share a subpage across media, you can either make it Franchise.Work.Subpage, or use the medium namespace of the main/original/best-known version. Thus Film.The Hobbit could share Literature.The Hobbit[symbol]Headscratchers and Literature.The Hobbit[symbol]WMG if desired.

EDIT: Another option would be to make nested urls like this when there is more than one work of the same name in the same medium:

• Film.Work[symbol]1983
• Film.Work[symbol]2002

with Film.Work as a disambig.

This might not help subpages, but I think it's better than

• Film.Work (1983)
• Film.Work (2002)

edited 14th Dec '12 10:27:01 AM by ArcadesSabboth

Oppression anywhere is a threat to democracy everywhere.

That's my thought precisely.

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Also, to help people find subpages that are under a different "namespace" (as if a franchise is sharing a subpage across media categories) the subpage listing on the sidebar could list all pages that share the same name, regardless of subpage or namespace.

Thus, if I visit Film.The Renfield@1983 I can see that the sidebar lists and links

• Film@1983
• Film@2002
• Film@Characters
• Literature
• Literature@Characters
• Franchise
• Franchise@WMG
• Main

And I can see immediately that there's a trope of the same name, that the WMG is shared across the franchise, but the characters are separated by medium.

If numbered subpages also existed, you could potentially also do this:

• Film.The Renfield@YMMV 1 (for 1983 film)
• Film.The Renfield@YMMV 2 (for 2002 film)

And thus give them separate subpages as well.

edited 14th Dec '12 10:33:58 AM by ArcadesSabboth

Oppression anywhere is a threat to democracy everywhere.

I'd rather distinguish identical work titles in the article title, not by subpage ID.

So, Film.The Renfield 1983@YMMV and Film.The Renfield 2002@YMMV, with Film.The Renfield as a disambiguation, rather than the way you have it above. There should never be a need to disambiguate the subpage, or changing it is pointless. Disambiguation should be done at the primary article level, and disambigs should never have subpages.

edited 14th Dec '12 10:40:14 AM by Fighteer

"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

Why are you using namespaces and not page types to control when someone can create a page? At least on the user level, page type will be the most basic decision they need to make; blocking direct creation can be determined by whatever comes up to create a page of that type. Blocking by namespace makes it needlessly harder to create redirects (and possibly disambigs and indexes, though I don't know whether that's a good or bad thing) in Main. And how would a TRS thread be associated with a page that doesn't exist yet? You could simply plop the thread address into a box, but that could prove to be prone to abuse. It seems like it would be better to either lump that category in with mod approval, bring back some sort of page-move mechanism, or, you know, fix the problems of YKTTW. Then I'm not sure the new page creation mechanism will be enough to make autolocking unnecessary. It's a little complicated, but not that complicated. Do you mean the YMMV/Trivia/etc. subpages? If so, it's worth noting that a lot of those apply to multiple page types (even if they're only intended for one, they might not be worth the effort to cull the ones for the "wrong" type), and again, in most cases there should be no reason why the same subpages shouldn't apply to e.g. all media that a work page would go in. Gotta agree with Fighteer here; if anything linking subpage types to page types might be more robust.

Also agree with Fighteer on Arcades' URL suggestion; to me, when you have different works in the same medium with the same name, the way you have them laid out here, conceptually the year of release almost fits better with the medium, which is being used to disambiguate, than on the subpage level. And I think numbered subpages would only be used (if at all) if a single page got too big for its britches, e.g., when a list of examples needed to be split.

Again, replying in bullet points:

• Disambigs and indexes are not usually created in Main/ out of nowhere. And we haven't decided yet on how the page type is going to be controlled under this system, but my personal preference is to keep only the index button (and possibly the disambig one) and to make all other page types controllable by the namespace/subpage choice - and thus by the Namespace List. With respect to the thread tool, a) we'll probably add a note "Just so we are clear: We check these threads", b) the thread will be plugged into the edit reason, and c) fix the page history so that it displays.
• We'll need some more statistics on the nature of unwanted page restorations to decide on this.
• We haven't agreed on a design for the Namespace & Subpage List. Mine was just a draft idea, but probably not the best one.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

I'm with Morgan regarding page type: they should be the most basic descision and the one that determines whether you need special permission or YKTTW or TRS or whatnot. Namespace and subpage options should be dependent on page type choice.

Oppression anywhere is a threat to democracy everywhere.

The main issue I have with page type is that I am not clear on how to integrate the thing into the system. I guess that trope, administrivia and index would go into the "thread^note With the things I proposed above with respect to prevent abuse, YKTTW or [panel/mod]" approval, and free creation for everything else.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

Ok, having thought all the night about these things, I have found some ways to work on this:

• About the queue: Regardless on whether a new Main/ or Administrivia/ page without YKTTW or a thread requires mod or panel approval, the queue should be publicly viewable and also publicly discussed if soemone wants to fix a bad draft or whatnot. Also, secret discussions (I am talking about the mod forum, by the way) just invite the "black box" issue back in.
• About page type: Frankly, the main issue I see here is that page types and namespaces and subpages are not within a clear classification scheme with each other.

My idea was to split the Namespace List into four lists for each tab in @86 (one for approval requiring pages, one for indexes, one for work pages and the last for everything else) and the subpage tab into 3 schemes (work subpages, trope/index subpage and common subpages)

The page type tool will have to stay as-is^note For changing already existing pages., even though we could use a way to set the page type with the tool. That said, we probably don't need a way to create disambigs out of nowhere - these are almost always useful only when created from redirects or existing pages.

• About the cut pages approach: Basically, there are 4 ways to go about it, sorted here from least strict to most strict:

1. Remove the autolocker and enforce the Permanent Red Link Club solely by page locking, i.e the page type input form .
2. As #1, but show on the screen for the input form that the page was cut in the past, the cut reason and a warning "Just so we are clear: We don't want the page restored with the same problems that got it cut." This is particularly effective when paired with a note on trope and work page input forms "Remember that we'll need at least three well-written examples to keep a page." In this case, the PRLC will be enforced by the page needing to be unlocked before it can be created if it's locked.
3. Similar as #2, but here when you try to restore a page that was cut, it will need moderator approval.
4. Keep the autolocker system and request an unlock to create a page (i.e like the current system)

Personally, I prefer #2. With #1, it would be essentially like the current way to create pages but without the autolocker, while #4 would be like the current system and is not very user friendly.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

One, that's going to make it even easier to spam-recreate cut pages. Two, that's going to defeat a lot of the point of this - you might as well just keep the page creation system the way it is now, and just have page type be auto-set by what namespace you created it in. Three, that's going to overwhelm the user with a long list of namespaces most of which aren't going to mean anything to them. Not sure what you mean by "integrate the thing into the system", but controlling page creation ability by page type seems like it maximizes simplicity and minimizes collateral damage. I don't think it's necessary to overthink the Official Namespace List. There's a select group of namespaces we'll need to make specific decisions on, but for the most part the list will grow naturally out of deciding what to do with each namespace. Copy over most of the "mediums", "page-type specific", "subpage types", and possibly "languages" and "Italian namespaces" folders, and that's probably 90% of the list right there, most of them with associated page types already determined. Maybe we could determine whether each namespace is a valid place to put an index or not, but I don't know how many non-Main pages actually have the "index" type as opposed to "does indexing". Again, I think you're overthinking this. Technically, I have to imagine there are a gazillion ways to associate a namespace with a page type or types. You could have a list consisting of a namespace, an associated page type, and yes/no settings for whether certain other page types can be created there. Or, in a variant of your idea, you could take each page type that can have multiple options and give each one their own list of approved namespaces. Really, the main technical requirements are a) checking to make sure a page has a valid type for that namespace, and b) populating the list of namespaces that appears in a drop-down menu when you create a new page for each page type.

• Trope: Can be created in Main only. Requires approval.
• Work: Can be created in any approved medium namespace.
• Creator: Can be created in Creator only.
• Index: Can be created in any namespace approved for indexes.
• Useful Note: Can be created in Useful Notes only.
• Just For Fun: Can be created in Just For Fun or any namespace on a list of JFF namespaces (or just marked as being a JFF namespace).
• Contributor: Can be created in Tropers only.
• Administrivia: Can be created in Administrivia only. Requires approval.

It's probably also best to have a single list of subpage types and assign legal types they can be subpages of to each one. Obviously, figuring out what to do with the translation projects could foul up all these schemes. Now it is, but what if, say, you have multiple unrelated works with the same name in different mediums? If we're trying to discourage creating redirects to work pages, we're probably going to be creating at least some disambigs from scratch when someone creates Literature.Foo when we already have Film.Foo.

Regarding cut pages, if it turns out that a substantial number of re-creators of cut pages could be classified as vandals or otherwise not caring about the reasons we cut a page, I think #3 may have to be the bare minimum.

edited 16th Dec '12 4:11:25 AM by MorganWick

Ok, replying in bullet points again:

• I have moved on from that idea to the one in @119, after spending all the night from 15th to 16th Dec figuring out how to make this work. To wit, it would organize them across some "page sorts" that I will explain in a moment.
• I already figured that there are various ways to organize that thing. I didn't find a best way in the aforementioned night, though.
• Ignoring the question of which tabs we ought to use in @86 (for instance, there is a case to make that it should be "Tropes & Indexes", "Subpages", "Administrivia", "Works" and "Special"), the ideas of yours look more complex and with more redundancy than what I was thinking of, to be honest.
• Not sure how to deal with that. Is there a need for disambigs there?

I think the biggest thing to keep in mind here is that "page types" are technically not so much a literal page type and more like checkboxes that enable certain functions by page. Thus, we migth not want to use them as a selection for actual "page types".

In this sense, it might be best to sort input forms in the pagecreation tool not by the old page typing system, but with a new "page sorting" system. That way, we could create a selection for "page sorts" in the createpage function, then the input form in @86.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

I was thinking of what would be necessary technically and in terms of reference. When actually creating a page, I would first have either a selection of buttons, radio buttons, or a drop-down list of page types, and if you selected Work, Index, Just for Fun, or Subpage (or possibly Disambiguation or Redirect), there would be another drop-down list of valid namespaces for that page type. Behind the scenes, it's possible those lists would be populated by filtering a single master list. It would not be necessary for someone to see the entire Official Namespace List when creating a page. Is there a practical difference, though? Especially since I have to imagine literal page types would be more user friendly. We could merge Creator and Useful Note, and we could merge Tropes and Administrivia, and we could merge Index with either one, but someone is likely to scratch their head as to why these very different sorts of pages are lumped together. Or were you suggesting a change in nomenclature and no more?

About #1 of @122, would it help if the input form of @86 had a tab for each page type, and the Namespace (or Subpage, for Subpages and Examples) List were to be split by the tab its listed items supply the dropdown of?

With respect to the cut pages thing, we'll need some solid statistics for the decision.

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman

Let's work a bit with base definitions, so we all have terms we agree on.

Namespace: We have one of these for each thing that could have a name collision with something else. Primarily, one for each medium of work (Film, Literature, etc.). We can think of the administrivia items as being a medium. (Wiki articles about this wiki's culture.)

Section: This often appears as a tab. It is a particular sub-topic of the Article it attached to. (YMMV, Characters, etc.)

Tab: A graphical way a section or namespace is presented to the reader.

Folder: A graphical way a section is presented to the reader. It always contains a section or sub-section.

We should control the number of namespaces so that their purpose is clear. Keeping the movies separated from comics and so forth. We could easily think of a namespace as a medium.

We have things now that are referred to as namespaces which shouldn't be. Characters, for example, are rightly a section of the work's article. Just For Fun is another case. It is essentially just a label that can be applied to anything at all. A tongue-in-cheek trope, even. Or a movie or tv show or a Useful Note. Creators are essentially a type of Useful Note.

I think we need to instill the use of the word Section to talk about most of the things that appear now on tabs and folder labels, unless those labels are media, which most of them are.

This simplifies a page creation tool. The editor has to decide if the page they are making is about a work or not. If it is, they need to pick the work's medium. Then tell us if the article is Just For Fun. That's it. Then they can make the article.

If the page they are making is not about a work, they need to decide between Trope, Useful Note and Section. The only one of those that has sub-types we care about is Section. It is different enough that we can make it a separate action. In other words, you can "Create Page" or you "Create Section."

Tropes, Useful Notes, Tropers, Disambigs, and Works can be created through "create page." Stuff like YMMV, Characters, Moments, etc. must be made from 'create section" while on the page it will be a section of. Obviously, only Tropes can have Medium sections. There may be some sections we don't want to have for tropes, as well. "Moments" about a trope, for example, makes no sense.

So, we have a limited list of sections. What do we do for people who want to make a folder to organize a long section of an article and label it whatever they want to label it? I think giving them a place to name the section would work fine. The section name they come up with would not be added to the list of approved section names, unless enough people want to use it. Call this one a "Custom" Section, or something.

Lastly, they can pick the display type for the Section. Tab, or folder. Or we can say that certain sections are always on a tab.

"K. Enough thinking out loud for now.

Goal: Clear, Concise and Witty

So "Section" is basically the same thing as "Subpage" and "Folder" are now. We'll need a way to deal with YMMV items and all that there.

Also, a YMMV "Section" would be about a work. It would probably better fit under the "Work" side of the pagecreation function rather than "Not a work".

About Creators/, I've seen it used kind of like a super-work page as well as an useful note. Are you saying to change this?

Final question: Are "Create Section" and "Create Page" different functions here?

"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." - Richard Feynman