“Rebooting” Community WG
mikeal opened this issue · comments
I’ve been asked to start the thread about “Rebooting the Community WG” or, more accurately, a thread about what to do with community related responsibilities going forward.
This thread will serve as a sort of post-mortem on the old Community WG with some additional thoughts intended to kick off a discussion about what to do going forward.
So, to rewind things about 9 months back, the Community WG came out of a few documents about how Community might work in IPFS and at PL. These were very ambitious documents and without being that ambitious and taking on a lot of potential responsibilities I don’t think we would have been able to hire people specifically for community related roles.
However, the biggest mistake we made, and continued to make long after hiring, was allowing the scope of responsibilities to increase beyond what was reasonable for the resources available. My thought at the time was, these are all community related things and they should be prioritized together. This meant that while the list of responsibilities was large the number of things actually prioritized and happening was quite low. But because there was this reference list of responsibilities, most people in other teams just assumed that these things were happening and they shouldn’t bother with them.
The core problem with having dedicated people and a working group for community is that community in IPFS is literally everyone’s job. Every person in this project engages with community members and has some number of community oriented responsibilities. And they probably have a better understanding of what the community priorities are in their subject area than anyone else.
Since community is such a broad topic that effects everyone in every project, community people get added to a lot of conversations, work groups, email lists and other threads. While these are well intentioned and rather small, in aggregate they add up to a significant amount of time and work because every thread requires the community folks to get the context everyone else who spends more time in these groups already shares.
Looking at the current state of the project and how things are laid out, I wouldn’t separate the leadership of “community work” from “project work” as they are effectively the same thing and should be lead by the Project WG (which didn’t exist 9 months ago). I also wouldn’t create a working group as broad as “community” but instead I’d add group(s) for specific tasks that you can also tie to ownership of certain projects or resources (evangelism, documentation, etc).
Lastly, I don’t think we’re going to make a lot of meaningful progress on getting more community contributors until we formalize a governance structure. It’s still unclear even to me how decisions are made in the project and how to unblock a decision when there is not yet agreement. This belongs in its own thread, and I’m happy to write it up in more detail when the project is ready to take this on. In the meantime, IMO, work we put into trying to grow the contributor base won’t be very effective until we have a real governance structure in place. It’s difficult, nearly impossible, to retain and grow contributors when you can’t tell them what their place in the project is and how they can grow into other decision making roles. Whatever that structure looks like, defining it is clearly outside the scope of a “Community WG” but should be considered a pre-requisite to starting one if one of the goals is to grow the contributor base.
@mikeal and I chatted more about this topic, along with getting feedback from wg captains on the issues they experience. To that end, we are thinking of three separable roles that each have their own responsibilities and expertise:
-
Community Manager (P0)
Responsible for our community channels to ensure that all contributor and users are welcome, engaged, and getting the help they need. Uses a strong technical understanding of IPFS to help answer open questions and figure out how to get started giving back (leaving docs, examples, and other learning materials better as they touch them). Also surfaces community needs and problems to other working groups for debugging and action. The goal for this role is to improve the experience of participating in the IPFS community for current inbound contributors / users. -
Content / Documentation Specialist (P1)
Works with existing IPFS content (docs, examples, guides, etc) to ensure they are useful, accurate, and up to date. Writes docs, specs, explainers, and how tos to ensure there are well documented and smooth paths to using IPFS for community needs. The goal for this role is to ensure IPFS users are successful and empowered with accurate information and clear guides. -
Project Evangelist (P2)
NOTE: there's interest in filling this position with a rotation in the near term
An external facing evangelist for the IPFS project presenting at strategic conferences, participating in other forums, and building bridges with dweb communities that we should be interfacing with and contributing to. The goal for this role would be to bring in new groups, contributors, and users to the IPFS project - and create awareness externally about IPFS through a variety of communication channels and formats.
Would love people's feedback on this breakdown and if it resonates! Specifically @ipfs/wg-captains, @Stebalien, @yusefnapora, and @daviddias =]
That sounds like a great breakdown and I second everything @autonome says, especially distinguishing between supporting users and contributors.