A Phased Approach for Leading DevRel Community Initiatives

[wesley83]

This is an iterable approach to organizing and managing the many community-driven initiatives important to the DevRel Profession. This process is designed to ensure that the DevRel Foundation isn’t led by the assumptions of the steering committee as to what the important topics to tackle are but instead charged with the stewardship of collecting input, creating processes to organize that data, and shepherding solutions to real problems. Embedding flexibility and iteration ensures continuous growth and adaptation to meet the community's evolving needs.

Phase 1: Identifying Common Themes

• Gather key themes that matter to the community through surveys, office hours, Discord, GitHub Discussions, and other community conversations. (Duration: 2 - 3 Weeks)
• Announce this initial list of key themes to the participants and the public via GitHub with the option for the community to add more suggestions. (Duration: 10 Days)
• Finally, the steering committee will be able to add additional themes to complete the list. (Duration: 4 Days)

Phase 2: Establishing Group Managers

• Round 1 - Using the final list of key themes from Phase 1, volunteers from the community will opt-in to manage the group responsible for a theme. (Duration: 10 Days)
  • Limit of 1 group selection per person.
  • Minimum of 2 hours per week commitment.
  • Minimum of 6 months commitment.
  • Minimum of 3 managers for each group.
• Round 2 - The total number of managers for each theme is made public. Groups with under 3 managers will be labeled “At Risk.” Managers can move to another group or stick with their initial suggestion. Volunteers who didn’t participate in Round 1 still can join in Round 2. (Duration: 1 Week)
  • Limit of 1 group selection per person.
  • Minimum of 2 hours per week commitment.
  • Minimum of 6 months commitment.
  • Minimum of 3 managers for each group.
  • Selections are final.

Phase 3: Securing Manager Commitment

• Groups that meet the minimum threshold of managers will move to this Phase.
• Managers provide information and sign commitment forms that outline the expectations for their roles. (Duration: 1 Week)
  • Minimum of 2 hours per week commitment.
  • Minimum of 6 months commitment.
  • Agree to the Code of Conduct.
  • Agree to governing document.
  • Agree to make their name public.
  • Provide bio, management experience, and the reasons why they chose their theme.
• The steering committee will review the information. (Duration: 10 Days)
  • Managers who have not completed the required information will be removed and notified.
  • Managers who do not have experience in the theme will be removed and notified.
  • Groups not related to DevRel will be removed and notified.
  • Groups that have less than 3 managers will be removed and notified.
• Managers and Groups removed may file an appeal. (Duration: 5 Days)
  • A majority of the steering committee must vote to overturn an appeal.

Phase 4: Laying the Foundation

• Managers added to tools. (Duration: 5 Days)
  • Managers will be added to the [group]-managers@lists.dev-rel.org distribution list.
  • Managers will be added to the #[group] channel on the DevRel Foundation Slack instance.
  • Managers will be added to the [group] repo on the DevRel Foundation GitHub.
• Creation of Group Charter (Duration: 2 Weeks)
  • Write a well-defined mission statement for the group for the 6 month period.
  • Define the leadership structure for the group.
    • How are decisions made?
    • How will members be included in decisions?
    • Who is responsible for what tasks?
  • Estimate what resources and personnel are needed to accomplish the mission statement.
  • How often and when will the group meet?
  • All managers must hold a consensus vote to agree on the charter.
• Feedback and approval from the steering committee. (Duration: 1 Week)
  • Groups that do not receive approval will be removed and notified.
  • This decision can not be appealed.

Phase 5: Recruitment

• Each Group’s Charter and the list of managers will be made public.
• Recruitment drive for membership to the group. (Duration: 2 Weeks)
  • Group managers create the application form for membership.
  • The steering committee will promote the recruitment process.
  • Group managers are encouraged to promote the recruitment process.
  • Each group must receive a minimum of 8 members.

Phase 6: Finalizing Membership

• Groups will select their members. (Duration: 2 Weeks)
  • Members must confirm their participation in the group.
  • Members are limited to membership in a maximum of 2 groups.
• Group managers hold a consensus vote to move forward. (Duration: 3 Days)

Phase 7: Getting to Work

• Members added to tools. (Duration: 5 Days)
  • Members will be added to the [group]-memebers@lists.dev-rel.org distribution list.
  • Members will be added to the #[group] channel on the DevRel Foundation Slack instance.
• Hold initial group meeting/orientation. (Within: 2 Weeks)
  • Introductions and Q&A.
• Group documentation creation. (Duration: 2 Weeks)
  • Define the goals of the final deliverable after the 6 month period.
  • Create a timeline with significant milestones.
  • Assign roles for members if needed.
• Submit documentation to the steering committee.
  • These documents will be made public.

Phase 8: Ongoing Progress and Reporting

• At least 1 group manager must present their progress at 1 of the DevRel Foundation open meetings every month.
  • Progress against their timeline.
  • Lessons learned.
  • Request additional resources.
  • Estimate of work that will be completed before the next check-in period.
  • Announce any significant changes to the group charter or deliverable.

Phase 9: Final Presentations and Future Planning

• At the conclusion of the commitment period, there will be a final presentation at an open meeting. (Within: 1 Month)
  • Deliverables published to GitHub.
  • Wrap-up summary of lessons learned published to GitHub.
  • Recommendations to pass on to the next group published to GitHub.
  • Feedback on the overall process published to GitHub.
  • Optional recognition of group managers or members.
  • Indication of what managers and members would continue for another commitment period and in what capacity.

Conclusion: Continuous Improvement

As we complete all phases, the steering committee will review the entire process. This final step is essential for ongoing growth and adaptability. We may revisit Phase 1 for new ideas and feedback to keep our community dynamic and aligned with its goals.

We value your input on the duration and effectiveness of each phase to balance thoroughness and efficiency. Your feedback will help us refine our approach and ensure impactful, meaningful collaboration.

Together, we can foster a thriving community where everyone has the opportunity to succeed.

[aspleenic]

First off, thanks for putting this together @wesley83! This is a great way to move things forward at a pace that's beneficial to the community. My only concern would be, as the number of participants grows globally, will there be a greater number of "noise to signal" issues that come up?

[wesley83]

First off, thanks for putting this together @wesley83! This is a great way to move things forward at a pace that's beneficial to the community. My only concern would be, as the number of participants grows globally, will there be a greater number of "noise to signal" issues that come up?

Initially there may be a lot of noise produced by having such an open process. This is needed to make sure everyone has the opportunity to have their voice heard. This approach can also cause decision paralysis by generating many niche groups with overlapping, similar, or duplicate missions and interests.

All of this is self-regulating through requiring a minimum number of managers and members. This should quickly bring the number of groups to a reasonable number. It will take endurance to work through this process. The dedication needed will aid the groups in the long run to make sure all members are invested in the success of their group.

Or we could be wrong and it will all fail, which will be a source of learning. That said, if you have any mechanisms to aid in its success, or a replacement for this approach, this is the time to propose one. Feedback is important and we're relying on the community to help us come up with the best solution.

[goofmint]

@wesley83 Thank you for your excellent work!

Phase 5: Recruitment

Where do we recruit the members? Discord? If so, we will have to invite more members.

The diversity of members should be noted. Biases such as only American, only Asian, only male, etc. may not yield good results.

Phase 7: Getting to Work

When we hold an online meeting, we must consider time zones. We should aggressively use online forums like GitHub discussions or Discord channels. Otherwise, some people can't attend some meetings.

This would reduce the commitment period of managers, which may make it easier for some to participate.
Maybe it is difficult to commit to 6 months because of many job & role changes in the DevRel community.

[anajsana]

+1. These are excellent reflections @goofmint! I would like to add some comments too:

Where do we recruit the members? Discord? If so, we will have to invite more members.

I think could be both, Discord and the dev-rel.org community mailing list.

Perhaps having a channel in Discord to align on the next steps with people in the community interested in contributing and leading the efforts on the devrel foundation communications (even creating official roles in the community) can be useful to be more effective when doing the recruiting

The diversity of members should be noted. Biases such as only American, only Asian, only male, etc. may not yield good results.

Maybe is worth it to adopt and adapt DEI standards made by the open source community. For instance, CHAOSS DEI Badge or the Diversity + Inclusion Policies used at LF. While these are mainly focused on events, maybe we can adapt them to fit community management needs here.

When we hold an online meeting, we must consider time zones. We should aggressively use online forums like GitHub discussions or Discord channels. Otherwise, some people can't attend some meetings.

AFAIK, some Discord communities make big use of voice channels

---

Overall, I think that these and other community management-related questions and issues would benefit from identifying a dedicated group of people within the community who are interested in leading these efforts and deciding on the best mechanisms and local groupings (e.g. like local chapters). Maybe thinking of setting up official "community management" roles for this community can be a nice idea to consider

PS: This thought was inspired by a past chat I had with @divya, who shared great feedback on how to build this initiative and make it inclusive for everyone.

[divya-mohan0209]

Left it as an actual comment below
Thanks for putting this together, @wesley83! Does governance management i.e. Code of Conduct etc. also fall under the collection of themes? Or are we looking at having a separate mechanism for setting it up/electing members to it?

[divya-mohan0209]

Thanks for putting this together, @wesley83! Does governance management i.e. Code of Conduct etc. also fall under the collection of themes? Or are we looking at having a separate mechanism for setting it up/electing members to it? Also, are there any minimum requirements for membership i.e. a set criteria or something of the sort?

[wesley83]

The steering committee is creating the governance structure as we speak to define elections and the over arching process/structure. That said, if there were to be a group formed to tackle this topic in parallel that too would be welcomed. Personally I think that would be a wonderful way to include the voices of the community while it's being developed. Just know that if a group is not formed around this topic the steering committee is already in the process of designing this.

As for the minimum requirements for the members of the groups, that is determined by the managers. The criteria is defined in Phase 4 under the "Creation of Group Charter" section where the managers, "Estimate what resources and personnel are needed to accomplish the mission statement."

In Phase 5 the members will see these in the application to the groups: "Group managers create the application form for membership."

In Phase 6 the managers will review the applications and reach out to the people that match their criteria. Then if there is a fit then the applicant still needs to confirm that they do want to join that group, since they are limited to membership of a max of two groups in total.

[divya-mohan0209]

Apologies if this is a stupid question - By members I assume we mean "official" members of the GitHub org of the foundation, yes?
Does that delineate in definition from being an official contributor? Or are they the same thing? The reason I ask is that mandating every official contributor choose a maximum of two areas to contribute to might not be a great guardrail to set since people might want to contribute to more areas of the project.

[wesley83]

Not a stupid question. The term "member" refers to anyone wanting to participate in any of the groups formed under the DevRel Foundation. They don't need to be registered with any specific group or an existing DevRel Foundation GitHub project contributor. The restriction of a maximum of two groups is only within the groups formed under the DevRel Foundation, and other groups outside of the Foundation will not count towards that limit.
With that said, if you feel that a max of two is too small, we are always open to suggestions of what that number should be.

[wesley83]

The plan at the top of the thread has been changed. Where it mentions Slack, it will be replaced by Discord. This is to consolidate communication on a single platform and ensure that historical communication is saved. Thank you to everyone who gave feedback on the plan and recommendations.

[hhkaos]

First of all, thank you @wesley83 for the great work on this 👏 . And sorry for being so late to the discussion.

I just wanted to hear your thoughts on something I commented during one of our meetings about “Phase 2: Establish group leaders”.

I see that “Define the objectives of the final deliverable after the 6 month period.” is defined in “Phase 7”, which makes sense, but I also think that starting the discussion about the scope of the deliverables before asking volunteers to apply to be group managers would also make sense. I say this because if I were considering leading a group, I would want to know if my expectations are aligned with those of the others before I step forward and commit.

Does it make sense?

[wesley83]

Yes, it does make sense. That approach is absolutely a valid option. We purposely chose to go in a different direction, so let me tell you why. The initial process of gathering themes from the community is to supply the managers with the broadest selections. If we defined the success criteria of each theme before managers elected to champion them, then the people who took on that responsibility would be executing our vision, not theirs. We didn't want to put such a heavy hand in that direction so early in the process. Also, since we are still working on increasing diversity in many dimensions, being too opinionated at the start gives another opportunity to inject bias into the framing of the ideas. The current approach allows the managers to take an idea and make it their own. Taking each manager's different interpretations and experiences in the area of the theme and creating a unified mission statement is also an exercise of demonstrating the leadership and collaboration skills needed to drive the success of the group. I hope this helps answer your question, but if not, I'm happy to follow up with you more.

[anajsana]

ICYMI, this proposal has been included in the governance repo and can be found here.

People are more than welcome to suggest edits directly to the doc by submitting a Pull Request 🙂

[saif-shines]

I have a very simple question stems from my lack of understanding of how foundations drive value. I see phase 1 to phase 6 establish who we operate.

The outcomes of Phase 7 and Phase 8, seems to be a lot of documentation or online resources — In short, a lot research distilled to drive inputs for any DevRel to take action. Is my understanding correct?