Thread:Talk:Design/Design process and documentation

Hi. Thanks for what is documented on wiki. Is Design/Team/Process meant to contain also the internal team practices à la Mobile web/Team/Team norms? I'd like to propose two changes, one very simple and the other a bit less. Undocumented decisions actively disallow anyone outside the inner circle of a team from contributing: this means getting no useful feedback; creating friction; and making design work ineffectual, because design decisions don't self-propagate across the codebase, they need devs to adopt them. Cf. [teampractices] The Rule of Three (+1), [teampractices] [Wmfall] Roles and Processes for WMF Design, [Wikitech-l] Communication of decisions, [Wikitech-l] Meetings vs mailing list,, , (in decreasing order of generality).
 * 1) Design review over specific changes must be provided on the relevant bug or gerrit change (or at the very least public mingle card or whatever). Too often I read on gerrit "Got +1 over [private] email by X, who doesn't use gerrit". Register and publish comments there: very easy. Some team members already do this.
 * 2) Any design decision broad enough to affect more than one commit (e.g. something for multiple repos, or something that is for now "settled"/"consensual" and should resist for some iterations) must be documented on a mediawiki.org wiki page (note: not talk page), with "state of the art" and rationale/supporting evidence for it. Can be one sentence, or two words per item, a stub is better than nothing.

I know you're already working on all this (in particular, on the highest priority right now i.e. updating translatable documentation at Typography refresh + FAQs), there's no urgency to reply; but I think that opening this a thread here on wiki will prove useful to document progress in this area over the next few months.