> For the complete documentation index, see [llms.txt](https://mmems.gitbook.io/calepin/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mmems.gitbook.io/calepin/project/project.md).

# Project

Aka conception

### Quotes

> A successful software tool is one that was used to do something undreamed of by its author. — Stephen C. Johnson

> Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love. — [Pete Cordell](https://twitter.com/petecordell/status/428542622844477441)

> Tout est faisable, c'est juste une question coût et/ou de temps

* [Starting an Internet Service Provider | Chris Hacken](http://chrishacken.com/starting-an-internet-service-provider/) - Create your own ISP

> Même si on est intelligent, et dieu sait qu'on croit l'être quand on est jeune, on est pas à l'abris de rater sa vie — Unknown

### Specification

See [Specification](/calepin/documentation/documentation.md#specification)

### Some possible issues

* s’imaginer que sa cible parle le même langage que soi / a la même culture que soi
* poser des questions qui ne recueillent que des réponses attendues
* poser des questions qui ne recueillent que des réponses fermées
* être trop centré sur la fonctionnalité technique en oubliant la situation d’usage
* trop extrapoler vis-à-vis de données statistiques
* [Culture differences](#culture-differences)

![Coca Cola Fail](https://github.com/mems/calepin/blob/main/Project/Coca-Cola_fail.gif) ![Castorama Fail](https://github.com/mems/calepin/blob/main/Project/castorama_fail.jpg) [Motorola et la pub](https://web.archive.org/web/20101223200221/http://blogs.nofrag.com:80/NoLog/2008/oct/27/41184-motorola-et-la-pub/)

### Constraints

Quality trilemma, constraints: scope, cost and time

![Good Cheap Fast](https://github.com/mems/calepin/blob/main/Project/good%20cheap%20fast.mp4) ![GoodCheapFast](https://github.com/mems/calepin/blob/main/Project/GoodCheapFast.jpg)

* [Project management triangle - Wikipedia](https://en.wikipedia.org/wiki/Project_management_triangle)

### Brand blunder

* Métro Express Régional Défense-Etoile (MERDE : translated to SHIT) → Réseau Express Régional (RER)
  * [Réseau expres régional — Wikipédia](https://fr.wikipedia.org/wiki/R%C3%A9seau_express_r%C3%A9gional#Anecdote)
* Renault Koleos
  * [κολεός — Wiktionnaire](https://fr.wiktionary.org/wiki/%CE%BA%CE%BF%CE%BB%CE%B5%CF%8C%CF%82)
* Mitsubishi Pajero (ex: masturbator, wanker)
  * [Mitsubishi Pajero - Wikipedia](https://en.wikipedia.org/wiki/Mitsubishi_Pajero)
  * [Mitsubishi Montero - Wikipedia, la enciclopedia libre](https://es.wikipedia.org/wiki/Mitsubishi_Montero)
* Diapers Pedo (es: "I fart"; [Pedobear - Wikipedia](https://en.wikipedia.org/wiki/Pedobear))
* Ford Pinto (pt: "male genitals")
* Nokia Lumia (es: "prostitute")
* Hyundai Creta
* GM Nova (es: ("No va") "doesn’t go")
* Mazda Laputa
* Peugeot (Biao Zi: ("婊子") "prostitute")
* [GEC Plessey Telecommunication - Wikipedia](https://en.wikipedia.org/wiki/GEC_Plessey_Telecommunications) / GPT (fr: ("J’ai pété") or "I’ve farted")

![TGV Snail](https://github.com/mems/calepin/blob/main/Project/tgv_snail.jpg) [TGV - Wikipedia](https://en.wikipedia.org/wiki/TGV) [le nouveau logo du CNRS - Etienne Mineur archives](http://www.my-os.net/blog/index.php?2008/11/17/1161-le-logo-du-cnrs)

* [Brand blunder - Wikipedia](https://en.wikipedia.org/wiki/Brand_blunder)

### Lifetime

> Plus longtemps vous travaillez sur un produit, moins vous avez envie d’entendre ce que les gens en pensent. — Astro Teller, SXSW 2015

Lorsqu’on travaille sur un projet, il faut le faire tester le plus tôt possible, condition sine qua non du succès

* [Google Glass : le patron du laboratoire secret de Google reconnaît des erreurs](http://www.lemonde.fr/pixels/article/2015/03/18/google-glass-le-patron-du-laboratoire-secret-de-google-reconnait-des-erreurs_4595780_4408996.html)

### Retrospective

* pas avant la fin de la crise
* orienté compréhension et solutions
* pointer le quoi plutôt que le qui
* évaluer les décisions en fonction des informations et risques du moment, pas en fonction de ce qui s'est révélé par la suite et qu'on sait après coup

### Counterproductive rules

See [Productiveness](/calepin/work/work.md#productiveness)

> Et si la rémunération à la performance nuisait à la performance ?
>
> « Comment faire pire en croyant faire mieux. » \[...] « Un club de football met à l’amende un de ses joueurs au motif qu’il rend trop souvent la balle à l’adversaire. Résultat : il ne la passe plus à personne. Un patron décide d’organiser la compétition permanente entre ses salariés. Résultat : une partie d’entre eux commence à saboter le travail de leurs collègues. » \[...] Une crèche israélienne souhaitant réduire le retard des parents, met en place une sanction financière. « Que se passe-t-il ? Après l’introduction de l’amende, le nombre de parents arrivant en retard a… augmenté, et ce de manière régulière ».

* ["Les stratégies absurdes" Maya Beauvallet. |](http://www.verbiage.fr/les-strategies-absurdes-maya-beauvallet/)

### Copyright infringement

See [Prevent violation](https://github.com/mems/calepin/blob/main/Project/Security/README.md#prevent-violation) and [Reverse engineering and cracking](https://github.com/mems/calepin/blob/main/Project/Security/README.md#reverse-engineering-and-cracking), [DMCA](https://github.com/mems/calepin/blob/main/Project/Law/README.md#dmca)

Launch world-wide from beginning, Crawl the web

* [Gamasutra: Mary Min's Blog - How to Fight China’s Mobile Game Pirates & Avoid Clash Royale’s Fate](http://www.gamasutra.com/blogs/MaryMin/20160520/273132/How_to_Fight_Chinas_Mobile_Game_Pirates__Avoid_Clash_Royales_Fate.php)
* [Selling your software in China | Successful Software](https://successfulsoftware.net/2010/08/12/selling-your-software-in-china/)
* [Why you should create a ‘honeypot’ page | Successful Software](https://successfulsoftware.net/2017/03/10/honeypot-page/) - Create an honeypot page for people how search a licence key or a cracked / warez version
* [How to remove software cracks and keygens from file hosting sites | Successful Software](https://successfulsoftware.net/2011/01/25/how-to-remove-software-cracks-and-keygens-from-file-hosting-sites/)
* [Copyfraud — Wikipedia](https://en.wikipedia.org/wiki/Copyfraud)
* [Copyright infringement — Wikipedia](https://en.wikipedia.org/wiki/Copyright_infringement)
* [Warez — Wikipedia](https://en.wikipedia.org/wiki/Warez)

### User generated content problems

Need moderation *a posteriory* or *a priori* because machine can't actually detect [pun](https://en.wikipedia.org/wiki/Pun) or [slang](https://en.wikipedia.org/wiki/Slang) (ex: leetspeak or SMS language), violence, inappropriate expression/image

Could be use in campaign:

![Coca-Cola with text "DIARRHEA" from campaign GIFtheFeeling.com](https://github.com/mems/calepin/blob/main/Project/Coca-Cola_fail.gif)

* [Andrew Bloch on Twitter: "Coca-Cola GIF maker provides a valuable lesson to brands on why you should never let the Internet customise anything https://t.co/YpIz0JheFS" :](https://twitter.com/AndrewBloch/status/693028968744800256/photo/1)
* [Coca-Cola demande des GIF pour sa promo, et arrive ce qui devait arriver | Big Browser](http://bigbrowser.blog.lemonde.fr/2016/01/29/coca-cola-demande-des-gif-pour-sa-promo-et-arrive-ce-qui-devait-arriver/#xtor=RSS-3208)
* [Things You Can’t Talk About in a Coca-Cola Ad - The Atlantic](http://www.theatlantic.com/technology/archive/2016/01/things-you-cant-talk-about-in-a-coca-cola-ad/431628/)

> Funny story - we were asked to make dong detection software for LEGO Universe too. We found it to be utterly impossible at any scale. Players would hide the dongs where the filtering couldn't see, or make them only visible from one angle / make multi-part penis sculptures. The moderation costs of LEGO Universe were a big issue in general. They wanted a creative building MMO with a promise of zero penises seen. They actually had a huge moderation team that got a bunch of screenshots of every model, every property. Entirely whitelist-based building. YOU could build whatever you wanted, but strangers could never see your builds until we'd had the team do a penis sweep on it. It was all automated, but the human moderators were IIRC the single biggest cost center for LEGO Universe's operational costs. Or close to. And "that" is why Trove/etc were able to make better building MMOs. They didn't have to worry about little kids seeing dongs. We REALLY did. We even had an employee very nearly fired for building a penis. It was on his own property, but a kid wandered into it during a kid test. We're talking "test operator rushed forward, blocks the monitor, slams the game closed, four alarm fire to find who built the penis" here. After which a memo went out indicating our new absolute zero tolerance policy on building penises of any kind, anywhere, in the game. This is all obvious, simple stuff, and is why dealing w/ COPPA (which protects kids) is so damn hard in online games. Even DEVS build dongs. This is a roundabout way of saying "never build an online game for kids / I have no idea how Minecraft hasn't been sued over this yet" People saying "well just allow dicks" - LEGO's brand is utterly trusted by parents. We had to uphold that trust. Which meant zero tolerance. I'm.... relatively positive I can talk about this stuff. The agreements signed when the studio shut down had more to do with defamatio, etc. Anyways, "all of that" is why every single successor to LEGO Universe has been small and missing build play. LEGO knows how expensive it is. And they basically can't compete with Minecraft, because Minecraft can just shrug that entire problem off. So they've focused elsewhere. I expect stories of the sunk costs gone into LEGO Universe are told to young LEGO execs at bed time, as cautionary tales to never try again.
>
> — [Megan Fox on Twitter: "Funny story - we were asked to make dong detection software for LEGO Universe too. We found it to be utterly impossible at any scale." / Twitter](https://twitter.com/glassbottommeg/status/604407061380640768)

Or in search engine autocomplete:

![Castorma autocomplete with suggestions of previous user in the search engine](https://github.com/mems/calepin/blob/main/Project/castorama_fail.jpg)

* [Le moteur de recherche de Castorama piraté](http://www.20minutes.fr/insolite/1861771-20160608-moteur-recherche-castorama-pirate)
* [Le site de Castorama indisponible à la suite du détournement de son moteur de recherche](http://www.lemonde.fr/pixels/article/2016/06/08/le-site-de-castorama-indisponible-a-la-suite-du-detournement-de-son-moteur-de-recherche_4943352_4408996.html)
* [Incivility — Wikipedia](https://en.wikipedia.org/wiki/Incivility)
* [Obscenity — Wikipedia](https://en.wikipedia.org/wiki/Obscenity)
* [Modesty — Wikipedia](https://en.wikipedia.org/wiki/Modesty)
* [Commons:Country specific consent requirements — Wikimedia Commons](https://commons.wikimedia.org/wiki/Commons:Country_specific_consent_requirements)
* [Consent — Wikipedia](https://en.wikipedia.org/wiki/Consent)
* [Copyright — Wikipedia](https://en.wikipedia.org/wiki/Copyright)
* [Sin — Wikipedia](https://en.wikipedia.org/wiki/Sin)

### Putting people first

* [Inclusive Design Principles](https://inclusivedesignprinciples.info/)

### Kiss Principle

Aka Keep It Simple, Stupid

* [KISS principle - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/KISS_principle)
* [The Kiss Principle](https://web.archive.org/web/20220409022251/https://people.apache.org/~fhanik/kiss.html)
* [Simplicity Isn’t Simple - FINCH](http://archived.getfinch.com/2012/04/simplicity-isnt-simple/)
* [Do one thing and do it well](/calepin/development/development/development.md#do-one-thing-and-do-it-well)

### Design

See [Design](https://github.com/mems/calepin/blob/main/Project/Design/README.md)

* [A Simple Web Developer's Guide To Color – Smashing Magazine](https://www.smashingmagazine.com/2016/04/web-developer-guide-color/)

### Open source

* don't create a new project instead of contributing to an already existing one -- how many framework/lib for doing X do we have out there?
* don't go private and don't be scared to share unfinished work, read [Programmer Insecurity @ iBanjo](http://blog.red-bean.com/sussman/?p=96)
* don't use your own custom/funky open source license, avoid license proliferation go read [Open Source Licenses by Category | Open Source Initiative](https://opensource.org/licenses/category)
* don't release your open source project only on your blog or forum, for dev sake pick one of the forge [Comparison of source code hosting facilities — Wikipedia](https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities)
* don't release a compiled version with no sources - if you call your project open source go read what it is [The Open Source Definition | Open Source Initiative](https://opensource.org/docs/osd)

> If you ask, "any update on this?" on an open source issue, the answer is always, "no." Updates are on the issue.
>
> — [Nicholas C. Zakas sur Twitter : "Here's a time saver: If you ask, "any update on this?" on an open source issue, the answer is always, "no." Updates are on the issue." / Twitter](https://mobile.twitter.com/slicknet/status/782274190451671040)

> Folks who manage/lead open source projects: Do you have any advice or lessons learned for someone who has no idea what she's doing?
>
> — [Suzana Ilić](https://twitter.com/suzatweet/status/1143425542122856448)

> Patience. Enable contributors. Listen to your community. Prepare for cultural differences and blunt language. Be patient. Thank your contributors. Release often. Prioritize docs. Let things take time. You compete for contributors' time with everyone else.
>
> — [Daniel Stenberg](https://twitter.com/bagder/status/1143773910124703744)

> Also. Prioritize backwards compatibility. Make upgrades painless for users . Diligence with releases pay off long term. Keep a list of security issues/fixes. Keep your defaults secure. Options are a plague on testing. Options to disable stupid default is worse.
>
> — [Spider](https://twitter.com/spidler/status/1144214905291182080)

> I'll try and hit some ones others haven't:
>
> * Have a code of conduct and enforce it
> * Document everything. From how to use it to how to develop it, to how decisions get made
> * Automate everything you can. Toil is demotivating.
> * Set healthy boundaries. Stick to them.
> * Make your contributor experience buttery smooth.
> * Giving attention to your community helps it grow, so be as attentive as you can (but realise this is a trap, so see point about healthy boundaries).
> * Enjoy it when inevitably someone does something awesome w/ your project
>
> — [Mark Mandel](https://twitter.com/Neurotic/status/1143657776943472641)

> Create a clear governance model early on. It'll save you endless frustration down the road if the project is successful. One good example can be found here: [browser-compat-data/GOVERNANCE.md](https://github.com/mdn/browser-compat-data/blob/master/GOVERNANCE.md)
>
> — [Morten @ home](https://twitter.com/mor10/status/1143725473609818112)

> any advice on how to make a living with open-sourcing?
>
> — [418 — I'm a teapot](https://twitter.com/mazunki1/status/1143792135524749312)

> Sell services that go along with the software, like installation, implementation in an organization, support.
>
> — [Anca Mosoiu](https://twitter.com/anca/status/1144033462879260672)

> That's harder than "just" succeeding with your project The less hard way to do that is to get a job at a company already doing a lot of open source. To make living on your own project you need to find a business case for it. Not easy.
>
> — [Daniel Stenberg](https://twitter.com/bagder/status/1143793181433180162)

> 1. every few years your audience changes. new users don’t appreciate problems of the past bc never seen them. old users burn out or lose excitement. new users have different reference frame, learned in diff ways, you might be their first programming env. plan accordingly.
> 2. when you fix a problem you better really really understand the problem you’re fixing. take a few steps back and reintegrate new knowledge into the design. should it change the design? it’s like fighting a hydra: solving a problem in the wrong spot spawns 10 new problems.
> 3. most PRs create more work than solve. even when the project’s internals are well-documented (which for us was brief), significant contributions are rare. this is not so much because of difficulties writing code but due to months worth of context needed to make decisions.
> 4. for libraries, make sure your PR descriptions are great (they become squashed commit messages). for apps, include product videos before/after and urls you were testing in PR descriptor. someone (me) will thank you eight years later when diagnosing a bug or planning a change.
> 5. a couple of trolls, even well-intentioned, can poison an entire discussion space.
> 6. write tests against public API instead of unit tests for internal implementation modules. then you can fearlessly rewrite the implementation using tests for verification and guidance. you can even keep both implementation versions at the same time and run tests against both.
> 7. long-running branches suck. merge into main and keep it behind a feature flag. invest time into a good feature flag mechanism that cuts out dead code and/or lets you deploy feature flag changes for % of uses in prod experiments.
> 8. if a change shows up red in metrics, maybe you made it slower. but maybe you introduced a bug which broke some interaction for %. or maybe you changed how metric is logged. or maybe you fixed a bug and metric was overreported before. metrics are hard.
> 9. many people want to score a PR in a popular project so that it appears on their gh. somebody will convert if-else to early return. next day somebody else will send a PR to convert it back. it doesn’t hurt to merge until you miss a mistake in the middle of a “stylistic” change.
> 10. if you fix something, add a test that fails. if you don’t add one, you’re tacitly agreeing that someone else (including you) will break it again.
> 11. your writing in project blog/docs will be copy pasted verbatim, rephrased, adapted, and then posted on content farms, other people’s personal blogs and slides. in a way that’s actually kind of cool because this means your writing worked
> 12. some projects have wide surface area and decisions can be decentralized. other projects have narrow surface area and decisions need to be centralized. both styles are ok, just don’t get confused why techniques that work for one type of project may be disastrous for another
> 13. keeping github clean is nice but for each individual person on the team there’s almost always something higher-value to do. that’s ok and you don’t need to feel bad about it. it’s much more important that your software works well. if it becomes dire you’ll know
> 14. nevertheless it’s invaluable to do occasional github issue sweep and read/triage every thread. you’ll get a window into the pain points and confusion that is hard to build up otherwise. that alone is worth the time and effort
> 15. with some PRs it feels like the person really knows what they’re doing. reach out to them. they might be your future teammate
> 16. if you don’t explain the story about what you’re doing and why, someone else will do it for you (and you might not like it)
> 17. be careful with what other projects you recommend and endorse, they might be the very thing that holds the entire ecosystem back in a few years
> 18. if there is harsh feedback, it is better to hear it from a kind person. unfortunately a kind person will often keep it to themselves, while a troll would shout about it. making it tempting to dismiss. validate harsh feedback with kind people and keep the door open for it
> 19. don’t DM with a troll. it’s a waste of time. don’t get dragged into twitter feuds. not enough space for nuance. redirect discussion to a technical long-form space. keep DMs for friends and people you trust
> 20. don’t throw inside DEV-only code. this makes some branches reachable in production but unreachable in DEV. so you might actually have *worse* problems than crashing in prod, like a privacy compromise, and none of the developers experienced it on their machines due to throw
> 21. when you write a tutorial, sit down with someone from your target audience and have them walk through it. they’ll stumble in five different places than you expected. you’ll tear your hair out and make the tutorial 5x better
> 22. some for the nicest, kindest and most amazing people you’ll meet and hang out with will be the people working on the competing projects
> 23. when you deprecate an api, don’t put a tombstone in your slides. this is tempting and might be funny to you as an author but categorically a wrong move
> 24. big rewrites can work if you know what you’re doing. make sure you know what you’re doing though
> 25. lock down introspection APIs and keep first-class tooling that uses them colocated. this ensures you’re not locked out of major internal changes by a long tail of tooling that assumes something about internal data structures and has become unmaintained or is incompatible
> 26. a crunch with a few weeks of overworking can be emotionally fulfilling when the team is in the flow state. a perfect work/life balance while team morale is low and dynamics are thorny can feel like a piece of your soul is flushed down the sink every day
> 27. innovation is not linear. sometimes you need to make it worse to make it better.
> 28. expanding on that, when you replace a system, you usually need to go incrementally. otherwise it’s too much risk for stakeholders to go all-in. but that means you won’t reap the benefits of *replacing* it until the end. you’re *adding* so likely regressing. set expectations.
> 29. let users try a new thing one piece at a time. even if you want them to use it everywhere, let that be *their* idea
> 30. if you can’t prove out a migration strategy with a small team on a big codebase, you don’t have a migration strategy. start again
> 31. the most important principle in API design is that it composes well. that means that if two people create two things, they need to still work well together combined. it also means you can delete one of them later without breaking the other. or copy and paste it to isolate it.
> 32. you will see the most bizarre feature requests. don’t dismiss them outright but ask why they’re trying to do this. a lot of use cases are actually legit and food for thought. eventually you run out of new ones — you’ve covered the entire problem space. consider solutions
> 33. if something doesn’t make sense, no amount of documentation or explanations will make it make sense.
> 34. people will copy and paste every code snippet you write. even the ones marked with “don’t copy paste, this is the bad example, the good one is below”
> 35. your personal social media account shouldn’t be a primary source of truth for news in a mature project. people will get FOMO plus it’s legitimately hard to track. you can repost but keep news in official sources (like GH)
> 36. even if someone is a great developer or a good friend, it still doesn’t mean they’ll necessarily succeed on your team. this can be gut-wrenching for all parties when it doesn’t work out.
> 37. if you accept and merge every individually reasonable clarification that someone sends as a PR to your docs, they will become a sorry unreadable mess
> 38. people *love* to hit the Accept button on someone’s PR even if they never contributed to the project and never left a single comment on it. it’s just a thing people do
> 39. occasionally, it’s good to take the minified code, run it though Prettier, and quickly read through it. you might spot things that shouldn’t be there, things that could be minified better, or get ideas on how to reduce the size
> 40. if you’re trying to introduce a new workflow (eg different task tracking tool) to the team, it’s on you to get people to feel good about it and try it out (“i know you prefer keeping tasks in a doc, let me sync that doc for you for a bit and we’ll see how it goes”)
> 41. taking ownership over something unowned (but that everybody cares about) is one of the most valuable things you can do on a team. try not to drop it though (i’m guilty of that)
> 42. when the code serves a particular purpose that’s too high-level to be seen from the code, write it down as a comment. long-ass ten line comments are good if they add context to the code (rather than describe what it’s doing)
> 43. re-running a test you’re actively iterating on after a file change shouldn’t take more than a second
> 44. write a script to do releases for you. get the CI to create automatic prereleases from main so you can always test the latest main in codesandbox (and other libs can run tests against nightlies). a stable release should patch+promote a CI version, not build locally
> 45. your teammates can literally move mountains
> 46. when you work on your messaging, run it by people. use it many times in narrower circles and widen slowly. close the gaps using feedback so that by the time you have final messaging, it’s the parts that resonate, are easy to understand, are easy to quote, and (!) make sense
> 47. if your technical vision is sound in theory, and you chip away at the practical obstacles with perseverance, organisational support, pragmatic compromises, and optimism, eventually the theory wins
> 48. if you have one scary bug after another, write regression tests but also use this as a signal. something in the model might be broken. complex code isn’t bad, but code built around a flawed model is very bad, complex or not
> 49. all people are irreplaceable. every iteration of a team is a new team in some sense. in some ways this is poignant, in others this is exciting
> 50. naming is one of the most important decisions you will be doing. it’s not just bikeshedding. give it appropriate time and effort. you will mess it up anyway though.
> 51. you keep hearing complaints about an API. the fix is simple, like flipping a switch. fine!! you change it. suddenly, the other half, previously quiet, comes frustrated. oops. turns out both options were equally disliked. congrats, you’ve just churned your users for no reason
> 52. semver is “just” a social contract. yes it’s important to communicate intent. breaking changes shouldn’t go into minors/patches. but even fixing a bug is a breaking change for someone relying on the buggy behavior. semver is first and foremost a human communication tool
> 53. you are not your project. it also seems unwise to pretend that it isn’t in some way a significant part of your life. not “work hustle 4 da boss” capitalism thing but more like “regardless of power structures i’ve put a lot into this and i have reasons to care”. that’s valid
> 54. most things don’t stick around long enough. you’ll now read most of the “announcing X, a new way to Y” with a 2-3 year flash-forward “X is legacy” in mind. be gentle or people will read this as being cynical. also some things *will* stick around, either in a good or a bad way
> 55. edge cases are your bread and butter. they’re more common than you think (with enough usage anything happens) and they are a first-class part of your design. you should have satisfactory (if not satisfying) answers to how the system behaves even (especially) when it’s wonky
> 56. it’s better when issues reproduce consistently. but if some bug caused by API misuse in product code is non-deterministic and happens less often than random typical existing bugs in the product code, it’s below the threshold of rethinking the design
> 57. thought experiments are your main tool as an API designer. “imagine a tabbed view…” “imagine a combobox…” “suppose we have a feed and a profile…” is how many breakthroughs begin. you start with a situation, think through ideal behavior — from user and system point of view
> 58. that clever optimization? probably unnecessary and will cost you a few weeks of bug hunting. oh, and good luck ripping it out
> 59. introduce some slight inefficiency in a hot path, and clicking every button becomes 10% slower. do that several more times and you’re 100% slower
> 60. constraints and edge cases drive your design. constraints exclude 99% of possible designs. edge cases accentuate the remaining choices and help you pick which one sucks the least (or least surprisingly). then if the common case makes sense you’re golden
> 61. if you’re not sure between recommending two approaches, wait it out. it might be because you don’t know all the constraints yet. it’s like solving nonogram puzzles. as you solve problems, they fill out the constraints for other problems. at some point only few options work
> 62. it’s unwise to put all effort into optimizing a fixed cost of library code if the cost of user code is unbounded. ignore benchmarks that focus on how fast the 5% of a realistic app runs, and focus on making 95% you don’t own faster. this doesn’t justify being sloppy though
> 63. if you go on a panel with a competing library maintainer and talk about an upcoming feature in your release a few months away, there’s a high chance they will ship a similar feature next week. that’s only fair
> 64. you will build for people who are excited to use your project. everyone’s jazzed. then you’ll notice a flood of people who hate it. this is because the people who were excited to use it are now forcing other people to use it (oh no) also now there’s a job market, congrats
> 65. your goal isn’t to make every app use your library. it’s to make other libraries copy the ideas you value the most. then your work won’t be lost because it’s upstreamed to the global programming consciousness. the failure case is good ideas dying with your code
> 66. look out for inspiration outside of your direct competitors. your direct competitors are looking at you too so at some point there’s a deadlock for fresh ideas
> 67. innovation looks like synthesis of existing ideas with a novel twist. it doesn’t happen often and it’s easy to miss if you’re not paying attention
> 68. people like to optimize something that they know how to optimize and where there’s obvious progress. there will never be a shortage of people excited about replacing a 5 KB library with a 2 KB library
> 69. designing is not so much creating as it is uncovering what already should be there. like math or archeology. it’s exploiting the properties of the system and making them shine
> 70. “how it scales” matters for technology adoption by small shops too. this is because if it doesn’t scale to big shops, there’ll be a competitor that scales *and also* works well enough for small shops. the solution that’s good enough for most people will wipe out yours
> 71. invoking “simple vs easy” as an argument in an API discussion works great if you have the design sensibilities of rich hickey. otherwise it’s just a sparkling HN comment
> 72. people have opinions on everything. even if you’re unable to handle the volume or respond individually, it helps to provide a void to shout into so that people feel heard, the discussion is consolidate, and doesn’t spill out into random platforms. then you can revisit it
> 73. much of Programming Discourse is shaped by people who aren’t shipping production code and have lost touch with the reality. get used to it and carry on. oh by the way… you are one of those people now
> 74. people arguing about applying abstract code patterns on Twitter means you’re failing. the wise API designer would empty their users’ minds, fill their bellies, weaken their wishes, strengthen their bones…
> 75. “no” is the correct answer to most feature requests. no matter who they’re coming from. try your best to help people though and bring the pain points back to the table. this is developer advocacy
> 76. “try harder” sounds too harsh as a motto and can be misused. i’d say, “peek around the corner”. it’s okay to stop when you’re stuck. but make sure you didn’t just give up on the last few steps to the solution because you ran out of hope
> 77. there are few forms of communication more powerful than a tech talk. it’s like carving out a meme out of stone. use this medium thoughtfully.
> 78. experimental/research work and content should be branded separately from the stuff people need to know and can use today.
> 79. eager vs lazy: both suck. eager sucks because you do more blocking work upfront that may not be used. lazy sucks because you start work too late. “eager non-blocking” is best. start optional work asap but you can drop it midway or downprioritize it if it’s not needed anymore
> 80. it’s often more valuable to have someone who “gets it” in partner teams than having that person on your own team
> 81. don’t compromise on core principles and properties of the system for the sake of convenience. convenience helps narrowly, but core principles will keep on giving for years in ways you didn’t expect. it’s nice when you can have both though
> 82. “i don’t know” and “i don’t understand this part” and “can you say this again” are phrases you should expect to say (and hear) in productive meetings
> 83. you need to create space for design discussions that isn’t crammed into a regular sync meetings. most enlightening discussions i’ve seen are free-flowing, didn’t have a predetermined agenda, went into rabbit holes, and needed a few hours to get to a conclusion. write it down!
> 84. failing is ok but you want some lesson carried away from it. so that the next person who tries has a chance to mitigate the same issue proactively. failing comes with a cost: it’s harder to justify doing same project again. better to wait out than to try at a wrong time.
> 85. the best features are vertically integrated. that means that they don’t just work at a particular level of the stack but pierce through the whole stack and give you some leverage at every level, low and high. they’re also integrated together: they all compose as you’d expect.
> 86. don’t cut a stable release or deploy the website on Friday unless you’re doing this intentionally. for example if there’s a big codemod and you need to land it while nobody else is pushing conflicts
> 87. global configuration like React.setOptions() is a bad idea. this is because components on npm written assuming one set of options wouldn’t wotk with the other set of options. so global configuration breaks composition.
> 88. people can handle bad news but people hate surprises
> 89. the way each person thinks makes a lasting contribution to the team. “what would X do” is not only a useful question that X can answer but also a way to nudge our own thinking for years going forward
> 90. an autocomplete has one chance to reorder per keystroke. if you got it wrong and you have a better ordering a bit later you must “swallow the sadness” (as per the original author of this wisdom) but never change already dispalyed items
> 91. if you have two similar APIs and you’re worried people will overuse A instead of B (which is actually better), give A a clunky name and make B nice and short
> 92. if you plan to change the paradigm, do it in a minor release
> 93. sometimes your thing sucks but you don’t know the solution and don’t have anything that helps move it forward. you have to learn to get comfortable with something badly sucking for years. just make sure a workaround exists
> 94. re-read every release post imagining that you’re drunk and your attention span is zero. if the message still lands you’re good
> 95. carrying messaging directly from a small team to the community doesn’t scale if the messaging is complex and nuanced. instead it is helpful to have a buffer of trusted folks who can learn the ins and outs, become experts, and participate in those panels
> 96. the best task management system for a release is long-ass quip doc (or gh issue) with a freeform checklist. we call these “umbrellas”
> 97. never assume you know others’ emotional states. if you don’t ask, you might not hear some critical information until it’s too late
> 98. it’s all about the people. if relationships are frail and people don’t trust each other, projects fail. technical wiring directly reflects which teams trust each other. poor communication produces broken systems. screw the org chart and go talk to the ICs directly
> 99. newer people on the team won’t know the norms if you don’t tell them. if reviews are slow in general they might think they specifically are being ghosted. be explicit about everything and always follow-up on how they feel and what’s concernin
>
> — [Dan on Twitter: "a hundred things i learned working on the react team @threadapalooza" / Twitter](https://twitter.com/dan_abramov/status/1470613731071696896)

See also:

* [License - Development](https://github.com/mems/calepin/blob/main/Development/Development.md#License)
* [A handy guide to financial support for open source](https://github.com/nayafia/lemonade-stand/blob/master/README.md)
* [Philippe Elsass on Twitter: "Popular JS projects have to manage huge communities, and the suspicion of strategic manoeuvres in a very competitive ecosystem https://t.co/uwGCB3RmXR"](https://twitter.com/elsassph/status/879424075252289536) - quoting Sebastian McKenzie (author of babeljs): "Hard to stay motivated when people are yelling at you to justify every little thing you do and take your actions as attacks."
* [Open Source Guides | Learn how to launch and grow your project.](https://opensource.guide/)
* [TODO guides // TODO: Talk openly, develop openly](https://todogroup.org/guides/)
* [The cost of an open source contribution](https://web.archive.org/web/20221225021157/https://rgommers.github.io/2019/06/the-cost-of-an-open-source-contribution/)
* [Lessons learned from 15 years of SumatraPDF, an open source Windows app](https://web.archive.org/web/20230311180722/https://blog.kowalczyk.info/article/2f72237a4230410a888acbfce3dc0864/lessons-learned-from-15-years-of-sumatrapdf-an-open-source-windows-app.html)
* [So, what's next? - core-js](https://web.archive.org/web/20230312094747/https://github.com/zloirock/core-js/blob/3a6698ece5d42b461104cce61e5aa5fffbc677b4/docs/2023-02-14-so-whats-next.md)

### Native App vs Progressive Web App

* [Web Case Studies | Google Developers](https://developers.google.com/web/showcase/)

### MVP - Minimum Valuable Product

!\[Progressive enhancement - Building Minimum Viable Product by Spotify]\(Progressive enhancement - Building Minimum Viable Product by Spotify.png)

* [Lean Product Management (lessons learned) | The Minimum Valuable Product](http://www.sebastiensacard.fr/articles/2015/the-minimum-valuable-product/)

### 80/20 rule

See also [The X-Y Problem](#the-x-y-problem)

> Don’t set your goals to high, try to make something small so you’ll finish it in time and you’ll stay motivated to make your next project.

* [Pareto principle — Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
* [Never prioritize your roadmap based on customer feedback – Feature Request Management in SaaS – Medium](https://medium.com/feature-request-management-in-saas/never-prioritize-your-roadmap-based-on-customer-feedback-30a8a5021f97#)
* [Rarely say yes to feature requests - Inside Intercom](https://blog.intercom.com/rarely-say-yes-to-feature-requests/)
* [Strategy Letter IV: Bloatware and the 80/20 Myth - Joel on Software](http://www.joelonsoftware.com/articles/fog0000000020.html)

### The X-Y Problem

See also [80/20 rule](#8020-rule)

> The X-Y Problem, as it is sometimes called, is a mental block which leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. It often goes something like this:
>
> 1. User wants to do X.
> 2. User doesn't know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
> 3. User doesn't know how to do Y either.
> 4. User asks for help with Y.
> 5. Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
> 6. After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X.
>
> — [XyProblem - Greg's Wiki](http://mywiki.wooledge.org/XyProblem)

### Solve problems, not exploiting it

AirBnB, Uber like

* [PITCH FRENCH TECH](http://www.frenchtech.co/a-propos)
* [J’ai rencontré #Ceuxquifont (de la merde) - Le site du journal Le Postillon](http://www.lepostillon.org/J-ai-rencontre-Ceuxquifont-de-la.html)

### Release

* 3-tier release strategy (nightly, prerelease, release) (like Firefox)
* semver
* [Rapid Release Model - MozillaWiki](https://wiki.mozilla.org/Rapid_Release_Model)
* [Moving Firefox to a faster 4-week release cycle - Future Releases](https://blog.mozilla.org/futurereleases/2019/09/17/moving-firefox-to-a-faster-4-week-release-cycle/)

### Never rely on third-party service

Base you product on an external service is risky. What happend if the provider (have to) discontinue it?

* [Google quietly ends support for Hangouts-based apps - SiliconANGLE](https://web.archive.org/web/20201112025222/https://siliconangle.com/2017/01/09/google-quietly-discontinues-support-hangouts-api/)

### Unsolicited reworks

Could also be a prototype

> Obviously, this is POC level only.
>
> Because any “real” solution needs to follow audit trails, pass security screening, not be reliant on something that could “just go away”, etc. ... No you did NOT replicate an $86 million dollar project, not even close. You replicated a single solitary feature of the project. ... No. What you developed is not the replica of an 86 million project… It’s the functional equivalent of the prototype for that project. And it’s OK.
>
> – [How I replicated an $86 million project in 57 lines of code](https://medium.freecodecamp.org/how-i-replicated-an-86-million-project-in-57-lines-of-code-277031330ee9)

> Easy! I can make a clone of Tweeter in one week". Maybe if you ignore all features and related services
>
> — [Je peux faire un clone de Twitter en un week end | Sam & Max](http://sametmax.com/je-peux-faire-un-clone-de-twitter-en-un-week-end/)

> Man, no matter how easy something seems, the "nearly complete" prototype is only ever like 1% of the time it takes to actually ship
>
> – [Jeremy Cowles](https://twitter.com/MoldyMagnet/status/905640968103247875)

> When Hacker News commenters say "I could build that app in a weekend!" I think of this chart of how Slack decides to send a notification.
>
> <img src="https://github.com/mems/calepin/blob/main/Project/Slack%20notification%20decision%20chart.jpg" alt="Slack Notification Decision Chart" data-size="original">
>
> — [Matt Haughey‏](https://twitter.com/mathowie/status/837735473745289218)

It's like unsolicited "redesign" website or app (without real constraints). See [Wikipedia:Unsolicited redesigns — Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Unsolicited_redesigns#Why_unsolicited_redesigns_can_be_problematic)

### A/B test

Aka A/B testing

* [Most winning a/b test results are illusory](http://www.qubit.com/sites/default/files/pdf/mostwinningabtestresultsareillusory_0.pdf)
* [A/B Test et UX design : l’utilisateur préfère cette version ? Non !   - Le blog des designers de la MAIF](https://design.maif.fr/blog/ab-test-et-ux-design-lutilisateur-prefere-cette-version-non.html)

### Quality and test

* QA (Quality Assurance) is a process to ensure adherence to the quality. Tests done by automated systems, testing teams running a test case periodically to test the various aspects of the product/software. Its generally technical people behind the test, find bugs report bugs.
* UAT (User acceptance Testing) is when the customer or the users who will be using this software test the product. Does it work for them. Does it provide them the easy of use, or the the expected output which they are looking for. Or the solution that they were looking on the first place.
* [Why We Killed Our End-to-End Test Suite - Building Nubank](https://web.archive.org/web/20210925045723/https://building.nubank.com.br/why-we-killed-our-end-to-end-test-suite/)
* [The Day My Script Killed 10,000 Phones in South America](https://web.archive.org/web/20211020142832/https://new.pythonforengineers.com/blog/the-day-i/)

### Web project

* [JavaScript Project checklist](http://bitovi.github.io/checklist/) - Project bootstrap: collect all project informations
* [How We Started Releasing Features Twice As Fast (Case Study) – Smashing Magazine](https://www.smashingmagazine.com/2016/07/how-we-started-releasing-features-twice-as-fast-a-case-study/)
* [Design and development standards to align and guide your project](https://github.com/north/north)

### Game

Aka gamification

Make a reward rather a penalty

> \[about player behaviors] encourage the behavior you want than discourage the behavior you dont. \[...] instead of punishing a player who is too slow, reward a player who finishes the level quickly

* [Extra Credits - YouTube](https://www.youtube.com/channel/UCCODtTcd5M1JavPCOr_Uydg) - Videos about games: how they are made, what they mean, and how we can make them better. For entertainment, education, etc. Rules, UX, business, etc.
* [Visual Guide: Multiplayer Level Design — Level Art+Design Portfolio](http://bobbyross.com/library/mpleveldesign)
* [How Game Designers Protect Players From Themselves | Game Maker's Toolkit - YouTube](https://www.youtube.com/watch?v=7L8vAGGitr8)

### Report issues

* [45 Github Issues Dos and Don'ts](https://davidwalsh.name/45-github-issues-dos-donts)

### Anticipante

* [10 ways to avoid CDN issues at peak](https://blog.peer5.com/avoid-cdn-issues-at-peak/)

### Glocalization

Aka globalization, g11n

* globalization: internationalization + localization
* internationalisation (i18n): the adaptation of products for potential use virtually everywhere (is done once per product). Ex: change texts in images to be locale based
* localisation (l10n): the addition of special features for use in a specific locale (is done once for each combination of product and locale). Ex: language, culture, technical limits, regulations (law)

Adapting to different languages, regional differences and technical requirements of a target market

* \[Internationalisation — 2200+ different ways to view a website.pdf]\(Internationalisation — 2200+ different ways to view a website.pdf)
* [Internationalization and localization — Wikipedia](https://en.wikipedia.org/wiki/Internationalization_and_localization)
* [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n)
* [Glocalization — Wikipedia](https://en.wikipedia.org/wiki/Glocalization)
* [Internationalization - Apple Developer](https://developer.apple.com/internationalization/)
* [About Internationalization and Localization](https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/Introduction/Introduction.html)
* [Top Ten Internet Languages - World Internet Statistics](http://www.internetworldstats.com/stats7.htm)
* [Techniques index](https://www.w3.org/International/technique-index) - W3C I18N resources relating to internationalization

#### Typeface

Aka font

* [Noto](https://en.wikipedia.org/wiki/Noto_fonts)
* [Arial Unicode MS](https://en.wikipedia.org/wiki/Arial_Unicode_MS)
* [Bitstream Cyberbit](https://en.wikipedia.org/wiki/Bitstream_Cyberbit)
* [Code2000 — Wikipedia](https://en.wikipedia.org/wiki/Code2000)
* [Doulos SIL — Wikipedia](https://en.wikipedia.org/wiki/Doulos_SIL)
* [Lucida Sans Unicode — Wikipedia](https://en.wikipedia.org/wiki/Lucida_Sans_Unicode)
* [GNU Unifont — Wikipedia](https://en.wikipedia.org/wiki/GNU_Unifont)
* [Unicode font — Wikipedia](https://en.wikipedia.org/wiki/Unicode_font)
* [Open-source Unicode typefaces — Wikipedia](https://en.wikipedia.org/wiki/Open-source_Unicode_typefaces)

#### Language and country selector

**Stop using country flag for a language selector: language ≠ country**

See [Stars and Stripes and ISO Codes · An A List Apart Column](http://alistapart.com/column/stars-and-stripes-and-iso-codes)

* [W3C I18n Checker](https://validator.w3.org/i18n-checker/)

#### Localization

> falsehood xxx believe about language: some people cannot speak or read the local (or the most commonly-used) language, like new international students, foreign workers, immigrants and refugees

See [localization](https://github.com/mems/calepin/blob/main/Development/Development.md#localization)

* [Translation](#translation)
* [L’internationalisation, c’est long et dur (et ça racle le fond) | Sam & Max](http://sametmax.com/linternationalisation-cest-long-et-dur-et-ca-racle-le-fond/)
* [Localizing PHP Applications "The Right Way" — SitePoint](https://www.sitepoint.com/series/localizing-php-applications-the-right-way/)
* [Internationalization in PHP 5.3 - Zend Developer Zone](https://devzone.zend.com/1500/internationalization-in-php-53/)
* [Korean Hangul Syllabary in Unicode](http://gernot-katzers-spice-pages.com/var/korean_hangul_unicode.html)

Tools:

* [How to translate a language file from a GitHub project - POEditor](https://poeditor.com/help/how_to_translate_a_language_file_from_a_github_project)

**Culture differences**

...and misconceptions

Services (ex.: social network) are not the same everywhere:

* in China Facebook and Twitter are banned, they use WeChat and Weibo instead
* PayPal vs Alipay

Asians (who use [hànzì](https://en.wikipedia.org/wiki/Chinese_characters), etc.):

* use lot of text and links, because it's hard to write logograms
* no text italic (bold is not common), min 12pt, no spaces, no capital, not lot differents fonts
* use lot of graphics animations
* use arab numbers in domain name to speed up writing it
* can use [Pinyin](https://en.wikipedia.org/wiki/Pinyin) (use Latin alphabet)
* use QR codes: [QR Code, why it works so well in China? — Yibo’s Look into China — Medium](https://medium.com/yibo-look-into-china/qr-code-why-it-works-so-well-in-china-21061b615a57)

Arab is more calligraphy art than western scripts, it's right to left:

* [Taking A Closer Look At Arabic Calligraphy – Smashing Magazine](https://www.smashingmagazine.com/2014/03/taking-a-closer-look-at-arabic-calligraphy/)
* [Writing Systems And Calligraphy Of The World – Smashing Magazine](https://www.smashingmagazine.com/2010/05/the-beauty-of-typography-writing-systems-and-calligraphy-of-the-world/)

Symbol signification:

* in Finland, ✓ often stands for väärin, i.e., "wrong"
* [Thumb signal - Wikipedia](https://en.wikipedia.org/wiki/Thumb_signal#International_usage) - "The sign \[thumbs up signal] is said to have a pejorative meaning in countries including Iraq\[5] and Iran"
* [OK gesture - Wikipedia](https://en.wikipedia.org/wiki/OK_gesture#White_power_symbol)
* [Per Axbom on Twitter: "Struggling with an icon (as one does). The struggle here is that the check mark is common for "ok/ready/done". In Sweden it has historically been used to mark wrong answers on tests. The opposite, really. So now I need more understanding on how big of a conflict this really is. https://t.co/C49NPrr9oP" / Twitter](https://twitter.com/axbom/status/1437687684508659713?s=12)

Others:

* [Why Do Russians Never Smile? - The Atlantic](https://web.archive.org/web/20220417130153/https://www.theatlantic.com/science/archive/2016/05/culture-and-smiling/483827/)
* [Why Russians do not smile](https://web.archive.org/web/20210625010125/https://www.chicagomaroon.com/2002/04/12/why-russians-do-not-smile/)

See also:

* [Comment concevoir votre site web pour l'international](https://www.alesiacom.com/dossiers/comment-concevoir-votre-site-web-pour-international)
* [T–V distinction — Wikipedia](https://en.wikipedia.org/wiki/T%E2%80%93V_distinction)
* [ces marques qui nous tutoient - Dimitri Kas -](http://www.dimitrikas.com/ces-marques-qui-nous-tutoient/)
* [Why do Chinese websites look so busy? | Econsultancy](https://econsultancy.com/blog/67466-why-do-chinese-websites-look-so-busy)
* [Seven rules for perfect Japanese typography | AQ - Design for digital products in Tokyo and Paris](http://aqworks.com/en/blog/2016/09/20/perfect-japanese-typography/) and (same article, but on Medium with comments) [Seven rules for perfect Japanese typography – AQ writes – Medium](https://medium.com/aq-writes/seven-rules-for-perfect-japanese-typography-c377fbf49d5)
* [Why Japanese Web Design Is So Different - Cultural, Linguistic & Technical Factors](https://randomwire.com/why-japanese-web-design-is-so-different/)
* [Yang Liu. East meets West - TASCHEN Books](https://www.taschen.com/pages/en/catalogue/graphic_design/all/04623/facts.yang_liu_east_meets_west.htm)
* [Etiquette — Wikipedia](https://en.wikipedia.org/wiki/Etiquette), [Category:Etiquette — Wikipedia](https://en.wikipedia.org/wiki/Category:Etiquette), [Category:Etiquette by region — Wikipedia](https://en.wikipedia.org/wiki/Category:Etiquette_by_region)
* [Culture — Wikipedia](https://en.wikipedia.org/wiki/Culture), [Category:Culture — Wikipedia](https://en.wikipedia.org/wiki/Category:Culture)

**Dyadic rational measures**

![US Measures](https://github.com/mems/calepin/blob/main/Project/US%20measures.jpg)

```
// 32nds of an inch: 2 3/8″
// Dyadic rational
//
long value;// to define
long denom = 32;
long numer = Math.round(value * 32.0);
while(numer % 2 == 0 && denom % 2 == 0) {
	numer /= 2;
	denom /= 2;
}
frac = numer + "/" + denom;
```

* [Dyadic rational — Wikipedia](https://en.wikipedia.org/wiki/Dyadic_rational)
* [America’s Fractional Mind | The Metric Maven](http://themetricmaven.com/?p=2595)

#### Market

Market (marché nord américain, européen, indien, etc.): [territory, languages](/calepin/data/locale/locale.md)

See locale's region

* `global` / `*` / `international`
* `001`, `europe` / `EU`
* `france` / `FR`

#### Translation

Keywords: locale, language, region, territory

Need to define [locales](/calepin/data/locale/locale.md)

* [Localization Guide — Localization Guide 0.9.0 documentation](http://docs.translatehouse.org/projects/localization-guide/en/latest/index.html)

### Adaptive

Art direction (depends context) Context: screen size, usage (mouse, touch, etc.), device (tv, print, handset), network capability, user capability, browser capability, device capability, hardware capability Escalator (hardware capability, etc.)

Target user:

* region
  * language (numerals system, text layout, plural forms, keyboard shortcuts, etc.)
  * culture (paper size, weights & measures unities, currency, etc.)
  * writing conventions (date/time format, time zone, numbers formating)
  * regulatory compliance (borders shown on maps, taxation laws, labour laws, etc.)
* technical abilities (usage of new technologies or tools)
* social position
* disability (temporarily or permanently), accessibility issues: color blindness, blindness, muscular or neurology disease, immobilization...
* age
* gender
* defined options
* contexte d’utilisation

Hardware:

* screen size
* pixel density
* bandwidth
* touch screen
* traditional mouse
* keyboard arrangement and different layouts
* performances

Software:

* OS (type — family, version)
* browser (type — family, version, capabilities like CSS support, image formats, images and videos support — one or more in same time, etc.)

Eviter le browser sniffing et la catégorisation (mobile, tablet et desktop, des devices peuvent faire partie d'aucune ou de plus d'une catégorie)

### Personas

* [Personas | GitLab](https://web.archive.org/web/20230119133629/https://about.gitlab.com/handbook/product/personas/)