Open discussion about the design feedback process, gathering expectations and guidelines from different open source communities.
Every Open Source project is different, every developer and designer is different so hoping that this session would provide a magic answer to our questions is not realistic. Its purpose is to open the discussion and try to gather examples from different communities in the search of drawing some guidelines.
In Open Source, the hardest part is to know when a design iteration should stop: after a certain amount of time, after a certain amount of votes, etc. Since there are no real/accountable stakeholders/decision-makers and the majority of decisions are done with voting, it can be hard for a designer to know which voices should be listened when iterating. Also, design is not really like code, so it can be harder to do partial work and just let another designer continue it. Sometimes things need to be redone from scratch (because of style differences, vision, approach, tools, etc.)
The purpose of giving and receiving feedback in open source should maximize the input all parties receive, having in mind their interests, availability, experience, commitment, etc.
Some questions we could ask: - What can be done when we feel there is no consensus between designer and community or even between community members? - What are the motives for proposing the design work and how much work does it involve? - Should something be accepted just because it's the only proposal? Do we have the luxury to refuse design work? - Should the same rules as in code review be applied? - How do we better match designers and communities in terms of style? - Should people from outside the community be involved in the feedback process? - Are community members the target or representatives for their users?
Meeting everyone's expectations needs a better communication and understanding of the topic and that's what this session tries to achieve.
Speakers: Ecaterina Moraru