social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

489
active users

Missed this Sunday. I think some sorts of engineering projects are very hard to make welcoming in this way, but I should probably still sit with the challenge rather than rejecting it out of hand.

social.coop/@adamgreenfield/11

@luis_in_brief I'm not disagreeing (or trying to be disagreeable) but do you have an example?

@edsu perhaps @adamgreenfield can push back, but as I read it his invitationality implies a few things:
(1) tasks that can be done immediately (or nearly immediately) by "the person off the street"; this is rare in open engineering projects (though some projects try to change that, with varying degrees of success)
🧵

Luis Villa

@edsu @adamgreenfield (2) a certain excess amount of labor which allows for both "people doing work" and "people performing invitationality".

I suspect if invitationality is built into the culture from an early point, this boundary can be made more porous, but again it's easier IRL when you can trivially *invite* someone to "observe over my shoulder" in a way that's trickier online (but again that could be designed for in tools)

🧵 more if I remember after my :30 meeting...

@edsu @adamgreenfield (3) work that is highly parallel; i.e., if new person off the street does does something slowly or badly, it doesn’t slow/stop work for others.

Wikipedia does this very well, which is part of its success despite otherwise not being very invitational.

Traditional software development used to be *actively terrible* at this, which was a competitive advantage for open software for a long time. But for many mid-size software projects it is hard.

@edsu @adamgreenfield (4) it works best when the newcomer is likely to be engaged, motivated, and trustable: eg, in the post-Sandy situation (as in most post-disaster situations, despite looter myths) new helper almost certainly was not a thief, so high-trust/low-barrier works great.

That’s true of the median open source contributor, but as we’ve learned the hard way the long tail of trolls/black-hats is very long and highly-motivated :( Unclear how to balance that reality with invitationality.

@edsu @adamgreenfield none of this is to say that Adam’s concept is bad; I genuinely want to explore what an invitational culture would look like in many open contexts. I suspect that if you built it in from day one, some pretty interesting things would result. (I should revisit @cfiesler on AO3 through this lens…)

@luis_in_brief @edsu @adamgreenfield @cfiesler looking over your list, OSM has all of this I think? And the chapter/local mappers setup helps to blur lines between different ways of working and learning together

@ldodds @edsu @adamgreenfield @cfiesler other than it being completely undiscoverable and technically undecipherable, yes ;)

@ldodds @edsu @adamgreenfield @cfiesler (I don’t think you’re completely wrong, to be clear; to the extent OSM does invitationality well, that is part of why it has survived at all despite often having very high barriers to entry. But I haven’t burned through all my remaining store of snark from the other place yet…)