A common point of friction in opensource is that we promise people greater influence over the software they choose to use, but then maintainers already overworking themselves often fail to take all the input onboard. This often leaves both camps feeling disillusioned.
But moving past this dynamic is challenging.
And onboarding new help takes special skill that rarely pans out.
I don't what to advise (contributing money or skill helps), so something to be aware of?
@alcinnz I've been trying to discuss this for many months now. Unfortunately, calling out the negative examples doesn't work well as someone always calls your definition of 'wrong' and it spins nowhere (Also SOOO many "but not all repos!!" silliness)
What I've been focusing on instead are the repos that are doing great work and are much more inclusive, focusing on the positive. This feels much better and doesn't get any pushback (yay?) yet still makes the point in a more positive way.
Those tips apply less to end users, who might not have the skills to contribute but might have valuable input. In that case I wonder what we can do improve both the culture and structures so end users are encouraged to give polite and positive feedback, feel like their voice is heard, but don't overwhelm the developers.
Companies with the resources solve this kind of thing by having community managers that spend all day talking to people on reddit etc 1/2
@nix@lucasgonze@scottjenson There's the concept of packagers, who could be helpful as an intermediary. But too many projects seem to find them to be a hindrance instead.
Maybe our tech can be improved to reduce the need for packagers, but I think they fill purposes we don't acknowledge! I think that's a common thing amongst sysadmin jobs...
@alcinnz I'm not too sure what you mean by "packagers" but I am guessing you mean like, ports systems? On BSDs, it's not uncommon to try contributing to ports before diving into /usr/src for example.
As a sysadmin of decades, who has maintained local apt repositories as an example, the local "packages" were not fit for redistribution as their tweaks were specific for that employer.
Very different than the kind of contributions I make as a MacPorts maintainer which are intended to be reused by others.
@nix@lucasgonze@scottjenson@alcinnz I can imagine this being successful. We should not expect end users to file proper bug reports. But someone who wants to help a FOSS project but doesn't have the coding skills to contribute directly could play a helpful role that way.
@lucasgonze@alcinnz These are all very valid points. Why I got involved is that these rules weren't always applied to UX contributors: e.g. the maintainers weren't in sync with UXer's working style and weren't generous to them even though they too were volunteers.
I'm NOT disagreeing with you. Just pointing out the 'being generous' needs to go both ways. For the record, the majority of repos already DO this. It's not a blanket statement but a goal I hope we all can aspire to.
@scottjenson@alcinnz Yes. OSS maintainers can be really hard to engage with for anybody, much less somebody from outside the culture. It can be a bruising experience.
@lucasgonze@alcinnz Which is another side of the same argument that @alcinnz and I are making. There is an ARMY of UX people dying to help in #FOSS#OSS systems but feel their is just some odd mismatch that no one can figure out. This is why I've given 3 talks on this at FOSSBack, trying to get maintainers to understand how to reach out to UX folk (and for UX folk work better in these environments) Many positive examples, but it feels like there is a lot left to do.
@scottjenson@lucasgonze Well, I tried to cover both sides understanding where everyone's coming from. But ultimately, I'm personally in the position of the maintainer overworking myself!
As developers we approach things by breaking down problems & building up solutions, and that's the way developer tooling is setup. But the role of UX is to keep the big picture in mind, to ensure things fit together nicely as we assemble them. Not all devs realise this.
So many projects make the mistake of pointing UX people to work on individual issues...
@alcinnz@scottjenson Big picture work can be a mismatch for the social model of OSS projects. The community behind a project is often wildly heterogeneous. There are a lot of different agendas.
@lucasgonze@alcinnz This is an important insight. I have to assume engineering projects like "reduce tech debt" have a similar challenge. How do OSS projects address this? Are there any good examples of them successfully tackling big picture work? #FOSS#OSS
@lucasgonze@scottjenson I'm not sure if that doesn't make big-picture work even more important! And there's a fair few projects which manage to pull it off...
@lucasgonze@scottjenson@alcinnz Just a data point: I firmly stopped wanting to contribute to open source projects exactly because the burden of being polite to maintainers were squarely and exclusively put on my shoulders, but the maintainers were given free reign to be total assholes to me.
Firefox. Linux kernel. GEM (the GUI). RISC-V cores. AROS. None of them were willing to accept contributions from me as a newcomer without me putting up what I felt was an inordinately large fight.
So, while I use it everyday, I've totally given up on giving back. It's clear my work isn't valued.
Maintainers are overworked and have to deal with a small number of complete idiots. It's exhausting.
Contributors are exhausted trying to figure out how to contribute, defend and land a change.
The point of my talks (so far) has been to avoid laying blame at either side but to talk about ways to fix this, e.g. better contributor guidelines, suggested starter problems, keywords for issues (eg. #UX) , Do/Don't lists, and likely much more
Add comment