2021-12-05

• [[maya]]
• [[meme generator]]
• [[devine lu linvega]]
• [[gyuri lajos]]
• [[elena]]
  • [[viejos tiempos]]
  • [[postre ravana]]
• [[push]] [[do]]
  • widen wikipedia iframe
    • wanted to also add a 'go' button for when you navigate away from the original iframe url -- tried it but unfortunately cross site policy doesn't let us read the iframe url it seems :()
  • fix mastodon bot, why is it not updating the [[following]] list?
  • start on [[agora rss]] == [[agora feeds]]
  • plan week

2021-12-05

• Reading: [[dulongderosnay2020: Digital commons]]
  • Really great paper on [[digital commons]].

incredible night last night

toki pona

https://en.wikipedia.org/wiki/Toki_Pona pull Small, concise language intended for ease of acquisition!! Focuses on simple, near-universal concepts - expressing a lot with very little and optimizing for simplicity and positivity! - follows Linguistic relativity - Wikipedia : `sapir-whorf hypothesis` - that a language changes the way its speakers think and behave. used in therapy to help people eliminate negative thinking by tracking their thoughts in `toki pona` instead! wonderful

"worlds in which different societies live are distinct worlds… no two languagesare ever sufficiently similar to be considered as representing the same social reality"

Google Code Review Advice

• https://chromium.googlesource.com/chromium/src/+/HEAD/docs/cr_respect.md
  • Assume competence - maybe someone just possesses information that the other isn't aware of!
  • Motivate why the right way is what it is - explain why code is wrong!
  • Find an end - it's okay to approve something that looks good overall, even if there are a few nitpicks! Instead of dragging on a conversation and criticising code line by line, much more important to handle all of the high level ideas and ensure some decent level of code quality then move on
  • Okay to agree to disagree - even if a decision isn't quite a subjective preference
• https://chromium.googlesource.com/chromium/src/+/HEAD/docs/cl_respect.md: respectfulcode changes
  • reach out to prospective reviewers before writing any code - make sure everyone's on the same page and get some help speccing it out together!
  • choose the reviewers. make sure they understand what's going on beforehand! get help early to make sure your fix is warranted or safe.
  • state expectations you'd like for your code to meet - what's important about this code? what should they be interested in?
  • address all comments - don't ignore any feedback, as it diminishes the time of the reviewers! at worst, move a structural issue to a later date or delay until a critical issue is fixed (depending on how important the change to make is)