2017/collabcriteria

What conditions make for effective collaboration? was a session at IndieWeb Summit 2017.

Notes archived from: https://etherpad.indieweb.org/collabcriteria
Video at: https://www.youtube.com/watch?v=NBTX3a3MpRw

IndieWeb Summit 2017

Session: What conditions make for effective collaboration?

When: 2017-06-24 14:00

Participants

Notes

What are the conditions that make for more effective collaborative community? It could be a website or a physical space like a library. The ability to see what's changed, and who changed it, for example: without it you can't address changes and it leads to futility and frustration. What are the other things that prevent futility and frustration?

Wikipedia "doesn't work in theory but does in practice". If that's the case, how can we formalize this?

Relevant links:

Ben: interested in inclusion in this context. Wikipedia really only works for white men.

Victoria: collaboration in open source.

Amit: in a small community you trust and know people. In a wide community you expect trolls or harrassment. Also, I write my websites to be artistic expression in part. On Wikipedia I don't have that ownership. Can there by a hybrid model? eg on GitHub you can own a project but accept pull requests.

Ward: Pete and I have been conversing about this for six months at least. Distilling this, not as a checklist, but as areas of advancement would be very attractive.

AJ: I'm interested in how open source works and how to foster community. I run open source projects, and how do you do that? More collaborative communities are better for everyone.

Ward: A sense of purpose helps a community. For an encyclopedia, being encyclopedic was a guiding role. I made the first wiki, about computer programming, and we asked people to talk about what they did and how it worked. Some sort of charter so people know why they're there works.

Potentially important elements:

Charter: what the purpose is
Norms (code of conduct): how you pursue that purpose
Regular communication: a drumbeat uniting the community (newsletter, regular outreach to newcomers/lurkers...)

It's also important that the community has a sense of owning itself. On Wikipedia the rules are created by community members. Some of the original rules came from Wikimedia, but the community has evolved and dictated its own direction over time. The size matters here: how E2 collaborated was very different to Wikipedia. Changes on Wikipedia are a drop in the bucket and may easily be reverted, whereas you could make more effective changes more easily on E2.

A lot of people have "I am a Wikipedian" as a core part of their identity when they log in. Others don't: they have other facets to their identity that they bring to it, and may therefore edit with different goals and ideals in mind.

Within the Oregonean wiki community, there was a fairly healthy community, but there was a group of insiders. There are still conversations that are ongoing. Pete began it, but it didn't depend on him to keep going.

Regular communication within a group, for example newsletters within the sub-communities relating to Oregon or to military history, has proven to be important. It acts as a drumbeat for the group, linking it together. It's semi-top-down - driven by the group but run from a central point.

Open source communities sometimes set a different bar: for example, they might set a minimum number of tests for a contribution, which contributions will be rejected without. The trick is to not make it feel overly exclusive - but on the other hand, the Oregonean wiki project had a list of members that had a large number of inactive individuals on it. It was hard to know who to communicate with. So some kind of bar is necessary.

Gamification could be a way to help people get started, or a motivator (as on Stack Exchange), but it can also eventually be a barrier to effective communication. If you can make it work, it can be a very effective model, although you also run the risk of overly-templating communication. Stack Exchange has set its charter well, in a way that ensures productive communication. That charter is a first-class part of the system when you're building a new Stack Exchange community. The gamification is outside of your direct control: you have to write a good post, and the measure is simply if other people see your contributions as valuable. There are lots of open source Stack Exchange clones, but none work: they're a community-building company, not a software company.

There's a local model railway club that has a rule for board members: if you want to be on the board, you need to also spend at least a day a month running the trains.

Certain teams on Firefox try to tag bugs as "good first-timer bugs". If you do that bug, they'll arrange a mentor, and it'll be okay if they don't know what they're doing. It's still running, so it's probably working. The intention is to help people get over any intimidation they feel with respect to participating in the community. Pump.io also does this - they'll pick bugs like "fix a typo", in order to help people set up their development environment, run IRC, etc.

Active outreach to communities that are underrepresented is key, and difficult. A "diverse gene pool of ideas." In order to widen your own perspectives, you need to join and actively participate in other communities. In tech, for example, you don't want communities to be all or mostly wealthy, white men.

And, of course, Indieweb is a community with its own principles and its own set of challenges.

Tantek: There are at least four different kinds of communities with their own sets of collaboration challenges:

Local communities. For example, fitness communities, or a local maker space.
Community around a specific project. A community of purpose: they have a goal to produce something beyond that community. For example, an open source project. Borders and language shouldn't matter here; location shouldn't matter.
Specific purpose or goals. There's no single project, but there is a collection of principles. Indieweb is an example of this. It's more about holding a space within which projects can happen.
Super-general communities. The intent is that it applies to everyone. It's meant to be open to everyone. Wikipedia is an example of this.
Common interest communities. For example, bloggers refer to "their community" as their posts and everyone who comments on them.

The three criteria probably do apply to all of these types. For example, Tantek's running group publishes a blog post after every session. But the criteria, and the specific embodiment of them, necessarily come out of a human need. There's no one size fits all approach.

In Ward's federated wiki project, they picked a video conference at a time that worked in the US and UK, but not for Australia. The Australian contributor left. But it was all Ward could handle: what obligation did he have to support everyone to get something going? The Australian contributors could have started their own call.

Do the three core elements just apply to any changing body of information, not just collaborative communities?

Some information is not necessarily public. For example, Ward's company doesn't publish a lot of board communications, or peoples' salaries. There is a question about how much a community needs to know in order to operate as a community. It may be intentional that some information is private in order to not violate personal privacy or distract them from their purpose. On the New York Times, transparency is a value to a point; authorship is known, and type of content (op ed vs news story, for example) is known. But the editorial process that drove the creation of the story is not known. There is significant centralized decision-making about what is appropriate to share and not share.

Tantek: Fifth example: community around a specific blog, personal blog, or community/topic blog.

Zegnat: that type of community is very common among gamers. e.g. in their chats. sometimes they pull those folks into Discord (https://discordapp.com/)

There are communities around lots of things, that don't necessarily participate in that thing. In open source there's a community of people who makes the software, but also a community of users. The same is true of blogs, or gamers on Twitch. These are common interest communities.

Another example, of #5, on social media, Instagram in particular, e.g. yoga teachers, people that comment back and forth, the teachers would refer to as their "community" e.g. on their "story" posts.

On wikipedia, that can also be an article and the people on the talk pages.

Pete: one of the professors I've spoken to in my research was frustrated that it was hard for students in his two-year program to understand and perceive that there was a community around published research, involving peer review, work referencing other work, etc.

Ward: there are natural communities based around what you necessarily need to know to make progress.

Amit: that also informs the conferences and central meeting points.

Ward: I was thinking about diversity. My wiki wasn't diverse in terms of nationality, gender or language. But nobody argued about whether C or Smalltalk was better. In other groups that was a problem. We somehow crossed that boundary by how we chose to talk about our experience.

Pete: So we've talked about effective collaboration. What's futility? What does that look like? If 95% of your community seems happy, that might seem great, but it might be a problem if 5% of people aren't happy.

Ben: But that's just the people in the community. There may be many other people who don't feel welcome to get that far.