TLP Community Issues

Also, there's the whole "Aim for a final draft appearance" thing. I'm not going to jump on someone for misspelling an uncommon word or making a solitary typo, but when someone's whole post needs to be rewritten for grammar, the sponsor doesn't need that extra work.

I don't really like the idea of "the sponsor shouldn't have to do extra work" cuz it feels like taking responsibility off the sponsor to check grammar and formatting and such, even when it's not very obviously bad examples. If someone sends my draft an example with formatting or grammar issues, I just tweak it accordingly. If I can't fix it, I just don't add it and instead ask for further clarification.

If anything, the problem is when sponsors don't check for mistakes until someone points them out, and we can all see the mistakes until they're fixed but we aren't sure if we can edit their draft.

Edited by mightymewtron on May 27th 2021 at 8:38:23 AM

Well, yeah. Sponsors should absolutely make sure everything looks good and is correct. I fix issues like that all the time.

But, I do believe it works both ways. While sponsors should be willing to do extra work if necessary, people who suggest examples should put in the effort to make sure things look good as well. The sponsors need to enact quality control, but that doesn't mean people who are giving examples should just be allowed to post garbage and force the sponsor to clean the mess. It's also indicative of their wiki work- if they can't be bothered to use proper indentation on the TLP, there's a big chance they're also doing it in their normal edits.

Basically, since it's a community, everyone in the community needs to be making sure things are good quality, and this to me includes making sure the examples we suggest are written properly.

I've definitely seen people leave comments like "X from this work is an example" or "This happens in this work". The people leaving the examples shouldn't just assume the sponsor is familiar with the work and knows what they're talking about.

Sometimes I leave comments like that, not as finalized entries, but more as a prime for those in the comments who can better provide context when I can't remember it.

I think there's a difference between things like:

"I think this one show has an example, but I don't remember the details, does anyone else?"

And

"Does show X count?"

That's why I blame the sponsors for adding "X from this work is an example" to the draft instead of asking for more details.

I ask for details all the time; so do a lot of people.

Which affirms my point that ZCE on the draft are ultimately the sponsor's responsibility most of all, as they could always either ignore the comments or do the research to flesh them out themself.

Well, yeah.

Still though, I do think we should try and crack down on repeat offenders. Sponsors need to step up their game too, but everyone should put effort in, and those who repeatedly break the rules should be confronted.

The admins think that putting together a TLP history of posts will be relatively easy, so they've put it (relatively) high on their list of priorities. No comments on timeframe, but it has been put on the active list.

Oh, sweet!

Oh nice!

I've asked the admins to look into putting some additional waiting periods into the TLP process. My hope is that these will address one of the primary sources of bad launches: clueless people randomly pressing buttons.

• The first is a mandatory 24-hour wait between pressing Launch and being able to confirm the launch. During this period, the draft would be prominently highlighted as "pending launch" and launch could be canceled. (I'm not sure if we should let anyone do that or only the launcher/a moderator.)
• The second is a mandatory 24-hour hold on launching if a trope is unlaunched or un-discarded.

Obviously, moderators should be able to override these restrictions. Thoughts?

Edited by Fighteer on Jun 2nd 2021 at 9:11:58 AM

I think that's fine.

I like the idea of not having to manually wait.

... Does that mean auto net hat check is happening too? If so, what happens on sudden bomb? Launch cancelled?

Edited by Malady on Jun 2nd 2021 at 6:14:27 AM

Also the TLP draft should be able to officially switch hosts when adopted so the new host has the same rights as the original creator. Bullet 1 would improve greatly if this were implemented.

Edited by ccorb on Jun 2nd 2021 at 9:14:57 AM

I really like those ideas, though I'm not very involved in the TLP so take what I say with a grain of salt.

Edited by themayorofsimpleton on Jun 2nd 2021 at 9:16:54 AM

Auto net hat check is already on the list of TLP requests so I didn't mention it above. I don't know how the case should be handled of a trope getting a rush of bombs during the launch wait. It feels too easy to abuse, but with hat/bomb logging it should be easier to figure out if people are systematically doing that.

I'm still leery of making TLP draft ownership grant formal privileges in code. It's supposed to be a collaborative process; the concept of an owner is more to keep things from devolving into chaos than to give one user veto power over the whole thing. I know that ~Septimus Heap has been doing most of the legwork of gathering opinion so I don't want to step on his toes.

an old proposal of mine

• Create a "Countdown" button.
• Hats/bombs can't be added to a draft until the "Countdown" begins.
• The "Launch" option remains greyed out until there are 5 more hats than bombs and 72 hours have passed since the "Countdown" was activated.

I had a more recent proposal that incorporated a few more elements, but just creating a "cooldown/countdown" timer and deactivating the voting system until that is used would be most of what I asked for. It would massively decrease "I like this idea" hats if you can only add them during the "evaluate" stage.

See, what I was thinking is that anyone can press a "takeoff in 24 hours" button and once it's set the launch button appears within 24 hours. And the draft is marked as "countdown running" or something like that after that point.

I concur with not enforcing sponsorship in code, though. Whether someone is stealing other people's TLPs or they are legit is not a distinction a machine can make, unless we apply some heuristics.

One other crazy idea is to ask whether the software can perform some basic quality checking before launch. Say count the number of bullets (at least 24?) and the number of words that aren't part of a link (4?) per bullet to block drafts with obviously too low example numbers or obvious ZCE.

I don't think forcing 24 bullets is good. the wick minimum for launch is 12 right now and likely for the next few years. Maybe ask for 3 bullets with links minimum when starting a draft to ensure it has an adequate start.

12 is also possible, but I definitively do not agree with any technical restrictions on creating a TLP draft. The point of TLP is not that something is launch ready as soon as it's posted.

A waiting period before hats/bombs can be added at all sounds like it might be desirable. Nobody should be hatting a trope draft when it is first written, no matter what the circumstances are. Conversely, we should have a way to screen zero-effort or spam drafts, but that may be better done by flagging them for moderator review than by allowing bombs.

So the process might look something like this:

1. After initial posting of a TLP draft, there is a 72-hour waiting period before hats and bombs may be added.
2. Once an article achieves five net hats and the initial wait has expired, the "Launch Countdown" button becomes available. Pressing it asks for confirmation and sets a 24-hour timer.
3. If during this period the net hat count drops below five or the user who started the countdown presses "Abort", the launch is canceled and may not be restarted for 24 hours.
4. Once the countdown expires and the draft still meets the requirements, it may be launched.
5. If a draft is discarded and then restored, or launched and then unlaunched, a 24-hour wait is placed on further launches or discards.

As previously stated, moderators (and engineers when that position is created) can override these features.

I'm leery of applying heuristics within the article text. For one thing, it doesn't account for variations, like indexes, creator pages, useful notes, and work articles, being drafted through TLP. For another, it might become too easy to game.

Edited by Fighteer on Jun 2nd 2021 at 10:43:54 AM