Communities

[b5]

@flyingzumwalt & I had a call yesterday where he suggested a feature that I think speaks to the core of the datatogether model that we don't currently have on the roadmap. As soon as he brought it up it was a bit of a "duh" moment:

We need a way for communities to represent themselves on data together, drawing attention to their work, and helping grow & support their efforts.

This feature would be analogous to GitHub organizations. I think we should refer to them as communities, but am happy to debate if just calling them "organizations" would provide more clarity. On a technical level this would be introducing a type of user. Communities, like users, would get a page on data together where they can set profile information, and at first the biggest thing they can do is create collections of urls that they're either already preserving. Users can create, manage, join and leave multiple communities. Users would join existing communities by invite from community "admins".

In practice "communities" could mean whatever it needs to. Possible examples of communities that come to mind are: EDGI, Data Rescue Boulder, Data Rescue Boston, Civic Tech Toronto, DataKind, CalTech.

If you want to hear me ramble about it, there's apparently a video for that

Thankfully, lots of this is already built into all aspects of the data together stack. The identity service already supports "types" of users, the frontend was coded with all of this in mind. The biggest shift is just recognizing how important it is to get communities properly represented as the real stars of the show on the data together platform ASAP. The first part of this proposed roadmap will be very straightforward, at which point we'd all have something we can play with while we make decisions about next steps.

Proposed Roadmap:

1. Proof of concept

estimated three days to complete

• [x] Stub out communities in the web app using fake data injected directly into the frontend:
  • Communities List page
  • Community Profile Page
  • Show a list of users as members.
  • User-picker, so users can decide if they want to create things like collections on their own account or the community account
  • Edit Community Details page
• [x] Add wiring to fetch this data from the backend
  • add api endpoint to list a community's users.
  • Update identity service to support querying users list for communities-only
• [x] Inject Initial communities into the backend manually, drop fake data.
• [ ] Publish initial PR. At this point users will need to be manually added & removed from communities.

2. Permissions & Invites

who knows, this could take a while, I'd guess four weeks(ish)

• [ ] Plan & decide on permissions. (do we have admins? how does it work?)
• [ ] Finish first pass of permissions service
• [ ] write Permissions for Orgs
• [ ] Stub out invites on the frontend
• [ ] Implement Invites on the backend

3. Expand

this will take infinity time, obviously

• [ ] Community & User Profile Photos
• [ ] Community twitter links
• [ ] Community API / technical links
• [ ] Community distributed web integration (!?!?!?)

Feedback welcomed, loved, appreciated.

[mhucka]

This definitely seems like a concept that will be needed. I assume that a community can have a list of data items/resources/whatever associated with it, right? (A kind of collective ownership/responsibility for a set of resources.) So, presumably the community page will include a list of those?

[dcwalk]

Hey, agree an immediate "yeah!"

some thoughts:

• This brings me back to @nshapio's (aptly phrased but short lived) "archival cluster" -- something seems to me important in a name such that maybe we don't want to settle to quickly on "community," there might be something more evocative
• I'd really really really like this to be something that only develops after taking with groups and hashing out across different groups how they imagine using a feature like this? Especially when I read this:

  Communities, like users, would get a page on data together where they can set profile information, and at first the biggest thing they can do is create collections of urls that they're either already preserving. Users can create, manage, join and leave multiple communities. Users would join existing communities by invite from community "admins".

I have a sense that maybe this is one path but not the one that groups of people would elicit (I'm just now thinking how the "EDGI community" would approach...)

so basically, don't want to be a block, but hoping we could build in (and maybe connect to Aug or Sep event??) some sort of investigation into features with users before going too far in building 'em out?

[flyingzumwalt]

I want to echo @dcwalk's suggestion. The important thing to do here is to include a placeholder -- something that spurs conversation and iteration around how to allow communities/clusters of people to represent and govern themselves somewhat autonomously. At this stage, where all of the activity in our prototypes is either being carried out on behalf of EDGI or the Distributed Wikipedia Mirror project (with the kiwix dumps), I think it's important for the proof of concept applications to visually indicate things like "you're adding this to EDGI's IPFS nodes and you're able to do that because you're a member of that community" or "you're asking the Distributed Wikipedia Mirror's task runner to generate new wikipedia dumps for you". This brings our core idea -- communities using decentralized tech to manage data -- to the foreground. Rather than presenting a centralized kind of UX, the somewhat paternalistic "you've nominated some stuff. data together will put it on ipfs for you", we can present an interface that says "this is a unified interface to activities and infrastructure that's spread all across the web, with many people, communities and orgs harvesting/replicating/analyzing/monitoring/storing data together". After all, a core part of the model we're working on is a counter-point to the idea that we can just give all our data to google (or their competitors) and have them handle it for us on their servers.

The notion, rather than the functionality, is the important thing to surface right now because it gets people thinking and generating ideas about what, exactly, it means for a many communities to deploy and use decentralized infrastructure to manage data rather than relying on centralized tools.

I would actually caution against getting too specific or building a lot of tooling and data models around "communities" and the functionality to support them at this point -- as @dcwalk suggests, the actual development of features and functionality around this notion should happen after we've allowed the ideas to percolate in a variety of organizations/communities/groups and observed their responses. Instead, focus on the decentralized nature of the infrastructure itself -- clusters of ipfs nodes, pinsets nominated by particular groups, metadata maintained by particular committers and aggregated or analyzed by other parties, etc.

In other words, centralized systems have to build representations of communities, capturing some essence of those communities according to a database model. Decentralized systems are communities and they are run by communities. This is a pretty profound shift. We need to point at that and get people's wheels spinning around how to relate with it.

[b5]

Just want to quickly thank everyone for putting such careful thought into all of these discussions. Waking up this morning to such cogent comments is delightful.

I think @dcwalk hit the nail on the head here:

I'd really really really like this to be something that only develops after taking with groups and hashing out across different groups how they imagine using a feature like this?

I interpret that to mean that we can't decide what a "community feature" is on behalf of others. If data together is about communities, it has to be built by communities, and so we can't develop community features in a vacuum. I was thinking along the same lines when putting together the proposed "phases", and set up the first phases as a stand-in conversation starter. I'm in deep agreement with @flyingzumwalt, that the main point of this first phase of development is specifically to foreground the notion of communities. I worry that not having at least an initial notion of communities built in to data together.org creates a strange disconnect between our rhetoric and our tech, so I'd like to get a stand-in in place while we work.

From there we need to tour this around, gather input, and build alternative models. I personally feel a bunch of inner turmoil when dealing with issues like doling out "admin access" or creating "invites" on other platforms (Slack, GitHub), mainly because I'm not sure I agree with the strongly-implied structure of such a decision. It seems to me the "I'm just now thinking how the EDGI community would approach..." is a jump off point for progress in this area. To me it's exciting to think about how EDGI's efforts in documenting it's own organizational process could be interpreted into a technical spec for distributed communities. (cc @murphyofglad, lol @nshapiro you need a GH)

Thinking long-term, I see the goal of this "feature" is to remove it (in a sense). The goal here should be replace the centralized "communities" feature, with a fully-distributed version. The reason for building the feature in the first place is to provide a rallying point for discussions exactly like this one. This is part of a general approach pattern that might be worth highlighting here:

1. Build a centralized system that facilitates convening around transitioning to a distributed system.
2. Ask the convened group to define shared principles for decentralizing.
3. Remove the centralized system.

If you're into metaphors: get a bus, invite as many as possible onto that bus as possible & ask "where do you want to go"? Go to that exciting place and get off the bus.

From a concrete implementation perspective this means we build out the communities feature in a centralized-but-open fashion, and then use the lessons learned from those refinements to draft a model for doing that same feature on the distributed web, then slowly phase out the centralized database bits, replacing them with reading from the distributed bits.

I propose we ship phase 1 of this into production shortly, manually creating communities with no "permissions" features, and the only thing that communities can do is create collections of urls. From there we put a hard stop on dev and go into research mode for phases 2 & 3. This would include doing interviews with mockups, and setting up a staging environment that we can push experimental branches to should we determine that would help spur discussion.

[b5]

woops just found @shapironick on GH. cc!

[mhucka]

Having a minimal placeholder for a first version seems like a reasonable way to go.

[mhucka]

It seems clear that lot of issues intersect in this topic. I agree and subscribe to the intentions of what's been written above (or at least my interpretation of the words), but I want to caution against going too far into a let-anyone-do-as-they-want model. I completely share the sentiment written by @b5,

I feel a bunch of inner turmoil when dealing with issues like doling out "admin access" or creating "invites" on other platforms (Slack, GitHub), mainly because I'm not sure I agree with the strongly-implied structure of such a decision.

The tl;dr version of what I want to say (I started writing a longer explanation that really was just a lecture about human behavior, which is obnoxious and unnecessary) is that there will be some day-to-day procedural decisions that someone has to make. (The someone can change over time, of course.) We definitely want to help make these communities avoid paternalistic power structures, but we will have to acknowledge the need for roles that include some people making decisions that impact the whole community.