├── Assets ├── BannerTemplate.psd ├── DevRelCycle.png ├── DeveloperRelations.png ├── DeveloperRelationsFunnel.png ├── DevrelTeam.png └── DevrelTriangle.png ├── Developer-Advocacy ├── DeveloperAdvocacyLogo.png └── README.md ├── Developer-Community ├── Assets │ ├── CommunicationFramework.png │ ├── CommunityCanvas.png │ ├── CommunityCanvasGuidebook.pdf │ ├── CommunityCanvasMinimumViableCommunity.pdf │ ├── CommunityCanvasSummary.pdf │ ├── CommunityCanvasWorksheetDoc.pdf │ ├── CommunityCanvasWorksheetSummary.pdf │ ├── CommunityCommitmentCurve.png │ └── DeveloperPortalElements.png ├── DeveloperCommunityLogo.png └── README.md ├── Developer-Evangelism ├── Assets │ ├── HackathonMarketingTasks.jpg │ └── HackathonSocialMediaAccounts.jpg ├── DeveloperEvangelismLogo.png └── README.md ├── Developer-Experience ├── Assets │ └── APIPhilosophy.png ├── DeveloperExperienceLogo.png └── README.md ├── Devrel-Management ├── Assets │ ├── AAARRRPModel.jpg │ ├── DevrelFields.png │ └── DevrelFieldsTwo.png ├── DevrelManagementLogo.png └── README.md ├── DevrelNotebookLogo.png ├── ISSUE_TEMPLATE.md ├── LICENSE.md ├── Loose-Notes ├── LooseNotesLogo.png └── README.md ├── PULL_REQUEST_TEMPLATE.md ├── README.md └── Sample-Reports └── EventConferenceReport.md /Assets/BannerTemplate.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/BannerTemplate.psd -------------------------------------------------------------------------------- /Assets/DevRelCycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/DevRelCycle.png -------------------------------------------------------------------------------- /Assets/DeveloperRelations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/DeveloperRelations.png -------------------------------------------------------------------------------- /Assets/DeveloperRelationsFunnel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/DeveloperRelationsFunnel.png -------------------------------------------------------------------------------- /Assets/DevrelTeam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/DevrelTeam.png -------------------------------------------------------------------------------- /Assets/DevrelTriangle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Assets/DevrelTriangle.png -------------------------------------------------------------------------------- /Developer-Advocacy/DeveloperAdvocacyLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Advocacy/DeveloperAdvocacyLogo.png -------------------------------------------------------------------------------- /Developer-Advocacy/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Developer Advocacy

7 | If they like your product they'll do the advocacy! 8 |
9 |
10 |

11 | 12 |

13 | 14 | ## Table of Contents 15 | 16 | * [Definition](#definition)
17 | 18 | ### Definition 19 | 20 | Here are a few core things that should be the main responsibilities of Developer Advocates: 21 | 22 | * Represent developers' interests to influence product roadmap (product, docs, tooling feedback) 23 | * Feeds back into the product strategy and roadmap and developer support offering (docs, forums) 24 | * Defends feature requests 25 | * Supporting Pre-Sales 26 | 27 | The core part of Developer Advocacy is feedback. Your goal here is to reach the core need of the person that is passing the feedback. A person who gave a piece of feedback should know what happened with their feedback and how was it used. That makes them feel heard and keeps them motivated to continue to share more meaningful feedback in the future. 28 | 29 | **Developer advocates build communities that generates new advocates** 30 | -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunicationFramework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunicationFramework.png -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvas.png -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvasGuidebook.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvasGuidebook.pdf -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvasMinimumViableCommunity.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvasMinimumViableCommunity.pdf -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvasSummary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvasSummary.pdf -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvasWorksheetDoc.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvasWorksheetDoc.pdf -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCanvasWorksheetSummary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCanvasWorksheetSummary.pdf -------------------------------------------------------------------------------- /Developer-Community/Assets/CommunityCommitmentCurve.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/CommunityCommitmentCurve.png -------------------------------------------------------------------------------- /Developer-Community/Assets/DeveloperPortalElements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/Assets/DeveloperPortalElements.png -------------------------------------------------------------------------------- /Developer-Community/DeveloperCommunityLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Community/DeveloperCommunityLogo.png -------------------------------------------------------------------------------- /Developer-Community/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Developer Community

7 | Developer Community - another hugely important part of the Developer Relations umbrella! 8 |
9 |
10 |

11 | 12 |

13 | 14 | ## Table of Contents 15 | 16 | * [DeveloperCommunity](#developerCommunity)
17 | * [DeveloperCommunityCanvas](#developerCommunityCanvas)
18 | * [DeveloperCommunityPersonas](#developerCommunityPersonas)
19 | * [DeveloperCommunityPortals](#developerCommunityPortals)
20 | * [DeveloperPrograms](#developerPrograms)
21 | * [Notes](#notes)
22 | 23 | ### DeveloperCommunity 24 | 25 | In terms of developer community the core question is: **are they customers or partners?** 26 | 27 | * Most communities are unnecessary to members 28 | * Discussion build relationships and relationships build communities 29 | * Developer Community management is about nurturing conversations 30 | * You need to explicitly ask your community for its needs 31 | * Main purpose of the community is to empower developers to share knowledge with each other 32 | * Developer Community is about relying on others 33 | * Developer Community isn't something that you can fully control 34 | 35 | **Developer Community Lifecycle** 36 | 37 | * Inception 38 | * Establishment 39 | * Maturity 40 | * Mitosis 41 | * Death 42 | 43 | **OR** 44 | 45 | * Awareness 46 | * Education 47 | * Retention 48 | * Adoption 49 | 50 | **Developer Communication** 51 | 52 | Hugely important element of your developer community is communication. 53 | 54 | ![](/Developer-Community/Assets/CommunicationFramework.png) 55 | 56 | * Treat all content as public content 57 | * Treat all content as company content 58 | 59 | The secret of marketing and communicating with developers is not to use marketing. There is no developer marketing, only teaching, inspiring and helping. 60 | 61 | **Community Commitment Curve** 62 | 63 | ![](/Developer-Community/Assets/CommunityCommitmentCurve.png) 64 | 65 | Community Getting Started 66 | 67 | * Identify target devs 68 | * Say goodbye to inactive members on a regular basis 69 | * Minimum commitment is expected from each member so set minimum expectations 70 | * Identify their interests and motivations 71 | * Remove barriers to adoption 72 | 73 | **Framework for launching Developer Communities - C.A.R.G.O (from Vanilla Forums)** 74 | 75 | * Concept 76 | * Acquisition 77 | * Retention 78 | * Goals 79 | * Outcome 80 | 81 | **Offering a new space to connect is no longer compelling on its own -> Conducting member research is crucial** 82 | 83 | **Onboarding and keeping developers is key** 84 | 85 | * Make developers feel welcomed and comfortable 86 | * Give specific, simple steps to get started 87 | * Don't overwhelm with too much info/tasks 88 | * Over time interact in multiple ways 89 | * Convey the culture and voice 90 | 91 | **Increasing Developer Participation** 92 | 93 | * Recognition and status boost 94 | * Access to more info, tools, resources 95 | * More capabilities and control 96 | * Swag, cool stuff 97 | 98 | In order to increase developer participation do such audit at least twice a year: 99 | 100 | * What are the challenges for your community audience? 101 | * Who are your community personas? 102 | * Who are the key people within your org? 103 | * Why community should matter to them? 104 | 105 | **A few strategy tips** 106 | 107 | * Make sure questions are answered 108 | * Proactive outreach to encourage additional engagement 109 | * Mark best answers 110 | * Reply to others' posts on related topics 111 | * Encourage less intimidating engagement actions for those who haven't yet posted 112 | * Users might be inactive but they are listening 113 | * "We miss you emails" 114 | 115 | ### DeveloperCommunityCanvas 116 | 117 | ![](/Developer-Community/Assets/CommunityCanvas.png) 118 | 119 | **Community Canvas** is a great framework to use to design a successful community. **More on this can be found in Assets folder** 120 | 121 | ### DeveloperCommunityPersonas 122 | 123 | **One of the things that is invaluable in the community / developer relations space is to create a persona around who the audience is** 124 | 125 | * **Consumers** in a community come with an expectation to be served: they attend events, at events they listen to speakers, in the online community they read or sometimes react to things, but usually only when it seems useful to them. If they don’t like something in the community, they complain or disengage. They feel that leading the community is someone else’s responsibility and they are mostly in the community for opportunistic reasons. 126 | 127 | * **Co-creators** on the other hand actively shape events they go to or they help organize them. In discussions, both online and in person, they actively contribute new ideas and initiatives without expecting anything in return. If they don’t like something, they bring it up for discussion and provide new ideas and suggestions how to address it. If a conflict arises, they are willing to work through it. They invest their energy, time and money into the organization, because they feel that this community is partially also their own organization and therefore their responsibility to push it forward. 128 | 129 | Those personas can have certain community feelings: 130 | 131 | * **Influence** - I have influence over what this community is like 132 | * **Fulfilment** - I get important needs of mine met because I am part of this community 133 | * **Connection** - Members of this community have shared important events together 134 | * **Boundaries** - It is very important for me to be in this community 135 | * **Safety** - I can trust people in this community 136 | * **Belonging** - Being a member of this community is part of my identity 137 | * **Investment** - I put a lot of time and effort into this community 138 | 139 | **Super Community Persona - Super User** 140 | 141 | Super users are the people who perform great in your community. We don't want super users to do advocacy for free stuff. 142 | 143 | * **Identity** – the mechanisms for how we are able to display, share and take pride in the accomplishment of becoming a super user 144 | * **Privileges** – the set of technical capabilities, access to, and engagement with the company, and opportunities to have their leadership sanctioned 145 | * **Tangibles** – the “goods,” whether physical items, account credits, or invitations to special events 146 | 147 | There are no lifetime memberships. Each member has to be reconsidered on a set time frame, no matter how good their contributions may be. This allows you to roll in new blood and remove inactive members. It also allows members who have stopped participating due to life circumstances a chance to step back and save face. 148 | 149 | **Community Member Journey** 150 | 151 | The journey of community member maturity: 152 | 153 | Aware -> Engaged -> Achieved 154 | 155 | **Measurements** 156 | 157 | * Number of members Aware 158 | * Number of members Engaged 159 | * Number of members moving from Aware to Engaged 160 | * Number of members Achieved 161 | * Number of members moving from Engaged to Achieved 162 | 163 | ### DeveloperCommunityPortals 164 | 165 | **Developer Portals Elements** 166 | 167 | ![](/Developer-Community/Assets/DeveloperPortalElements.png) 168 | 169 | When migrating a developer community to a new platform: 170 | 171 | * **Phase 1** - get your team and top 1% active community members to populate with content 172 | * **Phase 2** - invite all active members to participate in "beta" of new community 173 | * **Phase 3** - invite everyone else 174 | 175 | ### DeveloperPrograms 176 | 177 | Here are some notes on crafting successful developer programs. The core idea to remember is that your programs should be crafted with the purpose of leading the developer through this journey, measuring each step to determine where developers are getting stuck. 178 | 179 | ### Notes 180 | 181 | * People will follow when you're being your authentic self 182 | * Developers are not only in US and Europe 183 | * Always stay bi-directional: care about your developers but also your internal team 184 | * Before collecting data, build trust 185 | * Developers want to hear from each other 186 | * It takes time to get developers to love you. It requires trust building, living by their values, thinking and speaking like them. Do it for a long enough time so that they understand you are one of them 187 | * Be as personal as possible, try not to communicate toward everyone 188 | * Know your audience 189 | * Changes in community behaviour takes time (months, years) 190 | * Understand community members at personal level 191 | * As a Community Manager your job is to build up the community, not yourself. You succeed if and only if the community succeeds 192 | * Guiding a community is stressful work. You have to hold yourself to the highest of standards while everyone else gets to be human 193 | * Deleting content is generally safer than editing it 194 | * Make sure everything you send developers in mail, makes their life better 195 | * If you don't know an answer to a question in your FAQ, just say that 196 | * Successful communities explicitly define what the expectations are towards each member. If every member knows what is expected, they can contribute accordingly (or choose not to) 197 | * It's better to overcommunicate 198 | * Make your community indispensable to your organization 199 | * Make the community indispensable to your members 200 | * You shouldn’t forget your existing members. You need to ensure that they are still experiencing the value they were promised 201 | * We should always be optimizing for developer joy 202 | * Connect with your audience: 203 | * Get personal (empathy) 204 | * Stay on target 205 | * Be reachable 206 | * Pay huge attention to onboarding processes 207 | -------------------------------------------------------------------------------- /Developer-Evangelism/Assets/HackathonMarketingTasks.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Evangelism/Assets/HackathonMarketingTasks.jpg -------------------------------------------------------------------------------- /Developer-Evangelism/Assets/HackathonSocialMediaAccounts.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Evangelism/Assets/HackathonSocialMediaAccounts.jpg -------------------------------------------------------------------------------- /Developer-Evangelism/DeveloperEvangelismLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Evangelism/DeveloperEvangelismLogo.png -------------------------------------------------------------------------------- /Developer-Evangelism/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Developer Evangelism

7 |
8 |
9 |

10 | 11 |

12 | 13 | ## Table of Contents 14 | 15 | * [Intro](#intro)
16 | * [Core](#core)
17 | * [Events](#events)
18 | 19 | ### Intro 20 | 21 | **Developer Evangelism** can be split into: 22 | 23 | * Public Speaking 24 | * Social Media 25 | * Conferences & Hackathons 26 | * Blog Writing 27 | * Demos & Quickstarts 28 | * Events Sponsorship 29 | 30 | .. also covering failures of product. 31 | 32 | Being a Developer Evangelist if something new comes out of your company that should get out to developers, take it and access it like an outside developer would. Develop something with it, then document what you have developed and then start writing how you build the thing 33 | 34 | ### Core 35 | 36 | If you are / will be a Developer Evangelist then you can think of your mission and tasks in general this way: 37 | 38 | * **Build bridges** 39 | * Connect people 40 | * Connect businesses 41 | * Connect groups 42 | * Help people get jobs 43 | * Help find resources 44 | 45 | You are the **BRIDGE BUILDER** between **YOUR COMPANY** and **DEVELOPERS USING YOUR COMPANY PRODUCT**!!! 46 | 47 | ### Events 48 | 49 | Being a Developer Evangelist a huge part of your life will be events: conferences, meetups, online meetups, hackathons etc. 50 | 51 | **Hackathons** 52 | 53 | One can define a few goals that hackathon organisers are aiming for when organising hackathons. Here are some of the goals of external hackathons: 54 | 55 | * R&D 56 | * Community Building 57 | * Feedback 58 | * Driving adoption 59 | * Recruitment 60 | * Support Sales 61 | * Skills Increase 62 | 63 | On the other hand your in-house Devrel Evangelists can organise internal hackathons for your company and their goals could be: 64 | 65 | * Improve morale 66 | * Encourage cross-team collaboration to better understand the product 67 | * Identify weaknesses in your current workflow 68 | * Build and strengthen relationships among employees 69 | * Create an opportunity for individuals to test, create and share new ideas 70 | 71 | There are also other core things to remember: 72 | 73 | * Engagement with hackers after the event is super crucial in terms of your future events, especially when there are not many hackathons on the horizon 74 | * Great customer service for your partners - acknowledgments and detailed reports about the event. The more detailed the better! 75 | * Guidelines and booklets for your sponsors and partners before the event, regarding social media, promotion, the event are super useful for both you and your partners to keep consistency of your brand but also avoid fuckups! 76 | * Team build - marking people with colorful stickers depending on their skills, nice idea, isn't it? 77 | * Not revealing what prizes are and less or lack of travel reimbursments - competition is not what hackathons are about. Travel reimbursments - are you sure that you will get people who really care? 78 | * Diversity and inclusion at your hackathons start with organizers! 79 | * Arranging space - think of various adventures that you want to provide your hacker with (hacker journey during event) 80 | 81 | A huge part of the hackathon experience both pre and during the event is marketing and the social media part. 82 | 83 | **Hackathon Marketing Tasks** 84 | 85 | ![](/Developer-Evangelism/Assets/HackathonMarketingTasks.jpg) 86 | 87 | **Hackathon Social Media Handling Example** 88 | 89 | ![](/Developer-Evangelism/Assets/HackathonMarketingTasks.jpg) 90 | -------------------------------------------------------------------------------- /Developer-Experience/Assets/APIPhilosophy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Experience/Assets/APIPhilosophy.png -------------------------------------------------------------------------------- /Developer-Experience/DeveloperExperienceLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Developer-Experience/DeveloperExperienceLogo.png -------------------------------------------------------------------------------- /Developer-Experience/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Developer Experience

7 |
8 |
9 |

10 | 11 |

12 | 13 | One of the chief concerns in software design and development is to create an intuitive developer experience. However, developers often forget that they actually have two sets of users to consider: the end-user consuming the product, and the other developers using and working on the code itself. Developers know how stuff works. Developer experience has evolved so much through the years that now it can take up to even half a day to setup dev environment while some time ago you opened notepad and you started working. Before you start diving into this document, I want to leave you with one thought: 14 | 15 | **You can't assume that developers know what they want to do!** 16 | 17 | ## Table of Contents 18 | 19 | * [Intro](#intro)
20 | * [DeveloperJourney](#developerJourney)
21 | * [DevexPrinciples](#devexPrinciples)
22 | * [API](#api)
23 | * [Docs](#docs)
24 | * [OpenSource](#openSource)
25 | * [Notes](#notes)
26 | 27 | ### Intro 28 | 29 | Working as a Developer Experience Designer / Engineers or leading such people, there are a few key elements and concepts worth remembering. The core thing is using software engineering the way that allows you to **onboard and keep developers happy** while they implement something using your stack. When they use your APIs / SDKs / frameworks and tools, they need to see via different methods that you **put effort in developing those tools**. That will show them **engagement, energy and empathy** you put into that tooling. It's always nice to code something that will **bring your developers** some kind of **surprise**! This way you'll be able to both acquire them and also activate their powers by using your tools. 30 | 31 | ### DeveloperJourney 32 | 33 | Another thing worth diving in is developer journey. A developer journey is the route between a developer with no knowledge of a technology and the same developer that feels confident to use it in production and actively share the expertise acquired. 34 | 35 | **Developer Journey Stages** 36 | 37 | * Exploration (Connect): **Do I want to use it?** 38 | * Getting started (Engage): **How do I sign up and get started?** 39 | * Guidance (Adopt): **How do I use it?** 40 | * Reference (Advocate) **How do I get help?** 41 | 42 | **Developers right now spend too much time on the tooling and workflows compared to the time they spend on software development** 43 | 44 | ### DevExPrinciples 45 | 46 | **The Gold Ratio** 47 | 48 | Developer experience is not always about easy implementation. It's about ratio: 49 | 50 | * **Low**: Fewer steps in tutorial, but didn't learn anything useful 51 | * **High**: more steps, but accomplished more goals that otherwise possible 52 | * **High**: Spend little time and everythign worked! 53 | * **Zero**: Spent a lot of time but nothing worked 54 | 55 | **Information Architecture** 56 | 57 | You should always be thinking as a Developer Experience Engineer about information architecture. Whether it's a design of your API, SDK, repo or API documentation. It should be easy to navigate and intuitive to follow. Always think who you're designing for to make the entry level appropriate. No matter how great your SDK is if you don't have proper information architecture in place, developers won't use it. 58 | 59 | Another important thing in that field is information sharing. To be more specific - updates sharing. 60 | 61 | Types of changes important for notifying developers: 62 | 63 | * New big product launches (**the least important**) 64 | * Additional features & updates (**medium important**) 65 | * Deprecations (**most important**) 66 | 67 | Always ask yourself those questions about changes: 68 | 69 | * How many users does this impact? 70 | * Will this require them to do additional work? 71 | * Will this break anything? 72 | 73 | **Core DX Principles** 74 | 75 | Here are some core principles of great developer experience: 76 | 77 | * SDKs for many languages 78 | * Dynamic and personalised docs 79 | * Useful design and error codes and messages 80 | * Reliability, transparency and support 81 | * Backwards compatible API updates 82 | * Aligned incentives with developers 83 | * Quality of assets and processes available to developers 84 | * Learning should be incremental 85 | * Treat workarounds as bugs 86 | * "Magic" is frustrating 87 | 88 | **Measurements** 89 | 90 | * Check how many of these a developer needs to do to accomplish a goal: 91 | * Unrelated tasks 92 | * Required prerequisites 93 | * Steps 94 | * Snippets copied 95 | * Google searches 96 | * Docs 97 | * CLI commands 98 | * Clicks 99 | * Context switches 100 | * Mistakes 101 | * Wasted efforts 102 | * Decisions 103 | 104 | ### API 105 | 106 | ![](/Developer-Experience/Assets/APIPhilosophy.png) 107 | 108 | The core principle here is to design the API so that it allows programmers to use it in the following way: 109 | 110 | * Use **correctly** 111 | * Use **efficiently** 112 | * Use **pleasantly** 113 | 114 | One of the concepts worth understanding and having in mind when designing APIs with proper Developer Experience is: 115 | 116 | **3:30:3 rule** 117 | 118 | * 3 seconds to understand the purpose of the API 119 | * 30 seconds to identify the entry point 120 | * 3 minutes to create an account and call the system 121 | 122 | APIs are primary interfaces your developers interact with so treat their design as a function. Remember that first impressions stick and your design amplifies your message. On the other hand you should be aware of bad practices too: 123 | 124 | * Poor documentation 125 | * Inadequate support 126 | * Assume if you build it they will come 127 | * Poor developer experience 128 | * Unexpected & undocumented releases 129 | * Security complexity 130 | * Exposing your raw underlying data model 131 | * REST APIs that ignore HTTP rules 132 | * Poor error handling (error messages should be humble, human and helpful) 133 | 134 | You won't remember about each of those for sure, that's why Developer Betas are a powerful tool for building trust. 135 | 136 | ### Docs 137 | 138 | Documentation sets the tone for your product's Developer Experience. There are a few documentation types that can be mentioned: 139 | 140 | * Overview and value proposition 141 | * First-use example 142 | * Tutorials and examples 143 | * Conceptual documentation 144 | * Reference documentation 145 | * Other informal documentation 146 | 147 | In order to make those as useful as possible it's important to remember about Docs Navigation that can include following elements: 148 | 149 | * Group topics in product sidebars 150 | * Navigate from doc se to doc set 151 | * Allow navigation within content 152 | * Make popular topics easy to access 153 | * Reduce information fragmentation 154 | 155 | This way docs would be both **precursory** and **participatory** and its content will be up to date, exemplary and consistent. Also check out those general tips regarding designing docs: 156 | 157 | * Show people path to expertise instead of making them experts 158 | * Documentation is a part of the product, not a byproduct of the code 159 | * Good documentation system will make it easy to pivot (internal) 160 | 161 | **Begin documenting before you even begin developing** 162 | 163 | ### OpenSource 164 | 165 | Sooner or later taking care of developer experience at your company you'll either need to check out trends in Open Source or even develop something OSS within your company. Here are some key therms in the field: 166 | 167 | * **Author**: The person/s or organisation that created the project 168 | * **Owner**: The person/s who has administrative ownership over the organisation or repository (not always the same as the original author) 169 | * **Maintainers**: Contributors who are responsible for driving the vision and managing the organisational aspects of the project. They may also be authors or owners of the project 170 | * **Contributors**: Everyone who has contributed something back to the project. 171 | * **Community Members**: People who use the project. They might be active in conversations or express their opinion on the project’s direction. 172 | * **OSPO - Open Source Programs Office**: Establishes policies, process, tools and culture change around open source engagement. Someone or a team who are advocating for open source. 173 | 174 | When it comes to open source projects, documentation is hugely important. No matter which stage you decide to open source your project, every project should include the following documentation: 175 | 176 | * **LICENSE**: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source. 177 | * **README**: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. 178 | * **CONTRIBUTING**: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. 179 | * **CODE_OF_CONDUCT**: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. 180 | * **Other documentation**: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. 181 | 182 | **Other important thing in OSS Development is motivation.** Extrinsic motivators are great at getting people first exposure, but not for creating long term OSS contributors. The best way you can incentivise long term contributions is through providing either valuable learning opportunities, or career opportunities. Here are some OSS Motivations: 183 | 184 | * Improving coding skills 185 | * Being a part of community 186 | * Learning new technologies 187 | * Advancing careers 188 | * Advancing software freedom 189 | * Developing new products 190 | * Improving technologies required for job 191 | 192 | Knowing all this you'll want to be a good OSS Developer Experience engineer for sure, right? That's why you need to make the community that will be using your tools very welcoming: 193 | 194 | * Make it easy for someone to use your project 195 | * Clearly explain how to contribute 196 | * When someone new lands on your project, thank them for their interest! 197 | * Be responsive 198 | * Be open-minded about the types of contributions you’ll accept 199 | * Treat your README as a constitution 200 | 201 | Having those tips in mind will allow you to get rid of or even prevent some common OSS blockers and problems like: 202 | 203 | * It seems difficult to get started / I don't know where to start 204 | * I feel like I don't have the right skills to contribute 205 | * My company doesn't give me time to contribute 206 | * I am too intimidated to contribute 207 | * Lack of resources 208 | * Lack of interest 209 | * Unresponsiveness 210 | * Dismissive responses 211 | * Unexplained rejection 212 | * Unwelcoming language or content 213 | 214 | **Open Source Strategy** 215 | 216 | Creating and documenting an open source strategy is an essential first step to realising ROI with open source. Crafting a strategy document will help your team understand the business objectives behind your open-source program. 217 | 218 | * Start with the end goal first and then explain how to get there 219 | * Explain your company's approach to open-source and the purpose behind the document. 220 | * Specify how you want developers to consume open source code 221 | * Specify how you want developers to contribute to open source projects and identify projects that are critical to your business strategy 222 | 223 | **Company Open Source Pipeline** 224 | 225 | Let's assume you have something built and you want to open source it. Here's an example pipeline: 226 | 227 | * **Legal Review** 228 | * Consider the impact of open sourcing on your company’s intellectual property 229 | * Ensure full compliance with open source licenses 230 | * Select an open source license for the source code to be released, document all licensing requirements very clearly in your project 231 | * Decide if you need a contributor agreement 232 | * Consider the possible non-software outputs from the community and the appropriate licenses, such as documentation and specifications 233 | * Decide on any trademark related considerations 234 | * Decide whether there are additional factors to build into your plans for an ecosystem, such as conformance testing 235 | 236 | * **Technical Review** 237 | * Remove critical dependencies on non-public components 238 | * Provide documentation and use case examples 239 | * Remove internal comments, references to other internal code, etc. 240 | * Ensure coding style is consistent 241 | * Update copyright notices in source code files 242 | * Add license notice in source code file 243 | * Add license text as a file in the root directory 244 | 245 | * **Governance and Processes** 246 | * Define project governance steps and structure 247 | * Set up a code repository, bug reporting, and code testing infrastructure 248 | * Create supporting Slack channels, forums, and Wikis 249 | * Create open lines of communication with contributors for project success 250 | 251 | * **Branding and Marketing** 252 | * Set marketing strategy to promote an active contributor community 253 | * Design project logo, color scheme, website, collateral, etc. 254 | * Formalize branding guidelines 255 | * Register social media accounts for the project (Twitter, Facebook, LinkedIn, etc.) 256 | * Register domain names for the project 257 | 258 | * **Launch and Maintain** 259 | * Open project and begin development work and contributions process 260 | * Designate a community manager or community advocate 261 | * Ensure any changes to direction or governance are clearly communicated 262 | * Follow best practices of other similar communities 263 | * Encourage and provide opportunities for face-to-face community building 264 | 265 | * **End Project** 266 | * Whatever you do to end or transfer an open source project, perhaps the most important move you can make is to be candid with users at every step. Being open about your intentions helps establish trust for future work with all potential developer communities. 267 | * It’s important to always remember that just because your company doesn’t care about the code anymore it doesn’t mean that the existing community doesn’t care. 268 | * If your enterprise transfers the project to another group, the users should be kept up to date on what is being done to protect their interests as well. 269 | * Be sure to openly advise developers and community members about the status of the project with its new operators and give them clear details about how the project is now being maintained if they care to continue to use it. 270 | * Don’t forget to update your project website, social media channels, and other connected community assets so participants know where to find the moved project and can continue to make their contributions and use the code. 271 | * Remember to communicate all this information to downstream organizations and users as well. This includes companies, non-profits, and others that are using your code, and who may not be aware of the demise or transfer of the project because they’re not directly involved in the development cycle. You should make efforts to advise them of what is happening through your websites, social media channels, and other outlets, especially if the project is well-known and has had a substantial following. 272 | 273 | **Some loose OSS Notes** 274 | 275 | * When something is cheaper, more people buy it. That’s why open-source companies have such massive and rapid adoption when they achieve product-market fit. 276 | * Open source is the default when choosing software 277 | * Many organizations are getting involved in open source with the express purpose of attracting developers 278 | * No contribution is too big or too small 279 | * Younger developers contribute more to open source - to learn and have fun 280 | 281 | ### Notes 282 | 283 | * Most of the users uninstall the app if they notice freeze, crash or an error 284 | * Developers tend to stick to using IDEs rather than lightweight desktop editors 285 | * Developers spend almost 50% of their time on legacy code 286 | * Great experience lead to great engagement 287 | * Developer experience has become more complex since developers are using tools to do multiple things rather than a single thing 288 | * We should always be optimising for developer joy 289 | * Help users get started quickly 290 | * A good developer experience is making it so a developer will succeed with intuitive decisions rather than informed decisions 291 | * Basically everyone, but developers especially, hates the feeling that they are being sold something 292 | * C-level people at companies now worry about access to developers more than they worry about access to capital 293 | * It's a huge priority for upper management to increase the productivity of its developers 294 | * Think of developer experience as a buying process funnel (check till which step your developers succeed) 295 | * A developer can get really involved with a project, the rewards being seeing their changes applied, and their name listed in the change log history 296 | * Do not tell people that something with your stack is not advisable, provide preventic solutions and error handling 297 | * You cannot provide your developers with parts of the solution (developer mindset - they want to know all) 298 | * Developer won't use tools that they don't trust 299 | -------------------------------------------------------------------------------- /Devrel-Management/Assets/AAARRRPModel.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Devrel-Management/Assets/AAARRRPModel.jpg -------------------------------------------------------------------------------- /Devrel-Management/Assets/DevrelFields.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Devrel-Management/Assets/DevrelFields.png -------------------------------------------------------------------------------- /Devrel-Management/Assets/DevrelFieldsTwo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Devrel-Management/Assets/DevrelFieldsTwo.png -------------------------------------------------------------------------------- /Devrel-Management/DevrelManagementLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Devrel-Management/DevrelManagementLogo.png -------------------------------------------------------------------------------- /Devrel-Management/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Devrel Product Management

7 | Turning concepts into actions and sharing knowledge note features! 8 |
9 |
10 |

11 | 12 |

13 | 14 | ## Table of Content 15 | 16 | * [General](#general)
17 | * [DevrelManager](#devrelManager)
18 | * [BusinessModels](#businessModels)
19 | * [KPIs](#kpis)
20 | 21 | ### General 22 | 23 | In this section, there will be a few concepts, models and smaller thing presented that we considered meaningful, from the perspective of DevReal Team manager or even DevRel org head. Others not working on managerial positions should also find it helpful in order to understand over-arching goals of the whole DevRel structure in their company. 24 | 25 | The first thing is **AAARRRP Model** by [Phil Legetter](https://twitter.com/leggetter) 26 | 27 | ![](/Devrel-Management/Assets/AAARRRPModel.jpg) 28 | 29 | The other one is **DevRel Pillars 3 C's Model**, which consists of three key elements 30 | 31 | * Code 32 | * Content 33 | * Community 34 | 35 | Next one is understanding DevRel and its fields as a whole but also split into smaller fields. Those two assets by [hoopy.io](https://hoopy.io/) should make it all clear. 36 | 37 | ![](/Devrel-Management/Assets/DevrelFields.png) 38 | 39 | ![](/Devrel-Management/Assets/DevrelFieldsTwo.png) 40 | 41 | ### DevrelManager 42 | 43 | If you want to become a successful Devrel team / org , Developer Product Manager try to incorporate those thoughts: 44 | 45 | * There should be a right balance between KPIs / dashboards and interacting and listening to developers 46 | * Make users better at what they want to do not thinking what you want them to do 47 | * Developers don't have much time 48 | * Upgrade your users not your product 49 | * They want to hack your product to their usecases 50 | * There is no point trying to fix something that your organisation doesn't want to fix 51 | * Public Roadmaps - by sharing in advance what you’re planning with your users, you can help them make much smarter long-term decisions 52 | * Take a look at customer requests, and analyse them carefully. You want to distinguish between what customers ask for, and what they actually need 53 | 54 | Apart from all that do not forget about constant growth, crafting and executing a vision and above all empowering your team! 55 | 56 | ### BusinessModels 57 | 58 | Based on Hoopy.io State of Devrel Report organizations that practice DevRel fall into two business models: 59 | 60 | * **Developer First**: the primary business model of the company is B2D (Business to Developer). For example, Stripe and Twilio. 61 | * **Developer Plus**: a company's primary business model is B2B or B2C, but a developer play, extends or supports the primary business model. For example: Slack, Spotify, Apple. 62 | 63 | ### KPIs 64 | 65 | This applies to pretty much everyone, not only managers. If you don't measure your efforts and performance you don't know if you make progress. Without a quantifiable sense of where you are vs. where you were, you can’t know (in any meaningful way) whether you’ve succeeded or not. 66 | 67 | * **Developer Community KPIs** 68 | * Pageviews 69 | * User visits 70 | * Likes 71 | * Signups 72 | * Topics created 73 | * Posts created 74 | * Followers / Members 75 | * Engagement (discussions / comments / shares / retweets / re-posts) 76 | * Referral traffic from your community 77 | * Number of new signups and discussions 78 | * Active members 79 | * Questions asked vs Questions answered 80 | * What % of questions got answered? 81 | * Is traffic to your community going up or down? 82 | * What percentage of visitors register? 83 | * What percentage of registered members participate? 84 | * What percentage of those that participate are still active in 3 months time? 85 | * What is the average number of contributions per month your top 1%, 9%, and 90% of members make? 86 | * Total numbers of new topics 87 | * Number of participating numbers 88 | * Number of members who visit each month 89 | * Number of new users per month 90 | * Number of posts per month 91 | * Number of topics marked as solved 92 | * % of active vs passive users 93 | * Average number of posts per member 94 | * Number of members who upgraded to paying accounts 95 | * Number who joined 6 months ago and are still active 96 | 97 | * **Developer Experience Metrics** 98 | * **Quality**: Net Promoter Score 99 | * **Quantity**: Program Members 100 | * **Activity**: User Engagements 101 | * How many developers are completing the trial and stay for more? 102 | 103 | * **GitHub Repos Health Metrics** 104 | * **Contributor-Breadth**: the ratio of non-core committers to core committers. This metric indicates how open a community is to contributions from outside 105 | * **Contributor-Demographics**: gender, age, location, education, and skills over time 106 | * **Contributors**: number of contributors 107 | * **Issue-Response-Rate**: time between a new issue is opened and a maintainer responds 108 | * **Followers**: number of followers 109 | * **Forks**: number of forks 110 | * **Bus-Factor**: the minimum number of developers performing 50% of commits 111 | * **Closed-issues**: number of close issues 112 | * **Code-Commits**: number of code commits 113 | * **Transparency**: number of comments per issue 114 | * **Watchers**: number of watchers 115 | * **Issue-Resolution-Efficiency**: number of closed issues / number of abandoned issue 116 | * **Issues-Submitted-Closed**: issues submitted vs issues closed 117 | * **Code-Merge-Duration**: what's the duration of time between code merge request and code commit 118 | * **CommunityActivity**: frequency of contributions 119 | * **IssueComments**: number of comments per issue 120 | * **NewContributors**: number of new contributors over time 121 | * **OpenIssueAge**: age of an open issue 122 | * **OpenIssues**: number of open issues 123 | * **PRsComments**: number of comments per pull request 124 | * **PRsMadeClosed**: pull request made vs pull requests closed 125 | * **PRsOpen**: number of opened pull requests 126 | * **PRsOverTime**: how many pull requests have been submitted over time 127 | * **NewContributorsMaintainers**: ratio of new contributors to maintainers 128 | 129 | * **General Metrics** 130 | * Content Created 131 | * Signups 132 | * API Calls -> Revenue 133 | * Social Media Numbers 134 | * NPS 135 | * Stack Overflow Activity 136 | 137 | Remember that the number itself isn’t the goal — it’s the process of tracking them over time and finding patterns in the data that can inform project and process improvements. Not everything you can measure, should be measured. Don’t be a data puker, be a data analyst. Be laser focused on the things that matter & provide actionable insights 138 | -------------------------------------------------------------------------------- /DevrelNotebookLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/DevrelNotebookLogo.png -------------------------------------------------------------------------------- /ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Issue Report 2 | 3 | If you are reporting an issue, please fill the sections below. Thank you! 4 | 5 | ## Description 6 | 7 | Please provide a brief summary of the issue you report. 8 | 9 | ## Expected behaviour 10 | 11 | Please tell us what you think should happen. 12 | 13 | ## Actual behaviour 14 | 15 | Please tell us what actually happens. 16 | 17 | ## Steps to reproduce the problem 18 | 19 | Please tell us what we should do to reproduce the issue. 20 | 21 | ## Screenshots 22 | 23 | Feel free to insert here any screenshots that you consider helpful in solving your issue. 24 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 Devrel Space 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this repository content and associated documentation files (the "Repository Content"), to deal 7 | in the Repository Content without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense. 9 | 10 | The above copyright notice and this permission notice shall be included in all 11 | copies or substantial portions of the Repository Content. 12 | 13 | THE REPOSITORY CONTENT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 14 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 15 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 16 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 17 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 18 | OUT OF OR IN CONNECTION WITH THE REPOSITORY CONTENT OR THE USE OR OTHER DEALINGS IN THE 19 | REPOSITORY CONTENT. 20 | -------------------------------------------------------------------------------- /Loose-Notes/LooseNotesLogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/konradsopala/developerled-notebook/506ab6da11bf1f928844e87bb54b43b2f61fe167/Loose-Notes/LooseNotesLogo.png -------------------------------------------------------------------------------- /Loose-Notes/README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Loose DevRel Notes

7 |
8 |
9 |

10 | 11 |

12 | 13 | ## Notes 14 | 15 | You can find here all the loose notes that we've written down during DevRel field research, making notes and pretty much creating this repo. Hope they'll be somewhat useful in your present and future DevRel endeavours! 🖖 16 | 17 | * When you're asked about ROI and you think it's shit just don't come up with some number (**it's about trust**) 18 | * Not everything of value can be measured 19 | * When making products we should think about them that what we deliver is finished even when delivery is incremental 20 | * If you’re a great external communicator but you can’t get anything shipped for developers because you have no credibility with the product team - you aren’t becoming more senior in the organisation 21 | 22 | --------------------------------------------------------------------------- 23 | 24 | * When you're traveling it can be hard to work out every day 25 | * Ensure a workout happens just about every day you're not on the road 26 | * Devrel job is a very flexible one so you need to make extra effort to make it more static 27 | * Do not stay in front of the computer for more than 8 hours a day 28 | 29 | --------------------------------------------------------------------------- 30 | 31 | * Fly less, write more 32 | * You need an event strategy and plan to execute (so as not to waste your attendance at the event) 33 | * If you're attending conferences network, if you're on behalf of your company then collect developers feedback 34 | * If you're travelling for a conference always go for your health (even if they have talks that are interesting for you, choose the flight that allows you to get back home earlier and rest) 35 | 36 | --------------------------------------------------------------------------- 37 | -------------------------------------------------------------------------------- /PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | # Pull Request 2 | 3 | This repo holds a lot of information in a form of notes. Those notes were taken reading / listening or watching various resources and may lack original authors of the thoughts. Feel free to suggest any changes whether it's about authors and credits or any Markdown changes that you feel are appropriate. Please include a summary of the change you are making. Please also include relevant motivation and context. 4 | 5 | ## Type of change 6 | 7 | Please mark the correct option 8 | 9 | - [ ] Credits / authors change 10 | - [ ] Merit Knowledge Change 11 | - [ ] New feature (non-breaking markdown change which adds functionality) 12 | - [ ] Breaking markdown change (fix or feature that would cause existing functionality to not work as expected) 13 | 14 | ## Checklist: 15 | 16 | - [ ] I have performed a self-review of my own markdown code 17 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | 5 |
6 |

Devrel Notebook

7 | Your core knowledge to doing solid DevRel! 8 |
9 |
10 |

11 | 12 |

13 | 14 | **Hey there Devrel Friends!** 15 | 16 | **Devrel Notebook** is a repo that holds a lot of information in a form of notes and you should treat it as a gathering of extremely usefulf information from various sources.. **DISCLAIMER**: Those notes were taken playing with different SDKs, APIS, docs, reading / listening or watching different things and may lack original authors of the thoughts. We're open for pull requests to add those! Happy learning! 17 | 18 | In this repo you will be able to gain knowledge about various fields of the Developer Relations umbrella like: 19 | 20 | * [Developer Community](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Developer-Community)
21 | * [Developer Experience](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Developer-Experience)
22 | * [Developer Advocacy](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Developer-Advocacy)
23 | * [Developer Evangelism](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Developer-Evangelism)
24 | * [Devrel Management](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Devrel-Management)
25 | 26 | but also read some more or less [loose notes](https://github.com/DevrelSpace/Devrel-Notebook/tree/master/Loose-Notes). Let us walk you into the Developer Relations world! 27 | 28 | **Developer Relations** is about building trust at scale. Although charisma can be faked, DevRel requires genuine enthusiasm for your platform or product, so let's start learning! 29 | 30 | **Developer Relations is about**: 31 | 32 | * Outreach (online and in person) 33 | * Community 34 | * Product 35 | * Education and support 36 | 37 | **Developer Relations Funnel** 38 | 39 | In order to be able to do solid DevRel, you need to fulfill certain needs of your developer audience that can be divided into folllowing categories: 40 | 41 | * Basic Needs 42 | * Psychological Needs 43 | * Self-fulfillment 44 | 45 | **Have that in the back of your head: Developer Relations is hard to measure, subjective and time-intensive** 46 | -------------------------------------------------------------------------------- /Sample-Reports/EventConferenceReport.md: -------------------------------------------------------------------------------- 1 | # Sample Event / Conference Report 2 | 3 | * **Name of event**: 4 | * **Event Social Media Handle**: 5 | * **Date**: 6 | * **Location**: 7 | * **Why you attended**: 8 | * A quick summary of why this event was important for you 9 | * **General observations / themes**: 10 | * Why are those themes / observations important to the company? 11 | * How do these observations line up with what we're seeing elsewhere? 12 | * What follow-up questions should we ask ourselves or others from the conference / internally from the company? 13 | * **Event specifics**: 14 | * What were some of the popular sessions you enjoyed and why? 15 | * Would you recommend this conference to somebody else from the team and why? 16 | * **People / companies**: 17 | * Is there anyone from the conference you can think of that we can reach out to in order to spark some cross-companies collaboration? --------------------------------------------------------------------------------