Difference between revisions of "User talk:Popecrunch"

From Space Station 13 Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
useful feedback only disclaimer
pope's suggestions for writing policy:
 
* Consider a bored person who doesn't give a shit when writingLike, you're absolutely going to end up with a big chunk of text, but it's worth sticking a summary at the beginning.  I'm trying to get anything I'm working on to a state where the sections are "TL;DR", "Definitions", "Overview", "Specific use cases or exceptions or other weird shit", and "Conclusion" before presenting it as a thing to vote on.
"This is not a hangout or chat threadIf you have feedback about the rules, please provide it, so long as it is constructive and meaningful. 'i don't think you covered x' 'do we really need to codify y?' 'i'm pretty sure that's not how we handle z' are all fine. 'please use the british spelling for colour' 'only one space after a period, please' 'NSFW is a better acronym to use than NWS' are all nitpicky detailsI understand this is a difficult distinction to make, so I'm not going to punish people unless they're harping about a meaningless detail that has already been asked and answered. I am not your kindergarten teacher, it is not my job to give you a pat on the head and tell you that every sound that falls out of your face is special and wonderful. If you want to post just to post, do it elsewhere."
* i like to write early versions as outlines simply because it lets me dismantle the idea into its components and then look at each component and think of the weird interactions and edge cases they might run into. this is probably not great for finished versions, but it's a tool i use for the early stages
 
* don't try to think of every possible use case or interaction. you'll drive yourself mad. start with broad strokes, modify those with a couple detail passes, and when you find yourself thinking 'well what about this scenario, which is so unlikely it'll happen maybe once or twice a decade, what do we do THEN' force yourself to drop it.  this is policy, not computer programming, humans are significantly less likely to fall over and fart out magic smoke when they're fed stimulus they're not specifically programmed to handle. it's ok to have some slop.
tossed it here for tinkering
 
||admin page||

Latest revision as of 22:08, 8 March 2020

pope's suggestions for writing policy:

  • Consider a bored person who doesn't give a shit when writing. Like, you're absolutely going to end up with a big chunk of text, but it's worth sticking a summary at the beginning. I'm trying to get anything I'm working on to a state where the sections are "TL;DR", "Definitions", "Overview", "Specific use cases or exceptions or other weird shit", and "Conclusion" before presenting it as a thing to vote on.
  • i like to write early versions as outlines simply because it lets me dismantle the idea into its components and then look at each component and think of the weird interactions and edge cases they might run into. this is probably not great for finished versions, but it's a tool i use for the early stages
  • don't try to think of every possible use case or interaction. you'll drive yourself mad. start with broad strokes, modify those with a couple detail passes, and when you find yourself thinking 'well what about this scenario, which is so unlikely it'll happen maybe once or twice a decade, what do we do THEN' force yourself to drop it. this is policy, not computer programming, humans are significantly less likely to fall over and fart out magic smoke when they're fed stimulus they're not specifically programmed to handle. it's ok to have some slop.