Hi Jon! > Are they listening or participating? Transparency and reporting is > pretty simple to solve. Publish logs, document (wiki), and blog and > you're pretty much there. Participation and engagement is much > harder. Basically you need to find a way to build a relationship with > a designer. It doesn't have to be on IRC. IRC is just one of the ways > people actively working on the design of the GNOME core are > communicating. Google docs, git, sparkleshare, and IM are others. Well, currently many people are just listening (logs, wiki blog) because they cannot participate. And it is pretty hard to raise a point once the "closed group" came to an agreement. What happens is that bugs are filed against certain products which stall after some amount of discussion. Sometimes even ending in something that *can* be interpreted as "Sorry, you are not a designer, your argument doesn't count". I think by seperating developers (and other stakeholders) from designers we make a big mistake. Design isn't right just because it is done by designers especially when we don't talk about classical design art but about user-interface design and usability. Don't get me wrong, I think the overall design of GNOME 3 is pretty good but there are certain corners where it would be good if input from non-designers and users would have been considered. > Dealing with timezones and distance is a challenge. No doubt about > that. It is a problem even in our own team. However, once a > relationship has been established (trust, respect, and understanding) > it is much easier to surmount. It is most problematic when building > new relationships. My advice to people who want to become involved is > to be clever and find another way to build those relationships. Many > have. I think it is wrong to assume that people that already spent a lot of time on a project will extend this to find clever ways to get involved with designers. > This could mean picking something that is close at hand and making it > awesome and telling the world about it. Or even making something > yourself. It often turns out to be much more effective than just > showing up on IRC and saying - "hi, what can I do?" That's pretty easy with code because you can make a patch and fix a bug. It is much harder to fix design / usability issues by just showing up and trying to tell everybody that the design decision made was wrong. Even if I would patch some things I don't like about the design I would hardly have a chance to have it integrated if I cannot make my point in a broader discussion. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part