@doctormo Are you implying that coordination is exploitative?
I assume you coordinate on Inkscape? If so, how do you do it so it's not?
Top-level
@doctormo Are you implying that coordination is exploitative? I assume you coordinate on Inkscape? If so, how do you do it so it's not? 6 comments
@doctormo I'm trying to follow your argument. I doubt you are saying you CAN'T coordinate. Right? I assume you have to on Inkscape. If so, how do you do it so it works? Patience, generosity, friendship, reciprocity, and spaces to hold the community. I.e. not just got issues trackers or mailing lists. And still working it out tbh. @doctormo Agree strongly. It's hard work and there is always more to do. I think we're saying much the same thing. My point is just that there is a "cultural advantage" to programming tasks (for lack of a better term) that allows them to be coordinated a bit easier. UX tasks are a bit more outside the standard flow and just need a bit more help. Just exploring what this means. The "Make a small PR" is an ineffective model for UX work. It can work for trivial changes, but not bigger ones. Yes. It's a round hole square peg. And we both, I think, understand why well meaning people recommend tools for work they don't understand is bad. We might be able to come up with tools for designers. It would be interesting to see as many penpot instances as wiki's available for drafting for example. @doctormo @scottjenson This is less about tooling but more about how the team dynamic is coordinated. Code contributions just have a much "easier onboarding", which in turn means the focus is on them. If we agree that all contributions are valuable we should put in a bigger effort to make ux effort being relevant as well. I can see how that requires heavy lifting on the dev organization side, but the alternative means largely excluding ux. |
@scottjenson
It can be.
Coordinated consent is nonlinear, ask a group of 10 people where they want to go for lunch.