Jan DSomething that I have said in the past and hear from others, too, that developers can easily get started with contributions to open source projects, while it is difficult for designers. I am more and more wondering if that simple claim makes sense. (1/4)
Correcting a spelling mistake in a code comment is easy for developers. For a designer this is like correcting a color that is slightly off. The programmer would say that this is barely programming and the designer would say that this is barely design.
(2/3)
But any change more complex needs reading existing code, often of soso quality with compromizes only explained by the project's history. And reading that code takes a looooot of time. Understanding the history, context and technology of a project is hard for devs and designers alike.
The advantage of devs is that understanding the code structures this archeology and that they can get help from other devs for it.
Still, devs usually can't do substancial changes quicky, either. (3/4)
The advantage of devs is that understanding the code structures this archeology and that they can get help from other devs for it.
Still, devs usually can't do substancial changes quicky, either. (3/4)
While good documentation, "good first issue"s and an friendly community help both devs and designers, they can't relieve the burden of needing to understand the context before doing non-trivial changes.
Now, external people (e.g. design agencies) are sometimes hired to do work and they do not understand the projects all so well, right? Yes, but they, too, get onboarding (also cause they are expensive) and their problems are often carefully pre-packaged and standardized. (4/4)
Toke@simulo As a UX designer, I have considered contributing to FOSS projects now and then, but for me, the hurdle has always been what the "good first issue" should be. If I think of projects like QGIS or InkScape, I can find things to improve, but it would often have to be consistently changed across the UI. And maybe the changes would get lost in discussions about taste or mental models that a small fix to a code module would not. But I have never given it an honest shot.
> consistently changed across the UI.
That is true, code can be compartimentalized in ways UI can't
(See also: Duguid, P., 2006. Limits of self-organization: Peer production and “laws of quality.” First Monday 11. https://doi.org/10.5210/fm.v11i10.1405 )