The Resources Working Group was formed to aggregate and make assessible assets that support DevRel practitioners and elevate their professional practices. This is done fundamentally by sourcing, curating existing community expertise and industry frameworks, and innovation to mobilize targeted, content creation with specific objectives that build a living and evolving knowledge base.
This section describes the general approach for collecting resources for inclusion. We've identified types of resources that are described in more detail in section 6.
- Resource: an individual record that refers to a resource; assets are synonymous for resources
- Collection: the set of assets that fall within a particular category; library, directory, index, and catalog are synonyms for a collection
- Aggregation: the process of acquiring and storing assets into collections
- Contributor: anybody from the community at large who provided an asset for the collection
A resource collection is the set of all assets that fall within a discrete category.
Criteria for where resources are shared:
- open access to the data
- version control to account for change
- scalable to accomodate a large number of assets
The working group will make a recommendation for where to store resources.
Any member of the community should be able to submit a resource for inclusion so long as it adheres to the criteria for inclusion.
Criteria for contribution:
- anybody may submit a contribution to collections
- tracking of contributions gives appropriate attribution
- participants may be required to agree to a contributor license agreement affirming they have content rights or are the origin source of any contributions made
The working group is responsible for ensuring a framework for contribution is in place.
The value to the community is the ability to use a collection to meet their unique use cases. This value can be compromised if data quality is poor from sparse details or an excessive amount of records that do not support one of the intended goals.
To execute a review:
- review should occur within a reasonable amount of time
- adherence to standards for data quality can be clearly judged
- public access allows for community review and correction
- protection is in place to promote fairness so that contribution is not made to spam the collections for individual gain
- in cases of dispute, the owner of the resource is given priority
- periodically an assessment should be made to ensure the review criteria best serves the devrel commmunity
The working group will define criteria and a recommendation for how the review process works.
Any aggregated resources should be made available for use in any way the community sees fit.
To enable distribution:
- origin asset data can be indexed in secondary storage locations
- origin asset data can be transformed and extended
- intellectual property and terms of use are clearly identified in licensing
The working group will assist in providing reference implementations for accessing, indexing, and presenting resources. It is outside the scope of the working group to take on responsibility for providing an end-user experience.
This working group is composed of volunteers who have experience and interest in Developer Relations.
Typical participants include professionals who have roles such as: developer advocate, community manager, developer relations engineer, developer evangelist, developer marketing, product management, product marketing manager, etc.
We welcome all roles who have an interest in Developer Relations tactics. Organizations that have developer-facing tools can all benefit from a better understanding of the resources available to them.
To empower participation, we've identified the responsibilities for various types of roles.
Participation in this working group is open to all in the community. Individual one-off contributions are welcome by anybody so long as it follows the submission guidelines.
One does not need to be a full participant in order to contribute to the working group. Being identified as a full contributor is however a recognition of consistent contributions including:
- attending and engaging in working group community meetings
- volunteering and taking an active role in accomplishing group tasks identified as issues in the repository or during a community meeting
- submitting ideas and recommendations for inclusion in collected resources
We value regular participation so want to recognize those who do but may not show up as a code contributor on GitHub.
Working Group Managers are an integral part to the function of the working group and are recognized in order to drive action forward. They should do everything regular participants are expected to do and more. Managers are appointed by the Developer Relations Foundation Steering Committee.
Communication
- set recurring meeting times and dates that allow for synchronous communication with participants that may be spread around the globe
- set meeting agendas
- take meeting notes in order to share outcomes and progress
- ensure that participant questions are recognized and addressed across channels
- communicate with the community at regular intervals through updates to github discussions, discord, and the mailing list
Project Leads take on responsibility to construct and deliver a project which delivers a discrete output. See section 6 for more details on projects.
Project Management
- collaborates with managers on the scoping of a project
- defines requirements for the project with input from the community
- manage tasks by creating github issues and triaging them for assignment
- invites participation and contributions from the working group but ultimately accountable
- follow-up and facilitate the completion of tasks within a reasonable time frame in order to meet working group objectives
- maintains the project until time as a new project lead is available
We want to recognize project leads as the primary point of contact for related activities on an individual project as defined in section 6.
To ensure that community participants are able to contribute feedback on how the working group itself functions and operates we've enabled GitHub Discussions. Specifically, the Feedback category is an area that managers will utilize to post surveys and polls that invite input.
Asynchronous public communication is preferred for working group activities. This section attempts to identify the communication channels along with recommendations for how and when we'll use them.
Mailing List
- regular newsletter summarizing working group activities as required to report progress
- meeting/presentation announcements
- used by managers for any working group announcements
- low volume
GitHub
- GitHub Discussions used for working group feedback, suggestions, meeting agendas / minutes, and polls
- GitHub Issues used to track working group tasks
- GitHub Projects used to track multiple tasks into an outcome-driven kanban aligned with working group strategic goals
- GitHub Pull Requests provide opportunity for feedback from participants on any working group operating document changes
Discord
- use the #resource-aggregation channel for working group specific chat
- agenda and summary of any working group calls
- higher frequency of updates to call attention to activity from other channels
- real-time project coordination (please keep major items on GitHub discussions)
- misc discussions
Zoom
- see the next section for more about working group calls
Real-time communication will utilize the working group calendar to list events to be held using Zoom for teleconferencing.
Agenda
- agenda is set by managers with a call for topics a reasonable amount of time ahead of a call
- the agenda is published publicly to the working-group-calls section of discussions
Minutes
- the meeting minutes and attendees should be recorded in the wg-resource-aggregation discussions by managers within a reasonable amount of time following the call
Schedule/Cadence
- once per month on WED or THU at 9:00PM UTC
- to be held mid-week so that it does not fall on APAC weekends with Friday schedule
- once per quarter, assess from participants in community whether we need to have two separate sessions to accomodate different time zones
- announced via the working group calendar, mailing list and discord channel
The procedure for hosting working group calls is described here: #37
To support the activities of the working group, there are activities that are coordinated throughout the year.
- charter review session for community feedback and input on the working group itself, including amendments to the charter
- coinciding with steering committee elections a review of working group manager appointments
- project goal setting and scoping
The Linux Foundation provides access to PCC which has a set of resources for project administrators that we will leverage for the working group.
- Meeting Management Tool: PCC allows scheduling and sharing calendars to host private and public meetings on Zoom. This supports a larger number of participants, longer meeting times, and recordings / transcripts.
- Mailing Lists: PCC allows hosting distribution lists with Groups.io. This is how we distribute email to the working group mailing list.
The DevRel Foundation provides support through administration of GitHub repositories with features like GitHub Actions that enable the review, processing and aggregation of resources. These will be maintained independent of one another and the repository for the working group itself.
This working group repository will be used for the operations of the working group itself and the project management of initiatives during their early sandbox and incubation phases (see Project Lifecycle Stages in section 6.1).
By centrally managing issues and discussions we can leverage working group contributors across multiple initiatives and invite wider feedback early in development. As projects mature to the graduated phase, all issue management and discussions can move to those individual project repositories under the DevRel-Foundation GitHub organization.
All Working Groups within the DevRel Foundation must:
- Function with openness and transparency, meaning that participation is open to all, and minutes and other documents are available and easily accessible to everyone
- Adhere to the DevRel Foundation’s Code of Conduct
- Follows Linux Foundation's Antitrust Policy
- Follow Chatham House Rules
- and as otherwise set up in the Developer Relations Foundation Charter
This Charter is subject to the Series Agreement for the Project and the Operating Agreement of LF Projects. Contributors will comply with the policies of LF Projects as may be adopted and amended by LF Projects, including, without limitation the policies listed at https://lfprojects.org/policies/.
A project is a specific plan or design to create one or more outputs. We organize our works into projects to help increase focus on a discrete set of tasks that upon completion provides persistent value to the community independent of other bodies of work. Typically this involves creation of open data, standards documents, schemas, open source tooling, etc.
Projects this working group undertakes includes themes such as:
- Create a library of developer personas to guide strategies.
- Curate a directory of DevRel-specific software and tools.
- Maintain an events directory to support engagement in industry events.
- Collect a database of metrics and measurements that report performance of DevRel activities.
- Create a standard understanding and definitions of organizational traits for a dev rel maturity model.
- Manage a publicly accessbile website for exploring resources of use to DevRel practitioners.
Our project lifecycle takes inspiration from other Linux Foundation projects under the Cloud Native Computing Foundation (CNCF) and Open Source Security Foundation (OpenSSF). The lifecycle of a project is a multi-stage evaluation overseen by the Working Group Managers to define standards of maturity and adoption readiness by the community.
- Sandbox: Experimental or innovative projects early in their development.
- Incubation: Projects gaining adoption and focused on improving stability and maturity.
- Graduated: Mature and robust projects where adopters have demonstrated readiness for use in their organizations.
- Archived: Inactive or low activity projects that are no longer supported by this working group and not recommended for use for any variety of factors.
A persona represents the type of user that may or may not engage with a product or service. The value of a persona comes from using it to align a business around expectations for current and potential buyers or customers.
The goal for the working group then is to build a persona library and supporting materials to:
- identify key terminology for persona development and types of personas
- define a schema that can be used for a variety of use cases
- provide a versioning scheme to account for persona updates
- manage the library for where personas are discoverable (storage, search, presentation)
- evaluate criteria for accepting and rejecting contributions to the persona library
- collect and share open data-driven segmentation data as it relates to personas
- create educational resources around creating and using personas in developer relations practices
Annually, the working group should survey and identify when and how the community is using the persona library successfully to fine-tune marketing materials, improve user experience, or better understand the buyer's journey. The survey results and insights are to be shared with the community.
For more information:
Developer Relations professionals must use a diverse set of software and tools to accomplish the mission of the role. The value of having a catalog of software and tools is to support the discoverability of resources that help solve day-to-day operational challenges. The problems which a tool may solve can be varied including customer relationship management, ticketing, content authoring, video editing, communication, software development, etc.
The goal for the working group then is to build a catalog that can:
- define organizing principles for what constitutes a tool (problem-oriented, categorical)
- manage the catalog for where tools are discoverable (storage, search, presentation)
- provide a fair and balanced representation of resources that may include competing commercial products
- system for dispute resolution where a community member and tool-owner may have diverging perspectives
Annually, the working group should survey the community for feedback to identify changes in tooling used by professionals in their marketing, sales, product, and engineering tasks.
For more information:
Community is an important part of many Developer Relations programs. Events allow a community to come together to exchange ideas, whether in-person or virtually. Some events may have a single topic while others may have a diverse set of tracks that cover a variety of subjects. Events may be run by a private commercial company, an individual hobbyist, or an event management company. As part of a go-to-market motion, Developer Relations professionals often seek out events that provide speaking calls for papers (CFP) or other sponsorship activities.
- define a schema for events that define dimensions of interest to practitioners
- manage the catalog for where events are discoverable (storage, search, presentation)
- provide a recommended solution for the inter-exchange of event details with existing aggregators, listings, and calendars
- evaluate criteria for accepting or rejecting contributions to the event catalog
- provide educational resources and outreach to event hosts with an opportunity to ensure accuracy of event details
Annually, the working group should survey the community for feedback on the accuracy and utility of the events catalog, dimensions being defined, and the value it provides for their marketing and community efforts.
For more information:
The original charter as described here has been reviewed and approved by the working group managers and foundation steering committee. (Feb 2025)
- Rebranding of Resource Aggregation to be just Resources.
- Definition of projects (section 6) and split manager responsibilities into project leads (2.1.4).
- Increased scope of projects (section 6) to include website, metrics, and org resources.
- Simplified and aligned working group definition with foundation mission.
- Re-branded participants as contributors.