(apologies for not having the time to make these messages shorter) Another way of thinking of this problem might be as civics-style separation of powers.
Given that the problem is (simplified) "UX design compromised by developers" (wrong target users, implementing the easiest thing, whatever) -- how are we to guard against this? Any solution will necessarily "slow development". That needs to be acknowledged as a cost. One solution might be to have a monthly "UX oversight board" meeting. For proper separation of powers, no member of the board may have a patch up for review by the board (or they must recuse themselves). Board candidates should also be chosen based on their resumes, not just because "we think they could be convinced to serve". I suggest that it would be easier to fill the board if you keep the workload as light as possible. Therefore you could have a (large?) "design team" group whose job was *not* to make design decisions, but rather to facilitate the work of the oversight board. The board's work would be easy if it had a nice agenda for their meeting (which they didn't have to prepare themselves!) listing each patch/bug up for review, summarizing discussion pro/con, with relevant screenshots/video. The board could meet at a scheduled time each month (on IRC, or Skype, or videoconference) and (if necessary) voices pro/con the various proposals could show up and argue their case. The "design team" facilitators could then summarize the meeting, prepare minutes, guide the development of revised patches as necessary, etc. Timing/frequency/size of the board could be varied as time goes on based on workload, etc. Regardless of the strawman proposal above, my main point here is to suggest thinking about the role of design as a deliberate frustration of developers -- in the same way that the legislature and courts are a deliberate frustration of the power of the executive. I think this mindset would lead to a very different idea of "Design Dictator" that the one proposed early in this thread -- whose function seemed to be to rubber-stamp/expedite patches, not preserve UX. --scott ps. ...and preserving UX seems orthogonal to the task of "maintaining design documents", which is a separate job description at litl, at least. -- ( http://cscott.net/ ) _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel