Seems reasonable: "Design review" in addition to "code review" for new patches. Like code review, make a reasonable effort to have an experienced designer or someone who knows the design for the particular area, but if the patch stalls, any designer or developer's review will do. If you care about coherent design, spent time doing design review!
I'd just extend this to allow "initial design review" even absent a patch, so that people can get initial review before they sink too much time in an implementation. If you're confident of the basic direction, you can skip this step (your work still gets reviewed before the patch is committed upstream), but if you're uncertain you might want to post screenshots or sketches or a text description of what you want to do and have someone say, "sure, that seems mostly reasonable" before you start implementation. The initial review doesn't have to be nitpicky, because there are inevitably going to be things learned during the actual implementation, but it should serve to keep people from wasting too much time on ideas which are far from the desired design direction. --scott [off-topic, by maybe relevant to people reading this thread: http://ignorethecode.net/blog/2009/05/31/creating-new-documents/ and http://daringfireball.net/2009/02/untitled_document_syndrome on "untitled document syndrome" address a Sugar design issue that's been much batted about.] -- ( http://cscott.net/ ) _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
