“Rebooting” Community WG #1134
Comments
|
@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:
Would love people's feedback on this breakdown and if it resonates! Specifically @ipfs/wg-captains, @Stebalien, @yusefnapora, and @daviddias =] |
|
I like this breakdown of roles.
A couple of thoughts:
* I like that you make the distinction between contributors and users.
Supporting and growing these two groups are very different types of
activities. Fine to roll-up under a single role at this point, but we
should have an eye towards treating each separately as we grow.
* For contributor support and growth, we should be very clear about what
type of contribution we want, and what the goal is. Do we want more
developers working on the core projects to accelerate them? Do we want
testing and bug reports? This allows us to be prepared for those
contributions. Otherwise our evangelist might be great at getting loads of
people to show up and it creates chaos for the core team, who aren't
prepared for it.
* We should have a clear strategy for mitigating "we have a
community/documentation/evangelist person now, so it's not my job". We want
team members who naturally gravitate to any of these activities to have
clear permission and encouragement to do so. So maybe this is communicating
to the team a policy around time spent on these things, as well as
measuring it, and giving recognition for it?
…On Fri, May 31, 2019 at 1:00 PM MollyM ***@***.***> wrote:
@mikeal <https://github.com/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:
1.
*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.
2.
*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.
3.
*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!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/ipfs/team-mgmt/issues/947?email_source=notifications&email_token=AAAMHNYJWL75W7KOMQPEHVDPYF7T7A5CNFSM4HGXI5BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWWHNTY#issuecomment-497841871>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAMHN7HAMYMMVS24AZ3723PYF7T7ANCNFSM4HGXI5BA>
.
|
|
That sounds like a great breakdown and I second everything @autonome says, especially distinguishing between supporting users and contributors. |
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.
The text was updated successfully, but these errors were encountered: