I propose to think about establishing a workflow that makes the idea of “open” more relevant and invites a culture to bounce work around peers (which often are not present in projects).
Specifically I see it problematic when requests for design tasks get answered here in the forum with “I send my proposal by mail”.
I’d like to see discussions and open exchange of ideas, teamwork – all of that with a clear idea of responsibility and authority in respect to the job/project.
Of course that means assigning people when multiple people are interested in a task and that is extra work – but what should OSDs role be? Chose among competing offerings before they are done – or worse: let multiple people do the work and then chose?
OSD could feel a responsibility to act as an authority in steering decisions for projects, it has more experience and skills than any project seeking for design help.
I agree. I saw some “problematic” examples of the in the past, but also ones where a lot of sharing took place. One thing I sadly did not see is sharing of rough, different directions, but this is a general challenge in design to get these shared and not a problem of OSD in particular imho.
I vaguely remember having discussed something similar in the past. One challenge is that all projects that approach the community have internal stakeholders and different tools. So making it all happen according to “our” process (whatever this might be) is hard – it can easily loose touch with the project that needs help.
How, do you expect, can this be done in a place that volunteers of OSD and the participating non-OSD projects accept such decisions – ultimately they are made based on authority (as you write) but how would OSD “get” this authority and make people follow it?
I 100% get this statement/problem. Theres something in the OSD jobs ‘flow’ that feels much like well…how folks regularly solicit for briefs/work and then things go ‘dark’ as all comms is via closed comms channels like email.
But we as OSD ask for a contact email in the jobs form. So that becomes a de-facto way that comms go behind closed doors as it were.
One thing we can change is instead of having email as the comms process for OSD jobs have the forum thread and/or github issues for tracking it.
I experimented/tried github issues as a way of keeping things open in some projects before but it really needs to be embedded in the process as well as encouraged. We can’t ‘stop’ an OSS job poster and a design from ‘taking things behind closed doors’ but we can certainly make it explicit that we don’t want that to happen.
Re. the decision process/steering I think this is a difficult subject. Really the OSS project is an expert on the relevancy of a certain piece of work in context of the OSS project because not all OSD designers here can be experts on their specific tooling (I’ve had this problem before when encouraging open source design contributions to the OSS I worked with once) but there can be better feedback and support loops for the OS designers submitting to jobs.
This would also promote learning among the OSD community with things like ‘How did you do that in [specific design tool]?’ etc. etc.
The answer to that question isn’t easy and would need broad consensus among the OSD community. That certainly is the tricky part.
Here is a rough two-team scenario I could imagine:
The first team gets in touch with a representative (only people with actual authority in the respective project) and helps to get down to what they really need (often projects need help with clearly articulating even that).
That request gets published on OSD forums, inviting everybody to give feedback before the first team makes a final decision on what the final deliverables should be.
A second team works on the deliverables, post their progress or result and get feedback.
The second team delivers.
Both teams name a single team leader that makes final calls. The OSD community at large should feel invited to participate in feedback rounds. It also would need to form teams and encourage the respect of the team hierarchy.
You’re absolutely right that we currently foster bad habits, we really should change that. Just switching from mail to forum won’t change that much I guess. In my eyes a clear interface with expectations about how things will happen on both sides is missing.
A simple back and forth between arbitrary people getting in touch cements a certain “Can-I-has-Eyecandy-for-my-project” approach on the one side and a potentially less effective activism on the other side.
I think we need to emphasize the value of processes behind design work and expose them to a broader audience at the same time.
You can already get that on every other projects forum sooner or later. It’s exactly the experience I was hoping to leave behind.
Finding peers that help you grow and learn is what I think we need – not competitors that try to be better than the last submission. Making use of having the opportunity to bounce off ideas of peers instead of coders is what OSD could offer. Just having everybody throw something on the wall and hoping it sticks is wasting time and effort of people and not fostering teamwork at all. How are we harnessing the fact of design skills of our community?
