Hey folks, I wanted to ask some thoughts on a topic I’ve been thinking about for a while.
So OSS is open and viewable by everyone (that has the ability to find repos etc.) therefore open projects have a sort of ‘expectation’ that anyone at anytime could find the project and look to make a contribution.
If there’s a contributing doc or issues that are clear - it’s pretty easy to see how to immediately contribute and participate - most of the time these are short/light-weight docs and descriptions that require asking questions but still it feels like it’s ‘open’ to offer design contribution to.
Less well documented projects seem harder to contribute to if they don’t have these kinds of documents but they are still open and you can add an issue or ask questions etc.
So I don’t know if other designers feel this way but it often feels like we need to ‘ask permission’ before we contribute design to projects. Because design is an unusual contribution and sometimes unwelcome.
So I’ve been thinking about organising design contribution hackathons but not asking projects before hand for permission to contribute. Any thoughts from both a design pov or project pov on how to do this well?
My first thoughts after reading your lines are:
It’s a good idea to contribute design to the OSS world, and I support it.
On the other hand, design contributions (like every other contributions) should be welcome. Putting myself in the role of a dev and seeing such a contribution with their eyes: if I don’t see a value in a particular contribution, even if it is made with the best intentions, the chances of acceptance are low. In German, we have a saying: “Jeder Ratschlag ist auch ein Schlag.” - Every piece of advice is also a blow (the play on words sadly gets lost in translation here). Every contribution will also lead to efforts on the maintainer’s side: reviewing the contribution, perhaps discussing it and later maintaining the resulting code.
Therefore, contributing oneself or motivating people for a contribution that gets denied is a waste of efforts and may cause the opposite. If one would really keep that contribution alive, the only way is to fork - which means, you have to keep your project alive, regularly pull upstream changes etc., otherwise it is wasted efforts, again. The best thing one could do here is to document it like “this design works bad - but that is better, because it solves that problem” (like the examples in the NNGroup newsletters). This had an educational purpose.
In my opinion, the first step should be finding out, whether the OSS maintainers see the need and value of design help and are willing to accept it. If there are doubts, one could clarify this and show the value of design (showing, not talking). If they don’t seek design help and are not open to design contributions, a designer should find a better field of action. Choose your battles.
Given how hard it is to contribute design even when asking for permission, I fear that this might be frustrating for the hackathon participants (at least if the goal is that the contributions actually get used and accepted)
Analysis, assuming interesting code contributions are actually difficult, too
I wonder if the idea that anyone can just contribute code is also misleading. Implicitly, the idea of contribution seems often to be bug fixes for what is basically a mistake in the code: A 1-off error, an exception unhandled etc. Proposing an deeper change in code architecture is hard and also required discussions and permissions.
So even though the infrastructure and values are in their favor, code contributions are not trivial either; the ones that are easy are the equivalent of changing a padding or correcting line-weight in an icon. However, the outward rhetorics of “everyone can participate” (without qualifications) hide code is pretty limited, too.
Thanks both for your thoughts and comments here, I 100% agree that ideally and preferably, there’s engagement with the OSS project before any contributions are made (both code realted and design related) but I do think that code has more of a ‘established’ acceptance/presence in OSS - both in terms of being included in contributing documentation and if there are issues in the repos then they are usually a code related one (either an issue raised by a bug finder themselves or otherwise)
I think I’m trying here to challenge the hypocrisy (not sure if that’s the right word here!) of how design more readily has to ‘ask’ for permission/inclusion etc. due to it being an unusual, unwanted or surprising contribution. I wonder if normalising design contributions as part of the overall OSS interaction theres a shift that can be made towards those kinds of contributions being more readily accepted.
Related to this issue I think about ‘What is the best/good’ first contact a designer has with an OSS project?’ what contact method and content legitimises design as a valuable contribution and what also ‘mimics’ the spirit of ‘I saw/noticed something ‘wrong’ in your OSS and I added an issue to fix it with a potential fix’ - I wonder if this approach to designing in OSS might reveal some interesting results/interactions.
The big social coding platforms all put the code front and centre - it’s what you see first and the design ‘metaphor’ they use is that of a file browser/editor/IDE to navigate a codebase. I wonder if that doesn’t immediately place design concerns at a disadvantage. Contrast that with the visual-first social/sharing/contribution platforms e.g. Pinterest/PenPot where the metaphors that greet you are that of a mood board/drawing tool/gallery where design contributions are encouraged and expected.
Why couldn’t Github/GitLab/etc have a mode to browse a project by how it appears to the user? Imagine flipping through a gallery of screenshots so you could directly raise an issue against a dialog box, draw a circle around a mis-aligned button or a low contrast menu item for example. If the appearance & behaviour of an app was presented for scrutiny in the same way as the code is perhaps attitudes toward design contributions would change?
I think this is a great point!
From my perspective, this touches on another perspective – that of the users of software and especially those who are willing to make changes for the better, rather than just complaining. I believe they usually have no objections against design because they believe that good design can improve their own experience.
In my humble opinion, this post might have been triggered by Eriols question, but it’s a little bit off-topic. How about moving this to a new topic in this Design Lounge category and continue the discussion there?
In my opinion, for an open source design hackathon to be successful, we need to collaborate with project maintainers. This would prevent the “unwelcome” contributions part.
To prepare for it, I was thinking of curating a list of projects where we know the maintainers are open to design contributions. Creating this list could be a big lift as it requires “screening” a project. If a project is open to design contributions but doesn’t have any documentation, we will need to add documentation before the hackathon starts so that participants have a starting point. I’m open to helping out with this but would love to hear your thoughts on this.
Regarding “asking for permission”, I think that developers do the same in issues. From my past experiences, developers tend to mention that they like to work on the issue. But I guess for designers, just like in our regular jobs, we may need to communicate more with stakeholders (maintainers) more than developers do.
Hopefully there is some useful bits in my rambling Do you think that curating a list of projects as a preparation would help? I know there is a list of projects already available on Open Source Design but in the past it wasn’t too obvious to me how to contribute design to those projects. Anyway, I would love to help out with this initiative and would love to keep this discussion going
Thank you all for engaging in this post - I think the topic can raise a whole lot of connected questions so it’s totally optional for folks to start their own threads re. how platforms could encourage different core interactions re. more visual bug raising (such a cool idea! I imagine it’d make certain processes much more friendly for young learners too, like how Scratch’s visual ‘blocks’ make making programming easy for kids.)
I think it’d be great to have a thread here on the forum which is like a general ‘How can platforms for OSS be more design focussed/friendly’? but i’m sure there’s loads of other title options.
Also @aaronang I would love to help do a list of OSS projects that are design ready/friendly - I think that’d be such a fantastic resource for OSD to help maintain.
Re. the hackathon question
I do agree that working with devs and OSS projects is preferable but I also want empowerment for designers to work on contributions, pick up issues and suggest issues without that tender and gentle ‘Would it be ok if I did a UI design for this that improves X’ I would like there to be a little more boldness like how some ‘bug reporters’ straight up say ‘Hey this thing is broken in X way for me and heres how I would like that fixed’
@Erioldoesdesign I took the initiative to create a list but it’s very bare. Would it be better if we moved the repository under the Open Source Design organization? What would be best place for this project to live as there is an existing list of projects from the OSD organization?
While I was looking for projects on GitHub, it immediately became apparent to me that “design-friendly” is not as straightforward to judge. I guess we will learn as we work on this list? Another issue that I observed is that many open source projects may require some technical knowledge to set up the software product to run locally if it isn’t hosted in the cloud.
Regarding the hackathon, I think being bold doesn’t hurt. Developers face similar issues anyway where their opened issues may never be prioritized or contributions may never be merged.
Another thought that I had today is whether maintainers could use some kind of label similar to hacktoberfest? This may help with project discovery but I also don’t know how we could get buy-in for this
@aaronang: A good start, thank you! As I am currently searching for projects to contribute, I find this very helpful. I’ve just sent you a pull request mainly with the addition of LibreOffice. This also showed me that sometimes there is more than one design-relevant label. Another good candidate label is the “new feature” label, where a design contribution could have a very positive effect from the start.
Perhaps there are more good design practices we can mention for a clearer view. IIRC there were some talks about it at the FOSS Backstage conference this year (see the talks).
Do you think that curating a list of projects as a preparation would help? I know there is a list of projects already available on Open Source Design but in the past it wasn’t too obvious to me how to contribute design to those projects. Anyway, I would love to help out with this initiative and would love to keep this discussion going 
