Document principles - #50
Conversation
| * Choose language that provides mutual understanding between engineering and design over specificity. | ||
| * Support new vocabulary with descriptions and examples. | ||
| * Be consistent in the application of vocabulary in written and verbal communication to reinforce understandings. | ||
| * Articulate what you're are trying to do as well as what you are not doing. |
There was a problem hiding this comment.
Strike 're here (you're are → you are).
|
|
||
| ### Innovation | ||
|
|
||
| * Treat everything as an experiment. Make small incremental steps steps that provide proof towards goals, or disprove them. |
There was a problem hiding this comment.
Strike the duplicate steps here.
| * Seek feedback on implementations as often as possible. | ||
| * Everything is a component. | ||
| * Provide flexibility, but within the boundaries of the system. | ||
| * Assume that people will break the rules, provide safe ways for them to do so. |
There was a problem hiding this comment.
I like this one a lot. We should either add an and before provide here or change the comma to a semicolon.
| @@ -0,0 +1,39 @@ | |||
| # Principles | |||
|
|
|||
| ### Communication | |||
There was a problem hiding this comment.
We could also add a point here about writing code that is easy to read, as IMO that also falls under both internal and external communication. Something like "Whenever possible, write easily readable code. Readable code speeds up the development process and enables us to work smoothly with other teams.
There was a problem hiding this comment.
Yeah I was thinking that would be better covered in Implementation but open to suggestions!
| * Make decisions based on long term goals rather than this week's ship. | ||
| * Evaluate technology by the risk they present, not just the solution they offer. High risk deserves careful consideration, low risk deserves less attention. | ||
| * Have opinions and arguments for them, but remain open to seeing and hearing evidence that clashes with them when those opinions become wrong. | ||
| * Prioritize solutions for people who use the system and how it serves the customers who use products built with the system. |
|
I'm going to merge this once I have the 👍 - we can continue to iterate, and long term I think part of this can be pulled out into global operating principles for working on all Primer projects. |
This is a WIP. We started the discussion in a google doc, starting to flesh out into more memorable and concise sections.
@primer/ds-core This is definitely not finished but please comment or suggest additions etc. as this should be a collaborative effort!
👀 Rendered