Thread:Talk:Design/Design process and documentation/reply

Thanks for your comments. While I understand what you're saying with "Design review over specific changes must be provided on the relevant bug or gerrit change" perhaps you could write it as a suggestion rather than a demand, how we say things is often as important as what we say. Second, that is not our process, when we have Design Reviews its mostly for designers to iterate on projects they are currenlty working on, often in-production or pre-production. Individual designers may comment on bugs, but are less likely to do so on gerrit, as it is a tool for developers.

Design reviews rarely result in "decisions," rather they are meant to make the team think critically about their process, and try alternate routes. We always endeavour to make large/important decisions reflective on the project page of anything we work on, but there is a grey area where over documentation can make things muddy and unclear for people trying to understand what a project is about. I feel we do a pretty good job documenting our process, our decisions, and our rational, but like everything in life, there is always room for improvement.

It also seems like your conflating multiple things, our process documentation as a design team (primaries & secondaries, design reviews, etc) with documentation of a feature (typography refresh) while we seek to drive consistency, and build reusable tools and documentation for developers I just want to be clear that those are two totally different things.

Again, thank you for your comments and thoughts.