On the use of Hats and Bombs

As I mentioned above, my main problem with bombs is how universal they can be. They are used to signal a problem, but without a reason given, nobody (except the bomber) would know what that specific problem is. We desperately need bombing reasons.

Yet, like mentioned before, if you are going to require a bombing reason, you also need a hatting reason. At the moment you can mindlessly hat or bomb a prompt without any thought or participation and no-one would know the reason why the trope should exist or not. A healthy system would be one where you are forced to explain why you think so either way.

Does a hat mean launch the trope? Does it mean great prompt, launch it with additional work? Does a bomb mean bad prompt delete it? Does it mean prompt might be good, but not in this form?

Point is, we need more communication on all fronts, because at the moment even the people voting can't even agree what the thing they're voting on even means. Personally I'd tie hatting/bombing to the comments so that you're forced to participate in the discussion. It might lead to spam, but at least it makes it obvious who did it and at what point.

Another thing to note is that there's been several cases of people using sock accounts just to hat their underdeveloped drafts, so worst case scenario, we need hatting reasons to tell us when people are trying to abuse the system. I'm sure sockpuppet bombers are a concern as well.

Edited by WarJay77 on Dec 11th 2019 at 3:17:07 PM

Here is the main reason why Bombs are a bigger problem:

Bombs are meant to communicate a problem, but without giving a reason, no one would know what said problem is. I think if Hats were signed with our usernames, we could detect socks much more easily. But if Hats are strictly launch signals, then why would we need Hat reasons? Hats only mean one thing, and if each person gave the same reason, would it feel redundant?

My solution is to have Bombs require reasons, and for Hats to require signatures.

Edited by EarthboundFan on Dec 11th 2019 at 2:37:41 AM

Hats are only supposed to mean one thing, but people don't always use them correctly. This means bad drafts can be granted 5 hats with very little work- meaning they can also be launched, because they were given invalid hats.

With hat reasons, we can figure out which hats were given for the correct reason, and which ones can be disregarded.

Seriously, you guys seem to think that people aren't dumb enough to give invalid hats and then launch drafts with invalid hats. But they are.

And that's why I personally think hatting reasons are even more important than bombing reasons.

Invalid bombs can be disheartening. Invalid hats can get bad drafts to launch.

Do you think seeing the reasons for invalid hats will change the "dumb enough to launch with invalid hats" problem?

It'll let us subtract those hats from the equation.

Do you think the people who are choosing to launch clearly-incomplete drafts will do that?

No, but the drafts could be put on hold to prevent premature launches once it's been proven that the hats were given for invalid reasons, or sent back immediately for the same reason.

Besides, using that logic, bombing reasons would be just as useless- would the people who want to bomb decent drafts really be deterred by us telling them their bombing motivation was poo? It wouldn't stop drafts from being bombed to oblivion or prematurely discarded... but it would let us disregard those bombs and subtract them from the count.

Point is, these reasons are necessary in both cases to help us better prevent and catch problems before they become problems. It won't always work, but we need something to help us. Something we can point to to say "these hats shouldn't be here, these bombs are outdated, etc".

If I may, I do think new coding is crucial to improve the TLP, but I've also found the usefulness of the TLP guidelines lacking. And I take it those don't require specialized knowledge to be improved?

"The best way to determine if a TLP is ready to be launched is to see if the draft has a net 5 hats- five more tropers think it's ready to launch (added a hat) than think it should be discarded (added a bomb)."

This one's the most relevant, so I shall use it as an example. Firstly, it would be handy for this to mention that the software won't stop you from launching as long as you have five hats at all and that the responsibility of good faith is on the proposer to make sure it's five hats net. Secondly, "the best way to" suggests that five hats net is, in fact, not a requirement, but (as per the page name) a guideline. Thirdly, this is the only bit defining what hats and bombs are about, which is too little and as per this thread not how many people perceive and use them. Hats and bombs should have their own paragraph explaining them. And fourthly, that paragraph should be part of (or be referred to in) a TLDR at the top of the page. Obviously people should read the whole thing, but having the important parts emphasized and easy to find would be useful.

And even without code to enforce it, a paragraph about hats and bombs can mention it's proper etiquette to leave a comment explaining why you handed them out.

Guidelines aside, there's another matter that's been mentioned a few times in this thread that is a pretty big reason I don't bother proposing most tropes I think are missing. And that's that proposed tropes exist in a weird state of "expected to be rough" and "should be perfect at all times". For instance, the 3Ro3 page states that "you don't have to come up with [examples] yourself". When I proposed the eerie anatomy model trope, there were a few pieces of fiction I knew to be relevant, but hadn't read and very much didn't want to read. So I added the names of the works but without context and left a comment that I'd appreciate for someone who knows the work to contextualize the entry. This felt to me like doing a little more than "you don't have to come up with [examples] yourself". Then another user added ZCE warnings and it was (would've been; another note by them was encouraging) kinda discouraging because, yeah, I know about ZCEs, I said so much, and I wasn't planning on launching with the ZCEs still there. Mayhaps I should've done better than leaving those entries empty, but there's no guidelines on how to handle this. I suspect some of the early bombs may be due to the ZCEs, which doesn't seem fair to me because if I'd done less I wouldn't have had them. And just so, some tropes I can come up with I'm not doing because on one hand I don't want to invest too much in something that might get shot down (wiki trauma; long story) while on the other hand not doing enough before proposing might bring in bombs that then have to be compensated later on.

Coding like not being allowed to leave hats & bombs for the first three days and making the launch waiting time longer could definitely help. But guidelines on how to tackle imperfections in a proposed trope you can't readily tackle yourself are just as necessary.

Thanks for reading.

Edited by Pfff133 on Dec 22nd 2019 at 4:29:20 AM

Hey, if you feel the current page is lacking, we're actually rewriting it over at Outdated Pages. Join us!

Sorry if this is too bump-y, but I'd like to join too! Where is Outdated Pages?

On this very subfora. Link here.

I wonder if a third voting option would help with the problems. Something like "good concept, keep on TLP for improvments". Those who vote for it would need to write what problems they see and the timestamp for when the vote was cast would be visible.

Splitting the votes into "good idea/bad idea" and "ready/not ready" would accomplish that.

So mysteriously today, all four of my recently bumped drafts have gained a random, no-reason-given bomb. I think someone may be trollin' me.

This seems to happen a lot to some drafts.

I dont know if this the right place but should we move the bare minimum of 3 examples as a hat requirement to at least 10-15? It doesnt make much sense as anything launched with very little examples and crosswicks will get sent to Pages Needing Wicks and the Tropes Needing Examples list and most end up languishing there.

Although now we have a good eye in catching them so they can sent back but still

Three examples minimum is fine for works but not really for tropes.

Yeah, that sounds much more reasonable honestly, especially since we now updated the rules to be "crosswick as much as possible", not "just get it to 15 wicks".

10 to 15 seems rather high, I think it's enough to prove you have a solid idea (not necessarily the best page) with less. The Starvation level on Wick is 0-5 wicks if it's newly made. So make 5 examples the minimum standard for a hat instead (but I will still probably keep making drafts with only 3 examples as that would be fine for a start)? I know those indexes exist, but people should probably take the new standards on Wick into consideration before putting pages on there, especially since Pages Needing Wicks actually says "If one has at enough for Standing (counting this page), please remove it."

Edited by Piterpicher on Mar 2nd 2020 at 11:22:23 AM

I mean, speaking personally, I don't consider launching a trope until I have at least 10 examples, and my hatting standards are that high for everyone else's draft, as well. I think a lot of people now think that the more examples = more launchworthy, especially since hats are launch signals and not support signals.

If they were support signals, 5 examples would make sense as the minimum to prove that the trope exists as a pattern, but I wouldn't call it enough to launch and have a sustainable trope that'll thrive after launching.

Hm Pages Needing Wicks used to specifically say 16 but not anymore. Anyways,

I personally dont think a trope with only five examples shows a pattern. 10 is more solid to me. If you launch with only 5 examples, there isn't much chance it will grow beyond that unless you are really good at coming up with ways to link back to the trope.

Right, that's the issue.

This is actually the issue that made me make the New Trope Problem thread, as new tropes don't thrive too well and part of it is because they aren't wicked enough. If we need more examples on the draft before a draft is considered launchworthy, that'll just make the trope more likely to thrive when it's launched (assuming the launcher crosswicks properly).

Besides, has any good new trope actually launched recently with only 5 examples on it?

Admittedly, I couldn't really find any recently-launched tropes that have less than 10 examples (besides Eye Roll, but that one's a matter best talked about somewhere else). Most tropes launched by me (especially recent ones), like Export Save or Colorblind Mode, have had at least 10 examples since launch. The modern standards are certainly higher than what you'd expect. In any case, I guess I'm fine with that as I'm typically able to get 10+ examples for my tropes, but I'm against changing the Starvation range as that would mean the 4+ year maximum for the tier would go above 23 which is probably a fair barrier for older tropes to be safe (like Fourth Wall Shut-In Story which is from 2011 and sits firmly at 25).

Edited by Piterpicher on Mar 2nd 2020 at 11:48:42 AM

We're not really talking about changing the starvation wick-range though, just the amount of examples that a new trope should have to be considered launchworthy. They're two different things I feel, as a trope with 100 examples would still be starving for wicks if the sponsor never crosswicked it.

I know that, I guess I just started talking about it because Pages Needing Wicks was mentioned and I felt like my Starvation range would show a minimum of examples a trope needed as well (after all, indexes typically only add a few, potholes on subpages and stuff are probably a non-factor until the page actually grows a lot). So the amount of examples is fairly similar to the amount of wicks, assuming that crosswicking has been done.

Edited by Piterpicher on Mar 2nd 2020 at 12:03:01 PM