6 ms·

Speaking with my personal hat, not as Developer Evangelist at GitLab. I've joined my first OSS project in 2009 (left in 2020), and I have to admit - communicat

Speaking with my personal hat, not as Developer Evangelist at GitLab. I've joined my first OSS project in 2009 (left in 2020), and I have to admit - communication can be challenging. There are many best practices, little are documented, and projects and companies differ in their workflows. Here are few things I would encourage to do, or ensure to have in the very beginning: - Be transparent in all your decisions. Discuss in the open, record meetings for the public, share the meeting notes with everyone. If the project reaches a level where everything is discussed behind closed doors, and the only community updates are marketing blog posts and AMA threads ... that's a warning signal to lose your community. - Provide a handbook or documentation for all workflows. How to contribute, which direction/roadmap (in text form, not as a Git* issue board). Avoid so-called "product conferences" where you announce your roadmap. Instead, be open and have milestones to follow and discuss. - Community members should _never_ be treated as "you can submit a patch, but don't bug me further". Assume positive intent, and get feedback from problem reports. - Do not moderate or manage a community. Help seed the knowledge, and share trust with creating a governance structure (core team, community advisors, etc.). _Never_ silently remove granted permissions, losing trust. (that happened to me in 2020, I then made the decision to leave the OSS project Icinga after 11 years) - Establish a sense of belonging, share praise and encourage to contribute. Handle code of conduct violations with care, ensuring everyone feels safe. - Transfer knowledge in issue description, debug stories, reviews and encourage contributors to learn and follow. Coach and mentor fellow and future contributors. Take the time to thank everyone for their contributions. - Evaluate roles. A founder or backend developer as community builder may work in the beginning. Plan to hire additional resources who can lead the conversation, and involve teams when necessary. Encourage to learn new technologies and stay in the loop. - Document everything on the way, lessons learned, changes, what worked, what did not. Do retrospectives when announcements did not work the way you intended. Verify the defined actions. - Find evangelists/advocates in your company and community, give them visibility and push them in all collaborations. Ask friends who love social media, get the technical content writer champion, and give everyone a chance to learn and grow. Don't expect to hire experts. Instead, focus on existing DevRel communities and exchange knowledge and experiences within the community. - When you grow, do not hide as a leader. Be approachable with your team, and engage with your community. Coffee chats, meetups, etc. - follow the thought: Everyone can contribute. There's more to that, I've only shared a few quick thoughts now. Happy to chat more :) If you want to dive into the topic even more - I've shared my 10 years in OSS community story and all things learned in a talk at the Open Source at Siemens event in 2021. Slides: https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5WXA4mvcYQd9fdtvHicf-JyU/edit https://docs.google.com/presentation/d/1HnciJEQ8dDiHMaq1APg5... Recording: https://www.youtube.com/watch?v=yT63olXdS-I https://www.youtube.com/watch?v=yT63olXdS-I

andreacavagna 5y ago
At the moment I'm struggling with my founder role and accountabilities inside the project. I've switched from a DevOps position to become the Product Owner, managing the delivery of the open-source project and the day to day work, but now I see lack of time in developing a real evangelism and DevRel things inside the Leapp project. I'm completely aware that this is THE crucial part of an open-source project and I really love OSS because of the contributing from all around the world. But is turning that maintain and grow a community around the project, make the project well known, is a full time job for a founder of a project. I still don't know if I have the right skill for that kind of job and where a such particular job can bring me in the future, together with the Noovolari company. BTW, this is my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) and I would love to chat more with you!
- dnsmichi 5y ago
  Thanks for the additional context, helps to understand your situation and resources. > BTW, this is my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) Looks great. A few suggestions for the first impression opening the project: - Switch to dark mode and verify that the images work in the README and other docs. There is a logo which cannot be seen on the site, it's dark and black. - Focus on telling the "problem to solve" and "why" in the introduction https://github.com/Noovolari/leapp#leapp https://github.com/Noovolari/leapp#leapp I initially did not understand the term "cloud access app" - The screenshot description is AWS focussed. https://user-images.githubusercontent.com/9497292/114399348-1e942f80-9ba1-11eb-8b4a-74b60bd29189.jpeg https://user-images.githubusercontent.com/9497292/114399348-... If you don't know AWS specifics, it is hard to understand. Think of a more high level catchy architecture overview, or working example. Catch your marketing term with "multiple cloud access strategies". Maybe use a Gif to showcase the key items as done in the one in "key features" - Installation links to a release download page. https://www.leapp.cloud/releases https://www.leapp.cloud/releases Improve this, highly recommend to create documentation guides for Windows, Linux and macOS, explaining the different commands step-by-step, more tutorial alike. Actually, your website has a docs section, but it is not linked from the GH Readme. Suggest to link to https://docs.leapp.cloud/installation/install-leapp/ https://docs.leapp.cloud/installation/install-leapp/ instead of the releases page. Here's a PR to fix it: https://github.com/Noovolari/leapp/pull/215 https://github.com/Noovolari/leapp/pull/215 - You are using MkDocs for the documentation. That's amazing <3 - PR template - while fixing the readme, I was confused by the template structure. Maybe get inspired by GitLab MR (similar to PR) templates? Gary Bell wrote a great blog post about them: https://www.garybell.co.uk/merge-request-templates/ https://www.garybell.co.uk/merge-request-templates/ - You are using a DCO which requires all commits to be signed off. That's impossible with using the browser to make direct edits to the docs, or otherwise suggestions. It may throw off contributors after their first pull request (it throws me off every time I consider contributing on a mobile device). Did now on my desktop terminal: cd /tmp && git clone https://github.com/dnsmichi/leapp https://github.com/dnsmichi/leapp && cd leapp && git checkout patch-1 && git commit --amend -s && git push -f Suggestion: Document the DCO requirement more visible, e.g. with a badge in the README. - The PR fails because because of a check https://github.com/Noovolari/leapp/runs/4971776167?check_suite_focus=true https://github.com/Noovolari/leapp/runs/4971776167?check_sui... "Error: No release type found in pull request title "Update URLs to installation docs in README". Add a prefix to indicate what kind of release this pull request corresponds to (see https://www.conventionalcommits.org/ https://www.conventionalcommits.org/)." That's additional work for contributors. After fixing the DCO sign-off, the next thing to do. Then again, the commit also needs a "docs: " prefix. At this point, I would have lost the desire to contribute. - Why is the contributing.md hidden in the .github directory (https://github.com/Noovolari/leapp/blob/master/.github/CONTRIBUTING.md https://github.com/Noovolari/leapp/blob/master/.github/CONTR...) and not present in the main repository? I was specifically looking for it at the repository top level when looking to contribute. - https://github.com/Noovolari/leapp/blob/master/.github/CONTRIBUTING.md#submitting-changes https://github.com/Noovolari/leapp/blob/master/.github/CONTR... encourages you with "Please send a GitHub Pull Request to Leapp with a clear list of what you've done (read more about pull requests)." What's a clear list of changes? Suggestions in a new PR: https://github.com/Noovolari/leapp/pull/216 https://github.com/Noovolari/leapp/pull/216 - https://docs.leapp.cloud/contributing/get-involved/ https://docs.leapp.cloud/contributing/get-involved/ links from the docs to contributing.md As discovered above, contributing.md is more a "things to review" document. It should be the call-to-action document. Or maybe move the content from contributing.md entirely into your documentation - and only link there. I do the same with https://o11y.love/contributing/ https://o11y.love/contributing/ for example - Make it easy to spin up a development environment - I don't see any guides to do so? Suggestion: Add Gitpod or a local Docker build and a development.md to your repository. This will be critical for your success to attract contributors. - https://docs.leapp.cloud/contributing/project-structure/ https://docs.leapp.cloud/contributing/project-structure/ exists but is not linked in contributing.md - Labels help wanted / good first issue are used, but they are not explained/linked in the contributing guide. If you are not familiar with these label types, contributions are harder. Suggestion: Fix this by adding the Call-to-action in your contribution guides. https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22 https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3A... + https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3A... Above are my first impressions starting with the project and trying to find ways to contribute. I did not read the source code yet. I'd suggest addressing them, and then focus on DevRel and marketing ideas. The first impression of a project is crucial to help seed the community plants :)

andreacavagna 5y ago

At the moment I'm struggling with my founder role and accountabilities inside the project. I've switched from a DevOps position to become the Product Owner, managing the delivery of the open-source project and the day to day work, but now I see lack of time in developing a real evangelism and DevRel things inside the Leapp project. I'm completely aware that this is THE crucial part of an open-source project and I really love OSS because of the contributing from all around the world. But is turning that maintain and grow a community around the project, make the project well known, is a full time job for a founder of a project. I still don't know if I have the right skill for that kind of job and where a such particular job can bring me in the future, together with the Noovolari company. BTW, this is my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) and I would love to chat more with you!

dnsmichi 5y ago
Thanks for the additional context, helps to understand your situation and resources. > BTW, this is my project (https://github.com/Noovolari/leapp https://github.com/Noovolari/leapp) Looks great. A few suggestions for the first impression opening the project: - Switch to dark mode and verify that the images work in the README and other docs. There is a logo which cannot be seen on the site, it's dark and black. - Focus on telling the "problem to solve" and "why" in the introduction https://github.com/Noovolari/leapp#leapp https://github.com/Noovolari/leapp#leapp I initially did not understand the term "cloud access app" - The screenshot description is AWS focussed. https://user-images.githubusercontent.com/9497292/114399348-1e942f80-9ba1-11eb-8b4a-74b60bd29189.jpeg https://user-images.githubusercontent.com/9497292/114399348-... If you don't know AWS specifics, it is hard to understand. Think of a more high level catchy architecture overview, or working example. Catch your marketing term with "multiple cloud access strategies". Maybe use a Gif to showcase the key items as done in the one in "key features" - Installation links to a release download page. https://www.leapp.cloud/releases https://www.leapp.cloud/releases Improve this, highly recommend to create documentation guides for Windows, Linux and macOS, explaining the different commands step-by-step, more tutorial alike. Actually, your website has a docs section, but it is not linked from the GH Readme. Suggest to link to https://docs.leapp.cloud/installation/install-leapp/ https://docs.leapp.cloud/installation/install-leapp/ instead of the releases page. Here's a PR to fix it: https://github.com/Noovolari/leapp/pull/215 https://github.com/Noovolari/leapp/pull/215 - You are using MkDocs for the documentation. That's amazing <3 - PR template - while fixing the readme, I was confused by the template structure. Maybe get inspired by GitLab MR (similar to PR) templates? Gary Bell wrote a great blog post about them: https://www.garybell.co.uk/merge-request-templates/ https://www.garybell.co.uk/merge-request-templates/ - You are using a DCO which requires all commits to be signed off. That's impossible with using the browser to make direct edits to the docs, or otherwise suggestions. It may throw off contributors after their first pull request (it throws me off every time I consider contributing on a mobile device). Did now on my desktop terminal: cd /tmp && git clone https://github.com/dnsmichi/leapp https://github.com/dnsmichi/leapp && cd leapp && git checkout patch-1 && git commit --amend -s && git push -f Suggestion: Document the DCO requirement more visible, e.g. with a badge in the README. - The PR fails because because of a check https://github.com/Noovolari/leapp/runs/4971776167?check_suite_focus=true https://github.com/Noovolari/leapp/runs/4971776167?check_sui... "Error: No release type found in pull request title "Update URLs to installation docs in README". Add a prefix to indicate what kind of release this pull request corresponds to (see https://www.conventionalcommits.org/ https://www.conventionalcommits.org/)." That's additional work for contributors. After fixing the DCO sign-off, the next thing to do. Then again, the commit also needs a "docs: " prefix. At this point, I would have lost the desire to contribute. - Why is the contributing.md hidden in the .github directory (https://github.com/Noovolari/leapp/blob/master/.github/CONTRIBUTING.md https://github.com/Noovolari/leapp/blob/master/.github/CONTR...) and not present in the main repository? I was specifically looking for it at the repository top level when looking to contribute. - https://github.com/Noovolari/leapp/blob/master/.github/CONTRIBUTING.md#submitting-changes https://github.com/Noovolari/leapp/blob/master/.github/CONTR... encourages you with "Please send a GitHub Pull Request to Leapp with a clear list of what you've done (read more about pull requests)." What's a clear list of changes? Suggestions in a new PR: https://github.com/Noovolari/leapp/pull/216 https://github.com/Noovolari/leapp/pull/216 - https://docs.leapp.cloud/contributing/get-involved/ https://docs.leapp.cloud/contributing/get-involved/ links from the docs to contributing.md As discovered above, contributing.md is more a "things to review" document. It should be the call-to-action document. Or maybe move the content from contributing.md entirely into your documentation - and only link there. I do the same with https://o11y.love/contributing/ https://o11y.love/contributing/ for example - Make it easy to spin up a development environment - I don't see any guides to do so? Suggestion: Add Gitpod or a local Docker build and a development.md to your repository. This will be critical for your success to attract contributors. - https://docs.leapp.cloud/contributing/project-structure/ https://docs.leapp.cloud/contributing/project-structure/ exists but is not linked in contributing.md - Labels help wanted / good first issue are used, but they are not explained/linked in the contributing guide. If you are not familiar with these label types, contributions are harder. Suggestion: Fix this by adding the Call-to-action in your contribution guides. https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22 https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3A... + https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/Noovolari/leapp/issues?q=is%3Aissue+is%3A... Above are my first impressions starting with the project and trying to find ways to contribute. I did not read the source code yet. I'd suggest addressing them, and then focus on DevRel and marketing ideas. The first impression of a project is crucial to help seed the community plants :)