Outdated Administrivia Pages

Made a few minor edits, in particular taking the laconic title explanation out in the open and adding an explanation about hats and bombs in the intro. I hope they are agreed with.

As I said in the other thread, I'd like a system (abbreviations?) to indicate points of concern within a working page. Like, examples you want checked or filled in at all or feedback on listed related tropes. Is that possible here?

Hmm, the Hats and Bombs line seems too vague to me. It's pretty much agreed that hats for "support" aren't being properly used, and that they should only be a sign that the draft is ready to launch. Bombs are a little more versatile and can be anything from "discard immediately" to "this needs work before it can launch".

I'd personally change it to something like:

• Proposed pages are judged by a system of (green) hats and (red) bombs. Hats are in support of the page being launched and bombs represent a negative judgement, such as that the draft isn't ready to launch, or should be discarded.

For your second point, I'm not completely sure what you mean. Can you write it out as you're envisioning it and post it here?

How about this for mentioning net hats more than the current one?

• While the website code will let you launch any trope with over five hats, other users won't, as you need five more hats than bombs. These are called 'net hats' and are required for any launch. Remember that anyone can check the Launch List, and you need unanimous consensus to get a draft launched without objections.

Works for me. Where do we add it?

I say under "!! Launching".

Unless there are objections (or someone beats me to it), I'll move the text from Sandbox.This Is A Wiki and replace the redirect later tonight.

Though This Is a Wiki should be linked to somewhere on Repair, Don't Respond (I don't know if it'd need a text revision as well).

Edited by Piterpicher on Dec 24th 2019 at 12:29:01 PM

This is probably the best place for this... From Administrivia.How To Write An Example:

Avoid Spoilers: Remember our Spoiler Policy. It is always better to have a somewhat vague example that anyone can read than a precise and specific example covered with pieces of spoiler text. An entry with Spoiler Text like this one can confuse and annoy even fans of the work in question, not to mention anyone else. Always try to write your examples in such a way as to avoid plot-sensitive information like someone dying or switching sides, if you can help it. And for the love of God, don't add in spoileriffic content unless it's relevant to the topic at hand. If you don't need to talk about sensitive information to make your point, then don't. Again, don't assume everyone else knows about everything you know. If an example needs to be entirely spoiler-tagged (including the work/trope name) to avoid spoiling the work, reconsider adding it; it won't do any good as an example for anyone who doesn't want to be spoiled for that work.

The last sentence creates a bit of an issue with Handling Spoilers. Is everyone fine with a change to:

If an example on a trope page needs to be entirely spoiler-tagged to avoid spoiling the work, reconsider adding it; it won't do any good as an example for anyone who doesn't want to be spoiled for that work. Also, do not place the work name under spoiler tags, as a reader would have to expose themselves to the spoiler simply to see what work it's for.

That works.

I'm fine with the intro bit about hats and bombs being changed. My reason for adding it solely is so that there's some sort of "getting started" regarding hats and bombs so that elaborations later down the page don't come out of nowhere. So as long as it's there and hits on the essence of hats & bombs, it's good.

In regards to the whole bit about leaving notes, in the case I'm specifically thinking of is that I had some ZCEs in a trope I was proposing because I knew the works were relevant, but I didn't know in which way (or where in the work it showed up). So, I put them in as examples and left a comment saying I'd appreciate for someone else to fill out those entries. What I didn't say was that I wasn't planning to launch with those ZCEs there and that in case no one else would fill them out, I'd either delete them entirely or read those works myself later down the line. But then someone else added ZCE notifications in the text and left a comment saying ZCEs aren't okay.

So I've been wondering if there's some way a sponsor can communicate doubts or needs within the page itself, because comments aren't the best way. Maybe something like "Zero-Context Example - Help Needed" or (for context provided, but based on possibly faulty memory) "Context Feedback Needed" or "Not Sure If Example". That kind of stuff that communicated that the sponsor knows what they're doing, but just can't deliver on their own.

Sorry for the late reply, but yeah, I get you.

Something like this?

• If you're sponsoring a draft and need help with something that would otherwise make the draft unlaunchable, you should let people know you need the help. Some ways of doing this are to make a note in the title, laconic, or top of the draft itself, posting about it in the comments, or even making a post on the TLP workstation thread. Otherwise, a miscommunication may lead people to believe you aren't aware of or don't intend to fix the issues on the draft, so remember to speak up if your draft needs help you can't personally provide for it.

That works, but I think there should be some advice on how to leave these notes in the text. In brackets? Something in all caps? Like "[NOTE!: Will this definition do?]"

I mean... most people on the TLP just put it in parenthesis or something. There's no "official" way to leave notes like these and there doesn't need to be, as long as people can see the notes are there.

In an effort to enforce better crosswicking standards, should we fix this paragraph?

• When you've written up the trope, in order to make sure a trope gets plenty of wicks and is noticed, it helps to go to the example pages and add it there (there's nothing wrong with copy-pasting the example text), a process known as Crosswicking. A good rule of thumb is that a healthy trope page should have at least 12 wicks; if you absolutely can't get it there, you should probably list it on Pages Needing Wicks. If there are tropes related to the one you launched, add "See also" sections to both tropes. The more pages linked up, the better the Wiki Magic flows.

Not only did we change the "healthy" count, it also encourages sponsors/launchers to half-ass the crosswicking stage, getting the page up to about ~15 wicks before stopping, even if the page should have way more- and even if the only way to ensure Wiki Magic is to have as much opportunity for the trope to be noticed as possible.

Yeah, change it to say something to the effect of "every example listed on the trope page should also be listed on the corresponding work page, if we have one".

I understand there's no official way to do things and don't mean to say there should be on. But as a newbie, I look at all the ways the guide is insufficient to tell you what to do. And without at least a suggestion how to note a potential issue, I know I would invest way too much energy and time into figuring out the best way to go about it. (Or am I the only one who finds proposing tropes unpleasantly nerve-wrecking and emotionally draining?)

Ultimately, we can just add "A possible way to make notes within the proposed page is to add "[EDIT:{your issue)]" where applicable. Don't forget to mention these notes in the comment section to ensure they're noticed." to the text you wrote and it should be good.

I do agree the instruction for crosswicking should be better. It's very easy to "forget" about crosswicking because at that point you've already gotten past the hurdle of hats and bombs. For that matter, I suggest that any post-launch instructions be a separate section to emphasize their importance.

Yeah, alright, I get you.

• If you're sponsoring a draft and need help with something that would otherwise make the draft unlaunchable, you should let people know you need the help. Some ways of doing this are to make a note in the title, laconic, or top of the draft itself, ^note these can be formatted in parenthesis or brackets labeled as notes, if you want to ensure better visibility posting about it in the comments, or even making a post on the TLP workstation thread. Otherwise, a miscommunication may lead people to believe you aren't aware of or don't intend to fix the issues on the draft, so remember to speak up if your draft needs help you can't personally provide for it.

I put it in a note-markup because otherwise IDK where else to tack it on; feel free to rewrite if you have a better way.

And yeah, it should be a separate section.

Rewritten crosswicking bit:

• When you've written up the trope, in order to make sure a trope gets plenty of wicks and is noticed, it helps to go to the example pages and add it there (there's nothing wrong with copy-pasting the example text), a process known as Crosswicking. Every example listed on the trope page should also be listed on the corresponding work page, if we have one. If there are tropes related to the one you launched, add "See also" sections to both tropes. The more pages linked up, the better the Wiki Magic flows.

Edited by WarJay77 on Jan 5th 2020 at 3:21:59 PM

Updated the sandbox. Thoughts?

Looks good to me! I've made a tiny adjustment to the after launch section to make it a bit more checklisty for ease of use, even if it feels redundant.

The only thing I can think of right now that could still be added is something about how long the TLP process can last. To give absolute newbies a handle on what they're signing up for (again, something I personally have gotten very confused about). Maybe something like this?:

• A TLP takes time. Some launch only two weeks after they're proposed, while others linger for months. There are many factors that influence the length of the TLP process and you should never rush it (not in the least because there's also several post-launch matters to take care of).

Yes, good idea.

Wick's info isn't outdated, and this isn't a locked Administrivia page, but I was thinking about adding an explanation of Ghost Wicks. It'd be a major edit to the page. The term has been around for many years now, but there's no wiki page where info and what-do is housed, and therefore, occasional questions about invalid wicks pop up in ATT and elsewhere (I'm guilty of it). Also, there have been changes in policy over the years, not recorded, AFAIK.

My troper page has some lines. They might actually be misleading because the info is scattered. What do you think? OK? Or too in-the-weeds/esoteric?

I think that'd be a good addition.

Should be "recreated and cut (deleted)", since that's the order these steps would go in.

Edited by Twiddler on Jan 8th 2020 at 4:42:41 AM

The sandbox has been updated again. Are we ready to swap it in? I say we are.