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.
@luis_in_brief@edsu Very rich seam here, and you make some great points. The first thing I want to pick up (and I treat this explicitly in “Lifehouse”) is that invitationality in the Occupy Sandy case *absolutely* depended on the abundance and availability of labor, to the degree that an uncharitable observer might characterize some of the things I saw people doing at 520 as the nonhierarchical equivalent of makework, i.e. people doing self-directed, low-intensity things that may not have been
@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 (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 (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)
@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) 🧵
@edsu@luis_in_brief in material furtherance of the OS mission, but neither interfered with that mission, alone or in very small groups disconnected from the main functional areas of the hub. I’d wager that this in itself lent the space a quality of being easy to participate in, and, as you suggest, it meant too that there were always bodies available to greet, do intake and indoctrination, etc.
@adamgreenfield@edsu yeah. At least some open communities have had success along these lines by welcoming people into “intro” tasks like evangelism, or in the Wikipedia case, simply fixing typos. (My origin story is in part about a very invitational part of Mozilla based around bug *triage*, which could be done with just some common sense v. actual engineering chops.)
@edsu@luis_in_brief Uhh, let’s see: as far as “looking over someone’s shoulder” goes, someone I’d like to properly credit (but who I can’t, due to the broken search up in this place) yesterday posted a response to the thread that offered the example of “legitimate peripheral participation,” and that felt right to me – though, again, as you observe, far easier to realize in some contexts than in others. https://en.m.wikipedia.org/wiki/Legitimate_peripheral_participation
@adamgreenfield@edsu 👀 wow, that’s a great label for so much of what I’ve been able to benefit from in open over the years.
And what’s increasingly hard to do in many open contexts, because of … well, a whole shit-ton of factors that mostly are well-intended but often have the side-effects of reducing trust and increasing pressures towards efficiency and output.
@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
@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…)
@edsu@luis_in_brief@cfiesler Yes, I want to be clear that @ldodds was clearly responding in optimism and good faith! The fact that I don’t, personally, think OSM is the greatest model only speaks to the very great difficulty technical initiatives face in being anything like invitational as I’ve tried to define it here.
@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…)
@cfiesler@edsu@ldodds@luis_in_brief See, I don’t understand what that means. And I’m someone who tried to contribute locational information for 12,000 Chicago bus stops to the project, unsuccessfully.
@adamgreenfield@cfiesler@edsu@luis_in_brief might depend on your entry point. In terms of low barriers to entry I think hard to improve on StreetComplete or MapSwipe. And I found HOT projects more accessible than full map contribs.