├── .github ├── FUNDING.yml ├── dependabot.yml ├── settings.yml ├── website │ ├── config.toml │ ├── content │ │ ├── _index.md │ │ └── menu │ │ │ └── index.md │ └── resources │ │ └── _gen │ │ └── assets │ │ └── scss │ │ └── open-source-best-practice │ │ ├── book.scss_50fc8c04e12a2f59027287995557ceff.content │ │ └── book.scss_50fc8c04e12a2f59027287995557ceff.json └── workflows │ ├── backup.yaml │ ├── generator.yaml │ └── publish.yaml ├── .gitignore ├── .gitmodules ├── LICENSE ├── Makefile ├── README-en.md ├── README.md ├── _config.yml ├── audios-and-videos.md ├── books.md ├── cs-student-open-source.md ├── data └── financing │ ├── financing.tpl │ ├── item-1.yaml │ ├── item-10.yaml │ ├── item-11.yaml │ ├── item-12.yaml │ ├── item-13.yaml │ ├── item-14.yaml │ ├── item-15.yaml │ ├── item-16.yaml │ ├── item-17.yaml │ ├── item-18.yaml │ ├── item-19.yaml │ ├── item-2.yaml │ ├── item-20.yaml │ ├── item-21.yaml │ ├── item-22.yaml │ ├── item-23.yaml │ ├── item-24.yaml │ ├── item-25.yaml │ ├── item-26.yaml │ ├── item-27.yaml │ ├── item-28.yaml │ ├── item-29-primihub.yaml │ ├── item-3.yaml │ ├── item-30-vesoft.yaml │ ├── item-31-vesoft.yaml │ ├── item-32.yaml │ ├── item-33.yaml │ ├── item-34.yaml │ ├── item-35.yaml │ ├── item-4.yaml │ ├── item-5.yaml │ ├── item-6.yaml │ ├── item-7.yaml │ ├── item-8.yaml │ └── item-9.yaml ├── encourage-community-members.md ├── encourage.md ├── english.md ├── etiquette.md ├── event.md ├── financing.md ├── good-first-issue.md ├── how-to-contribute.md ├── insist.md ├── mentor-plan.md ├── motivation.md ├── open-source-credit.md ├── open-source-write-guide.md ├── ospp.md ├── others.md ├── platforms.md ├── practice └── community-first.md ├── review.md ├── sig.md ├── what ├── community-manager.md ├── devrel.md ├── devrel.tpl ├── items │ ├── devrel-adamd.yaml │ ├── devrel-anthonyLimo.yaml │ ├── devrel-aprilspeight.yaml │ ├── devrel-arkodyuti.yaml │ ├── devrel-hasson.yaml │ ├── devrel-jennita.yaml │ ├── devrel-jono.yaml │ ├── devrel-mary_grace.yaml │ ├── devrel-matthewrevell.yaml │ ├── devrel-michael.yaml │ ├── job-4paradigm.yaml │ ├── job-aloudata.yaml │ ├── job-amazon.yaml │ ├── job-bytedance.yaml │ ├── job-chainlink.yaml │ ├── job-consensys.yaml │ ├── job-illacloud.yaml │ ├── job-injoying.yaml │ ├── job-jetbrains.yaml │ ├── job-jinaai.yaml │ ├── job-nebula-graph.yaml │ ├── job-openKylin.yaml │ ├── job-orbit.yaml │ ├── job-starrocks.yaml │ ├── job-streamnative.yaml │ ├── job-taos.yaml │ └── job-weave.yaml ├── jobs.md ├── jobs.tpl ├── tw.md └── tw.tpl ├── why └── why-open-source.md ├── workgroup.md └── workshop.md /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | custom: ['https://afdian.net/@os_best_practice'] 4 | -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: "github-actions" 4 | directory: "/" 5 | schedule: 6 | interval: "daily" 7 | pull-request-branch-name: 8 | separator: "-" 9 | -------------------------------------------------------------------------------- /.github/settings.yml: -------------------------------------------------------------------------------- 1 | # we manage labels via https://github.com/linuxsuren/linuxsuren-bot-config 2 | # please check out https://probot.github.io/apps/settings/ 3 | repository: 4 | name: open-source-best-practice 5 | description: This is an open-source best practice for those who want to participate in open-source projects 6 | homepage: https://github.com/LinuxSuRen/open-source-best-practice 7 | private: false 8 | has_issues: true 9 | has_wiki: false 10 | has_downloads: true 11 | default_branch: master 12 | allow_squash_merge: true 13 | allow_merge_commit: true 14 | allow_rebase_merge: true 15 | branches: 16 | - name: master 17 | protection: 18 | required_pull_request_reviews: 19 | required_approving_review_count: 1 20 | dismiss_stale_reviews: true 21 | require_code_owner_reviews: true 22 | dismissal_restrictions: 23 | users: [] 24 | teams: [] 25 | required_status_checks: 26 | strict: true 27 | contexts: [] 28 | enforce_admins: false 29 | restrictions: 30 | users: [] 31 | teams: [] 32 | -------------------------------------------------------------------------------- /.github/website/config.toml: -------------------------------------------------------------------------------- 1 | googleAnalytics = "UA-75011109-1" 2 | 3 | # hugo server --minify --themesDir ... --baseURL=http://0.0.0.0:1313/theme/hugo-book/ 4 | 5 | baseURL = 'https://linuxsuren.github.io/open-source-best-practice/' 6 | title = '开源最佳实践' 7 | description = '写给希望了解、参与、传播开源的人群' 8 | theme = 'book' 9 | 10 | # Book configuration 11 | disablePathToLower = true 12 | enableGitInfo = true 13 | disqusShortname = "my-site" 14 | 15 | [permalinks] 16 | docs = '/:filename.md/' 17 | 18 | # Needed for mermaid/katex shortcodes 19 | [markup] 20 | [markup.goldmark.renderer] 21 | unsafe = true 22 | 23 | [markup.tableOfContents] 24 | startLevel = 1 25 | 26 | # Multi-lingual mode config 27 | # There are different options to translate files 28 | # See https://gohugo.io/content-management/multilingual/#translation-by-filename 29 | # And https://gohugo.io/content-management/multilingual/#translation-by-content-directory 30 | [languages] 31 | 32 | [languages.en] 33 | title = '开源最佳实践' 34 | contentDir = 'content' 35 | 36 | [menu] 37 | # [[menu.before]] 38 | [[menu.after]] 39 | name = "GitHub" 40 | url = "https://github.com/LinuxSuRen/open-source-best-practice" 41 | weight = 10 42 | 43 | [params] 44 | # (Optional, default light) Sets color theme: light, dark or auto. 45 | # Theme 'auto' switches between dark and light modes based on browser/os preferences 46 | BookTheme = 'auto' 47 | 48 | # (Optional, default true) Controls table of contents visibility on right side of pages. 49 | # Start and end levels can be controlled with markup.tableOfContents setting. 50 | # You can also specify this parameter per page in front matter. 51 | BookToC = true 52 | 53 | # (Optional, default none) Set the path to a logo for the book. If the logo is 54 | # /static/logo.png then the path would be logo.png 55 | # BookLogo = 'logo.png' 56 | 57 | # (Optional, default none) Set leaf bundle to render as side menu 58 | # When not specified file structure and weights will be used 59 | BookMenuBundle = '/menu' 60 | 61 | # (Optional, default docs) Specify root page to render child pages as menu. 62 | # Page is resoled by .GetPage function: https://gohugo.io/functions/getpage/ 63 | # For backward compatibility you can set '*' to render all sections to menu. Acts same as '/' 64 | BookSection = '*' 65 | 66 | # Set source repository location. 67 | # Used for 'Last Modified' and 'Edit this page' links. 68 | BookRepo = 'https://github.com/LinuxSuRen/open-source-best-practice' 69 | 70 | # (Optional, default 'commit') Specifies commit portion of the link to the page's last modified 71 | # commit hash for 'doc' page type. 72 | # Requires 'BookRepo' param. 73 | # Value used to construct a URL consisting of BookRepo/BookCommitPath/ 74 | # Github uses 'commit', Bitbucket uses 'commits' 75 | BookCommitPath = 'commit' 76 | 77 | # Enable "Edit this page" links for 'doc' page type. 78 | # Disabled by default. Uncomment to enable. Requires 'BookRepo' param. 79 | # Edit path must point to root directory of repo. 80 | # BookEditPath = 'edit/master' 81 | 82 | # Configure the date format used on the pages 83 | # - In git information 84 | # - In blog posts 85 | BookDateFormat = 'January 2, 2006' 86 | 87 | # (Optional, default true) Enables search function with flexsearch, 88 | # Index is built on fly, therefore it might slowdown your website. 89 | # Configuration for indexing can be adjusted in i18n folder per language. 90 | BookSearch = true 91 | 92 | # (Optional, default true) Enables comments template on pages 93 | # By default partals/docs/comments.html includes Disqus template 94 | # See https://gohugo.io/content-management/comments/#configure-disqus 95 | # Can be overwritten by same param in page frontmatter 96 | # BookComments = true 97 | 98 | # /!\ This is an experimental feature, might be removed or changed at any time 99 | # (Optional, experimental, default false) Enables portable links and link checks in markdown pages. 100 | # Portable links meant to work with text editors and let you write markdown without {{< relref >}} shortcode 101 | # Theme will print warning if page referenced in markdown does not exists. 102 | BookPortableLinks = true 103 | 104 | # /!\ This is an experimental feature, might be removed or changed at any time 105 | # (Optional, experimental, default false) Enables service worker that caches visited pages and resources for offline use. 106 | BookServiceWorker = true 107 | 108 | # /!\ This is an experimental feature, might be removed or changed at any time 109 | # (Optional, experimental, default false) Enables a drop-down menu for translations only if a translation is present. 110 | BookTranslatedOnly = true 111 | -------------------------------------------------------------------------------- /.github/website/content/_index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "开源最佳实践" 3 | description: "写给希望了解、参与、传播开源的人群" 4 | --- 5 | -------------------------------------------------------------------------------- /.github/website/content/menu/index.md: -------------------------------------------------------------------------------- 1 | +++ 2 | headless = true 3 | +++ 4 | 5 | - [good-first-issue]({{< relref "/good-first-issue.md" >}}) 6 | - [为什么要参与开源]({{< relref "/motivation.md" >}}) 7 | - [激励制度]({{< relref "/encourage.md" >}}) 8 | - [图书推荐]({{< relref "/books.md" >}}) 9 | - [相关工作]({{< relref "/docs/what/jobs.md" >}}) 10 | - [开源商业化公司融资情况]({{< relref "/financing.md" >}}) 11 | - [二本科班生如何参与开源]({{< relref "/docs/cs-student-open-source.md" >}}) 12 | -------------------------------------------------------------------------------- /.github/website/resources/_gen/assets/scss/open-source-best-practice/book.scss_50fc8c04e12a2f59027287995557ceff.content: -------------------------------------------------------------------------------- 1 | @charset "UTF-8";:root{--gray-100:#f8f9fa;--gray-200:#e9ecef;--gray-500:#adb5bd;--color-link:#0055bb;--color-visited-link:#8440f1;--body-background:white;--body-font-color:black;--icon-filter:none;--hint-color-info:#6bf;--hint-color-warning:#fd6;--hint-color-danger:#f66}@media(prefers-color-scheme:dark){:root{--gray-100:rgba(255, 255, 255, 0.1);--gray-200:rgba(255, 255, 255, 0.2);--gray-500:rgba(255, 255, 255, 0.5);--color-link:#84b2ff;--color-visited-link:#b88dff;--body-background:#343a40;--body-font-color:#e9ecef;--icon-filter:brightness(0) invert(1);--hint-color-info:#6bf;--hint-color-warning:#fd6;--hint-color-danger:#f66}}/*!normalize.css v8.0.1 | MIT License | github.com/necolas/normalize.css*/html{line-height:1.15;-webkit-text-size-adjust:100%}body{margin:0}main{display:block}h1{font-size:2em;margin:.67em 0}hr{box-sizing:content-box;height:0;overflow:visible}pre{font-family:monospace,monospace;font-size:1em}a{background-color:transparent}abbr[title]{border-bottom:none;text-decoration:underline;text-decoration:underline dotted}b,strong{font-weight:bolder}code,kbd,samp{font-family:monospace,monospace;font-size:1em}small{font-size:80%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sub{bottom:-.25em}sup{top:-.5em}img{border-style:none}button,input,optgroup,select,textarea{font-family:inherit;font-size:100%;line-height:1.15;margin:0}button,input{overflow:visible}button,select{text-transform:none}button,[type=button],[type=reset],[type=submit]{-webkit-appearance:button}button::-moz-focus-inner,[type=button]::-moz-focus-inner,[type=reset]::-moz-focus-inner,[type=submit]::-moz-focus-inner{border-style:none;padding:0}button:-moz-focusring,[type=button]:-moz-focusring,[type=reset]:-moz-focusring,[type=submit]:-moz-focusring{outline:1px dotted ButtonText}fieldset{padding:.35em .75em .625em}legend{box-sizing:border-box;color:inherit;display:table;max-width:100%;padding:0;white-space:normal}progress{vertical-align:baseline}textarea{overflow:auto}[type=checkbox],[type=radio]{box-sizing:border-box;padding:0}[type=number]::-webkit-inner-spin-button,[type=number]::-webkit-outer-spin-button{height:auto}[type=search]{-webkit-appearance:textfield;outline-offset:-2px}[type=search]::-webkit-search-decoration{-webkit-appearance:none}::-webkit-file-upload-button{-webkit-appearance:button;font:inherit}details{display:block}summary{display:list-item}template{display:none}[hidden]{display:none}.flex{display:flex}.flex-auto{flex:auto}.flex-even{flex:1 1}.flex-wrap{flex-wrap:wrap}.justify-start{justify-content:flex-start}.justify-end{justify-content:flex-end}.justify-center{justify-content:center}.justify-between{justify-content:space-between}.align-center{align-items:center}.mx-auto{margin:0 auto}.text-center{text-align:center}.text-left{text-align:left}.text-right{text-align:right}.hidden{display:none}input.toggle{height:0;width:0;overflow:hidden;opacity:0;position:absolute}.clearfix::after{content:"";display:table;clear:both}html{font-size:16px;scroll-behavior:smooth;touch-action:manipulation}body{min-width:20rem;color:var(--body-font-color);background:var(--body-background);letter-spacing:.33px;font-weight:400;text-rendering:optimizeLegibility;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;box-sizing:border-box}body *{box-sizing:inherit}h1,h2,h3,h4,h5{font-weight:400}a{text-decoration:none;color:var(--color-link)}img{vertical-align:baseline}:focus{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}aside nav ul{padding:0;margin:0;list-style:none}aside nav ul li{margin:1em 0;position:relative}aside nav ul a{display:block}aside nav ul a:hover{opacity:.5}aside nav ul ul{padding-inline-start:1rem}ul.pagination{display:flex;justify-content:center;list-style-type:none}ul.pagination .page-item a{padding:1rem}.container{max-width:80rem;margin:0 auto}.book-icon{filter:var(--icon-filter)}.book-brand{margin-top:0;margin-bottom:1rem}.book-brand img{height:1.5em;width:1.5em;margin-inline-end:.5rem}.book-menu{flex:0 0 16rem;font-size:.875rem}.book-menu .book-menu-content{width:16rem;padding:1rem;background:var(--body-background);position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-menu a,.book-menu label{color:inherit;cursor:pointer;word-wrap:break-word}.book-menu a.active{color:var(--color-link)}.book-menu input.toggle+label+ul{display:none}.book-menu input.toggle:checked+label+ul{display:block}.book-menu input.toggle+label::after{content:"▸"}.book-menu input.toggle:checked+label::after{content:"▾"}body[dir=rtl] .book-menu input.toggle+label::after{content:"◂"}body[dir=rtl] .book-menu input.toggle:checked+label::after{content:"▾"}.book-section-flat{margin:2rem 0}.book-section-flat>a,.book-section-flat>span,.book-section-flat>label{font-weight:bolder}.book-section-flat>ul{padding-inline-start:0}.book-page{min-width:20rem;flex-grow:1;padding:1rem}.book-post{margin-bottom:3rem}.book-header{display:none;margin-bottom:1rem}.book-header label{line-height:0}.book-header img.book-icon{height:1.5em;width:1.5em}.book-search{position:relative;margin:1rem 0;border-bottom:1px solid transparent}.book-search input{width:100%;padding:.5rem;border:0;border-radius:.25rem;background:var(--gray-100);color:var(--body-font-color)}.book-search input:required+.book-search-spinner{display:block}.book-search .book-search-spinner{position:absolute;top:0;margin:.5rem;margin-inline-start:calc(100% - 1.5rem);width:1rem;height:1rem;border:1px solid transparent;border-top-color:var(--body-font-color);border-radius:50%;animation:spin 1s ease infinite}@keyframes spin{100%{transform:rotate(360deg)}}.book-search small{opacity:.5}.book-toc{flex:0 0 16rem;font-size:.75rem}.book-toc .book-toc-content{width:16rem;padding:1rem;position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-toc img{height:1em;width:1em}.book-toc nav>ul>li:first-child{margin-top:0}.book-footer{padding-top:1rem;font-size:.875rem}.book-footer img{height:1em;width:1em;margin-inline-end:.5rem}.book-comments{margin-top:1rem}.book-languages{margin-block-end:2rem}.book-languages .book-icon{height:1em;width:1em;margin-inline-end:.5em}.book-languages ul{padding-inline-start:1.5em}.book-menu-content,.book-toc-content,.book-page,.book-header aside,.markdown{transition:.2s ease-in-out;transition-property:transform,margin,opacity,visibility;will-change:transform,margin,opacity}@media screen and (max-width:56rem){#menu-control,#toc-control{display:inline}.book-menu{visibility:hidden;margin-inline-start:-16rem;font-size:16px;z-index:1}.book-toc{display:none}.book-header{display:block}#menu-control:focus~main label[for=menu-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#menu-control:checked~main .book-menu{visibility:initial}#menu-control:checked~main .book-menu .book-menu-content{transform:translateX(16rem);box-shadow:0 0 .5rem rgba(0,0,0,.1)}#menu-control:checked~main .book-page{opacity:.25}#menu-control:checked~main .book-menu-overlay{display:block;position:absolute;top:0;bottom:0;left:0;right:0}#toc-control:focus~main label[for=toc-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#toc-control:checked~main .book-header aside{display:block}body[dir=rtl] #menu-control:checked~main .book-menu .book-menu-content{transform:translateX(-16rem)}}@media screen and (min-width:80rem){.book-page,.book-menu .book-menu-content,.book-toc .book-toc-content{padding:2rem 1rem}}@font-face{font-family:roboto;font-style:normal;font-weight:400;font-display:swap;src:local(""),url(fonts/roboto-v27-latin-regular.woff2)format("woff2"),url(fonts/roboto-v27-latin-regular.woff)format("woff")}@font-face{font-family:roboto;font-style:normal;font-weight:700;font-display:swap;src:local(""),url(fonts/roboto-v27-latin-700.woff2)format("woff2"),url(fonts/roboto-v27-latin-700.woff)format("woff")}@font-face{font-family:roboto mono;font-style:normal;font-weight:400;font-display:swap;src:local(""),url(fonts/roboto-mono-v13-latin-regular.woff2)format("woff2"),url(fonts/roboto-mono-v13-latin-regular.woff)format("woff")}body{font-family:roboto,sans-serif}code{font-family:roboto mono,monospace}@media print{.book-menu,.book-footer,.book-toc{display:none}.book-header,.book-header aside{display:block}main{display:block!important}}.markdown{line-height:1.6}.markdown>:first-child{margin-top:0}.markdown h1,.markdown h2,.markdown h3,.markdown h4,.markdown h5,.markdown h6{font-weight:400;line-height:1;margin-top:1.5em;margin-bottom:1rem}.markdown h1 a.anchor,.markdown h2 a.anchor,.markdown h3 a.anchor,.markdown h4 a.anchor,.markdown h5 a.anchor,.markdown h6 a.anchor{opacity:0;font-size:.75em;vertical-align:middle;text-decoration:none}.markdown h1:hover a.anchor,.markdown h1 a.anchor:focus,.markdown h2:hover a.anchor,.markdown h2 a.anchor:focus,.markdown h3:hover a.anchor,.markdown h3 a.anchor:focus,.markdown h4:hover a.anchor,.markdown h4 a.anchor:focus,.markdown h5:hover a.anchor,.markdown h5 a.anchor:focus,.markdown h6:hover a.anchor,.markdown h6 a.anchor:focus{opacity:initial}.markdown h4,.markdown h5,.markdown h6{font-weight:bolder}.markdown h5{font-size:.875em}.markdown h6{font-size:.75em}.markdown b,.markdown optgroup,.markdown strong{font-weight:bolder}.markdown a{text-decoration:none}.markdown a:hover{text-decoration:underline}.markdown a:visited{color:var(--color-visited-link)}.markdown img{max-width:100%;height:auto}.markdown code{padding:0 .25rem;background:var(--gray-200);border-radius:.25rem;font-size:.875em}.markdown pre{padding:1rem;background:var(--gray-100);border-radius:.25rem;overflow-x:auto}.markdown pre code{padding:0;background:0 0}.markdown p{word-wrap:break-word}.markdown blockquote{margin:1rem 0;padding:.5rem 1rem .5rem .75rem;border-inline-start:.25rem solid var(--gray-200);border-radius:.25rem}.markdown blockquote :first-child{margin-top:0}.markdown blockquote :last-child{margin-bottom:0}.markdown table{overflow:auto;display:block;border-spacing:0;border-collapse:collapse;margin-top:1rem;margin-bottom:1rem}.markdown table tr th,.markdown table tr td{padding:.5rem 1rem;border:1px solid var(--gray-200)}.markdown table tr:nth-child(2n){background:var(--gray-100)}.markdown hr{height:1px;border:none;background:var(--gray-200)}.markdown ul,.markdown ol{padding-inline-start:2rem}.markdown dl dt{font-weight:bolder;margin-top:1rem}.markdown dl dd{margin-inline-start:0;margin-bottom:1rem}.markdown .highlight table tr td:nth-child(1) pre{margin:0;padding-inline-end:0}.markdown .highlight table tr td:nth-child(2) pre{margin:0;padding-inline-start:0}.markdown details{padding:1rem;border:1px solid var(--gray-200);border-radius:.25rem}.markdown details summary{line-height:1;padding:1rem;margin:-1rem;cursor:pointer}.markdown details[open] summary{margin-bottom:0}.markdown figure{margin:1rem 0}.markdown figure figcaption p{margin-top:0}.markdown-inner>:first-child{margin-top:0}.markdown-inner>:last-child{margin-bottom:0}.markdown .book-expand{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden}.markdown .book-expand .book-expand-head{background:var(--gray-100);padding:.5rem 1rem;cursor:pointer}.markdown .book-expand .book-expand-content{display:none;padding:1rem}.markdown .book-expand input[type=checkbox]:checked+.book-expand-content{display:block}.markdown .book-tabs{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden;display:flex;flex-wrap:wrap}.markdown .book-tabs label{display:inline-block;padding:.5rem 1rem;border-bottom:1px transparent;cursor:pointer}.markdown .book-tabs .book-tabs-content{order:999;width:100%;border-top:1px solid var(--gray-100);padding:1rem;display:none}.markdown .book-tabs input[type=radio]:checked+label{border-bottom:1px solid var(--color-link)}.markdown .book-tabs input[type=radio]:checked+label+.book-tabs-content{display:block}.markdown .book-tabs input[type=radio]:focus+label{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}.markdown .book-columns{margin-left:-1rem;margin-right:-1rem}.markdown .book-columns>div{margin:1rem 0;min-width:10rem;padding:0 1rem}.markdown a.book-btn{display:inline-block;font-size:.875rem;color:var(--color-link);line-height:2rem;padding:0 1rem;border:1px solid var(--color-link);border-radius:.25rem;cursor:pointer}.markdown a.book-btn:hover{text-decoration:none}.markdown .book-hint.info{border-color:#6bf;background-color:rgba(102,187,255,.1)}.markdown .book-hint.warning{border-color:#fd6;background-color:rgba(255,221,102,.1)}.markdown .book-hint.danger{border-color:#f66;background-color:rgba(255,102,102,.1)} -------------------------------------------------------------------------------- /.github/website/resources/_gen/assets/scss/open-source-best-practice/book.scss_50fc8c04e12a2f59027287995557ceff.json: -------------------------------------------------------------------------------- 1 | {"Target":"book.min.97cfda4f5e3c9fa49a2bf8d401f4ddc0eec576c99cdcf6afbec19173200c37db.css","MediaType":"text/css","Data":{"Integrity":"sha256-l8/aT148n6SaK/jUAfTdwO7Fdsmc3PavvsGRcyAMN9s="}} -------------------------------------------------------------------------------- /.github/workflows/backup.yaml: -------------------------------------------------------------------------------- 1 | name: Backup Git repository 2 | 3 | on: 4 | workflow_dispatch: 5 | push: 6 | branches: 7 | - master 8 | 9 | jobs: 10 | BackupGit: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4.2.2 14 | - name: backup gitee 15 | uses: jenkins-zh/git-backup-actions@v0.0.6 16 | env: 17 | GIT_DEPLOY_KEY: ${{ secrets.GIT_DEPLOY_KEY }} 18 | TARGET_GIT: "git@gitee.com:linuxsuren/open-source-best-practice.git" 19 | -------------------------------------------------------------------------------- /.github/workflows/generator.yaml: -------------------------------------------------------------------------------- 1 | name: generator 2 | 3 | on: 4 | push: 5 | branches: [ master ] 6 | 7 | workflow_dispatch: 8 | 9 | jobs: 10 | build: 11 | runs-on: ubuntu-latest 12 | if: "!contains(github.event.head_commit.message, 'ci skip')" 13 | 14 | steps: 15 | - uses: actions/checkout@v4.2.2 16 | - name: Update financing 17 | uses: linuxsuren/yaml-readme@v0.0.17 18 | env: 19 | GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }} 20 | with: 21 | pattern: 'data/financing/*.yaml' 22 | template: 'data/financing/financing.tpl' 23 | output: 'financing.md' 24 | username: linuxsuren 25 | org: linuxsuren 26 | repo: open-source-best-practice 27 | push: false 28 | orderby: date 29 | sortby: '!date' 30 | - name: Update DevRel 31 | uses: linuxsuren/yaml-readme@v0.0.17 32 | env: 33 | GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }} 34 | with: 35 | pattern: 'what/items/devrel-*.yaml' 36 | template: 'what/devrel.tpl' 37 | output: 'what/devrel.md' 38 | username: linuxsuren 39 | org: linuxsuren 40 | repo: open-source-best-practice 41 | push: false 42 | - name: Update jobs 43 | uses: linuxsuren/yaml-readme@v0.0.17 44 | env: 45 | GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }} 46 | with: 47 | pattern: 'what/items/job-*.yaml' 48 | template: 'what/jobs.tpl' 49 | output: 'what/jobs.md' 50 | username: linuxsuren 51 | org: linuxsuren 52 | repo: open-source-best-practice 53 | -------------------------------------------------------------------------------- /.github/workflows/publish.yaml: -------------------------------------------------------------------------------- 1 | name: BuildHugo 2 | 3 | on: 4 | workflow_dispatch: 5 | push: 6 | branches: 7 | - master 8 | 9 | jobs: 10 | BuildHugo: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4.2.2 14 | with: 15 | submodules: 'recursive' 16 | - name: Publish 17 | env: 18 | GITHUB_TOKEN: ${{ secrets.PUBLISH_TOKEN }} 19 | run: | 20 | mkdir -p bin 21 | curl -L https://github.com/gohugoio/hugo/releases/download/v0.88.1/hugo_extended_0.88.1_Linux-64bit.tar.gz -o bin/hugo.tar.gz 22 | tar xzvf bin/hugo.tar.gz -C bin 23 | sudo mv bin/hugo /usr/local/bin 24 | 25 | git checkout -b book-publish 26 | make publish 27 | git status 28 | git config --global user.email 'LinuxSuRen@users.noreply.github.com' 29 | git config --global user.name rick 30 | git remote -v 31 | git add . && git commit -m 'publish' && git push origin book-publish -f 32 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | .github/website/themes 3 | .github/website/content/docs 4 | .github/website/resources/_gen 5 | .github/website/.hugo_build.lock 6 | bin/ 7 | .vscode/ 8 | -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule ".github/website/themes/book"] 2 | path = .github/website/themes/book 3 | url = https://github.com/alex-shpak/hugo-book 4 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Rick 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | theme: 2 | rm -rf .github/website/themes/book 3 | git submodule add -f https://github.com/alex-shpak/hugo-book .github/website/themes/book 4 | 5 | copy: 6 | mkdir -p .github/website/content/docs/what 7 | cp *.md .github/website/content/docs 8 | cp -r what/*.md .github/website/content/docs/what 9 | cat .github/website/content/docs/README.md >> .github/website/content/_index.md 10 | 11 | run: copy 12 | hugo server -s .github/website/ 13 | git checkout .github/website/content/_index.md 14 | 15 | publish: copy 16 | hugo -s .github/website/ 17 | mv .github/website/public docs 18 | git checkout .github/website/content/_index.md 19 | -------------------------------------------------------------------------------- /README-en.md: -------------------------------------------------------------------------------- 1 | # Open-source Best Practice 2 | 3 | [![hackmd-github-sync-badge](https://hackmd.io/o_NKVlw4QiqqDoWSYMLnQg/badge)](https://hackmd.io/o_NKVlw4QiqqDoWSYMLnQg) 4 | 5 | 6 | ## Why? 7 | Why do I want to write the "Open-source Best Practice"? 8 | 9 | Those who want to participate in an open-source project generally feel confused about where to get started. Hopefully, this practice can help more people. I believe that you can improve yourself no matter you work in a role as an ordinary developer or other roles. 10 | 11 | You may already know about certain existing open source guides, such as ["Open Source Guides"](https://opensource.guide) which GitHub wrote. So, what's the difference between those guides and what I write here? Open source is more than just sharing your code. The more important part is the collaboration with other contributors and how to do it. 12 | 13 | To make a difference, I'll try to explain it from the practice aspect. 14 | 15 | 16 | 17 | ## Get started 18 | Please read the project README carefully, and follow the process in the CONTRIBUTION. 19 | 20 | In the early days of a new project, especially in an unfamiliar field, here are some ways to help you contribute to an open-source project. 21 | * Document contributions. This is a very effective way to learn about a project. Usually, we can fix typos, punctuation, grammatical errors, broken links, and so on as we read the document. 22 | * Good-first-issue. For projects that want to receive more contributions, the tag will be added to issues that are easy to fix. 23 | 24 | ## Issues 25 | Common Misunderstanding: 26 | 27 | * Only title, without content. 28 | * Only result and phenomena, without background. 29 | * There are many possible causes for a problem, and no one can guess your environment and operation steps. 30 | * Only screenshots, without error, exception and keywords in content. 31 | * If there is no text, it is not convenient for others to search. 32 | 33 | Best Practice: 34 | 35 | * Add a new issue after confirming the problem is not in the existing issues. 36 | * Be familiar with the language of regulations that correspond to community expectations, and follow them. 37 | * The title should be concise and standardized 38 | * Make a classification, and you can do this by label or title prefix 39 | * Common title classification: Question: xxx, Proposal: xxx, Bug: xxx 40 | * The issue relevant to the UI needs screenshot(s). 41 | 42 | ## Pull Request 43 | Common Misunderstanding: 44 | * Use a single branch(like master) to commit changes. 45 | * Many different updates and fixing in a single PR. 46 | * Continually add new content in a single PR. 47 | * Merge your own PR. 48 | * Use instant messaging to urge specific people to review your PR. 49 | 50 | Best Practice: 51 | * Before submitting PR for the first time, browse some successfully merged PRs and take a look at the comments and format, etc. 52 | * If the problem to fix already has a related issue, please assure that nobody submitted the corresponding PR. Then, please leave a comment about your fix plan. 53 | * If you want to submit several changes, please add the issue first. And describe your thoughts according to the actual situation(like difficulty and controversy) 54 | * A PR only contains changes of the same type. 55 | * Add a new branch for each submit. 56 | * Avoid repeatedly closing and creating PRs for the same topic 57 | * Avoid making frequent submit for the same PR, which makes it difficult for reviewers to review the PR. 58 | * If your PR is not already prepared for accepting review, please add prefix `WIP` before the title until you think the PR is ready for review. 59 | * When making revisions based on reviewers' suggestions, avoid forced push `--force`, making reviewers unable to check your newest changing part. 60 | * Keep your commit records as elegant as possible. In case there are too many reviews, the project owners will decide whether to squash your commit records at merge time. 61 | * Give as much detail as you can about your PR, like related issues(s), solving problems, and any context convenient to review. 62 | * Provide screenshots of the effect before and after modification if it is related to UI. 63 | * List your self-test process as appropriate. 64 | * Give your reason for the controversial part. 65 | * If your PR hasn't been reviewed for more than a week, try to cc* related teams. 66 | * If there is no related team to cc, you can find someone who has merged similar PR recently and explain that it is because there is no other way, and I apologize for bothering you. 67 | * *cc stands for carbon copy which means that whose address appears after the cc: header would receive a copy of the message. Also, the Cc header would also appear in the header of the received message.* 68 | 69 | ## Review 70 | In the process of PR review, there are usually three roles involved: AUTHOR, MAINTAINERS, and others. 71 | 72 | First of all, we need to figure out a question, why do we need a review? The review is critical, no matter it's code, documentation, or other types of files submitted in PR. 73 | 74 | * The expression of the most basic principles of open source(transparency and openness). 75 | * The Review process is a manifestation of the open source spirit. In the Review, we need to open not only about the results but also about the process. 76 | * Review does not mean an audit. Everyone can be a reviewer, and everyone will learn in this process. 77 | * Life cycle 78 | * PR does not apply to urgent merging needs. 79 | * After submitting the PR, the author should check it by himself first. If there is any problem, please mark it as "work in progress." 80 | * We can add a prefix: `WIP` of PR that is not ready for review. 81 | * If you are unsure about a specific part of the code or documentation, you can express your opinion directly in the form of a comment. 82 | * Review and merge within 2 to 7 days. 83 | * Politeness 84 | * No one should review your PR, including maintainers. 85 | * Thanks to each reviewer who contributed to your PR merge. 86 | * Don't rush anyone to review your PR during the best review cycle. 87 | * If you do need to ask for a review for help, please give instructions. And @ a team first, then directly @ a person, and apologize for interrupting. 88 | * Make a clear point. 89 | * Try to avoid giving vague comments, and the writer needs to make changes based on the suggestions you give. 90 | * If you are not sure about the question, you can comment like this: "I have a feeling there may be a problem here," give the suggestion and why, and indicate that the comment does not block the PR merge. 91 | * For the part in question, give information or data that support your point. If relevant authoritative information is available, you can attach a related web link. 92 | * For example, code comments in PR are not standard, giving the official community documentation links. 93 | * Automated process 94 | * Manage the review process with an automated tool like [Lighthouse](https://github.com/jenkins-x/lighthouse) 95 | * Run as many automated tests as possible (unit tests, E2E tests, stress tests, etc.) before merging. 96 | * Avoid human intervention in automated processes 97 | * If a review is completed, but some manual verification is needed. To avoid an untimely automatic merge, you can block it with a comment command. 98 | * For example, comment `/hold` to prevent robot-account auto-merging. 99 | 100 | ## Community Operation 101 | 102 | Different people have different understandings of the word **community**. The word community in this article is precisely the **open-source community**. 103 | 104 | There are many excellent practices and ways in community operation, such as social media, Meetup, and TOC. 105 | 106 | ### SIG Operation 107 | 108 | Determine the admittance and approval system of the SIG, and then control the number of SIG according to the team's actual situation. In this process, the quality of operations is the primary consideration. 109 | 110 | The healthy development of SIG cannot be separated from openness, transparency, and diversification. There is no sense in existence for the formalistic and non-open-source SIG. 111 | 112 | ### SIG Meeting 113 | 114 | * Meeting time should accommodate the needs of the majority of people 115 | * Voted on via [Doodle](https://doodle.com/en/) or similar tools 116 | * Each meeting should have an opening and a closing statement 117 | * **Start as:** Let's begin our regular meeting today; **End by saying**, "Thank you very much for coming to today's community meeting," and so on. 118 | * Welcome new members with enthusiasm and encourage self-introduction 119 | * Give the necessary context introduction 120 | * Whether for the participant dial into the meeting or watch the replay, it may be the first participating time for them. The lack of context makes it difficult for them to follow the discussion. 121 | * If there is a textual context introduction, try to include it in the minutes. 122 | * The moderator should control the time and pace of the meeting 123 | * Try to limit the time to one hour, and put the remaining topics into the next meeting. 124 | * Assist and guide the conclusion of the discussion 125 | * Use appropriate expressions 126 | * Avoid phrases like "We discussed that yesterday." New community members won't be able to follow what you discussed. 127 | * Make sure meetings are regular 128 | * In general, meetings once every two weeks are moderate. 129 | * If the number of participants is relatively large and distributed in different time zones, two meetings can be divided based on participants' opinions. 130 | * Notify the community as early as possible of canceling the meeting when no one available to chair the meeting can attend or in other cases where the meeting needs to be canceled. 131 | * The minutes of the meeting 132 | * We can use [Google Document](https://docs.google.com/document/u/0/) for text records. 133 | * We can use [YouTube](https://www.youtube.com/) for video records. 134 | 135 | ## Others 136 | Here are some other recommended practices: 137 | * Check your email 138 | * Please associate your usual email address with GitHub, and then you can receive the notice information in issues and PR in time. 139 | * Manage your schedule through your computer and mobile phone 140 | * There will be various meetings in the open-source community, and it's easy to forget important things if you're not in the habit of using a calendar. 141 | 142 | ## References 143 | * [Google Engineering Practices Documentation](https://github.com/google/eng-practices) 144 | 145 | ## Projects that adopt the practice 146 | * [Halo](https://github.com/halo-dev/halo) 147 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | > 本文潜在的目标人群： 2 | > 3 | > 正在（或希望）从事以下工作的人：技术岗（研发、测试、运维）、运营、市场，其他对开源开放性协作感兴趣的人。 4 | 5 | [![LinuxSuRen/open-source-best-practice](https://img.shields.io/static/v1?label=OSBP&message=%E5%BC%80%E6%BA%90%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5&color=blue)](https://github.com/LinuxSuRen/open-source-best-practice) 6 | 7 | ## 为什么？ 8 | 9 | 为什么要编写这一份《开源最佳实践》呢？ 10 | 11 | 对于初次尝试参与开源的人，在面对完善、成熟、大型的开源项目时，往往会有无从下手的感觉。《开源最佳实践》将从如何选择合适的项目、如何参与贡献等多个角度引导读者。 12 | 13 | 国内（中国）已经有 Gitee 发起并由众多开源爱好者共同编撰的[《开源指北》](https://gitee.com/gitee-community/opensource-guide)，还有 GitHub 官方提供的[《开源软件指南》](https://opensource.guide/zh-hans/)，那这一份最佳实践和这些有什么区别吗？开源不仅仅是把代码开放出来就好了，更加重要的是一种协作精神的体验，以及具体落地操作。所以《开源最佳实践》更多会从落地实践的角度来讲述。 14 | 15 | 不管你是一名普通的研发，还是一名非技术人员，参与开源必将使你受益匪浅。万事开头难，希望这一份最佳实践可以帮助到更多有意参与开源的人们。 16 | 17 | ## 寻找起点 18 | 19 | 参与开源有很多的形式和途径，对于刚开始接触开源的人而言，非常重要的一点就是——基于已有的经验、技能选择适合的开源社区，并且[坚持较长的一段时间](insist.md)。 20 | 21 | 开源社区通常会在一些平台托管代码、发布文章或音视频资料，大家可以在这些[常见的平台](platforms.md)中寻找适合自己的社区。 22 | 23 | 对于一个开源社区来说，通常可能会有多个开源项目。社区的自我发展，也要求不同技能、不同背景的人加入，而为了保证社区以公开、透明、平等的方式得以适当的治理，也会出现多种不同类型的项目。例如：存放社区治理规则的 [community](practice/community-first.md) 项目，存放与图片设计、logo 相关的 artwork 项目，存放社区文档、网站的 website 项目等等。甚至，在发展过程中还可能会出现“子社区”。 24 | 25 | 和传统的、自上而下的团队管理不同，在开源社区里，虽然存在着不同的角色、分工，但这些角色既不是任命也不是申请来的。角色或影响力，都只能通过贡献（contribution）获得，任何人没有所谓的特权。如果你已经习惯了按部就班地完成分配好的任务，在开源社区里可能会有无所事事的感觉，进而找不到自己的“位置”。而对于愿意自发地做事情、喜欢拥抱变化、追求变得更好的人而言，则会在开源社区中找到“如鱼得水”的感觉。排除涉及到权限的事情，大部分情况下都是不需要“等拿到授权后”再行动。例如：代码（或其他类型的 Pull Request）的 review 并不是 maintainer 独有的权力，每个走过路过的人都是可以针对自己熟悉的领域给出观点、评价。 26 | 27 | 接下来，会从不同的角色、角度来阐述如何更好地参与到开源社区中。 28 | 29 | ## 贡献者 30 | 31 | 对于贡献者（contributor）来说，熟悉[通用的贡献指南](how-to-contribute.md)可以在参与贡献的过程中少走弯路、获得更多帮助。 32 | 33 | ## 维护者 34 | 35 | 项目的维护者（maintainer），通常指的是有合并（Pull Request）权限的贡献者。在不同的社区中可能会有不同的叫法，例如：committer、[PMC](https://www.apache.org/dev/pmc.html)(Project Management Committee)、owner 等等。维护者更多的会考虑如何促进项目、社区的健康发展，以及 review 相关仓库的 PR。 36 | 37 | ### 关注贡献者 38 | 39 | 项目维护者，一般情况下是愿意花更多精力、时间到某个项目上的人。如果是纯个人项目，或者并没有期望有很多贡献者协同参与的话，并不需要特意关注贡献者，只做自己喜欢做的事情即可。反之，维护者更多应该做的事情是去关注贡献者，帮助愿意参与项目的人贡献他们的聪明才智，也就是所谓的发挥“杠杆作用”。换个角度考虑，对于“能力很强”但对上述事情没有兴趣的话，其实是没有必要赋予“维护者”的权限。 40 | 41 | 那么，对贡献者的关注包含哪些方面呢？ 42 | 43 | * 定期查看新提交的 issue、PR，通过打标签（label）等方式进行分类，根据情况 ping 相应的团队（或者贡献者）； 44 | * 时间允许的情况下，选择自己熟悉领域的 issue、PR 做尽可能详尽的回复。切忌随意回复，随意对自己和其他贡献者都是不负责的一种行为，同时也是对时间的浪费； 45 | * 邀请贡献者参加社区的各类活动，例如：社区例会、Meetup 等。鼓励贡献者深度参与社区； 46 | * 熟知成员的贡献，在相应的社区角色、奖励（ambassador、top contributor 等）给与提名； 47 | * 发现、挖掘潜在的项目维护者。 48 | 49 | ### Review 50 | 51 | 在 PR 的 review 过程中，通常会涉及到三个角色的人：作者、维护者、其他。 52 | 53 | 首先，我们要想明白一个问题——为什么要进行 review ？不管 PR 中提交的是代码、文档还是其他类型的文件，进行 review 的都有着非常重要的意义。 54 | 55 | 而不管是对项目维护者，还是贡献者而言，了解如何 review 以及在 review 过程中[有哪些需要注意的地方](review.md)，都是很重要的一件事情。 56 | 57 | ## 社区治理 58 | 59 | 随着社区规模的变大，社区治理的重要性会日益凸显，可能遇到的以下问题： 60 | 61 | * 如何帮助新人快速地熟悉、适应社区的氛围、玩法； 62 | * 如何利用适当的社媒、多媒体平台宣传社区理念、技术，吸引有相似兴趣的人加入； 63 | * 如何结合社区成员自身的特点、发展诉求，通过复盘、再组织等方法，适时地调整社区结构； 64 | * 如何从合规（许可证选用、商标、专利等）层面确保社区的利益； 65 | * 如何维护社区基础设施； 66 | * 如何设置沟通、交流底线（或规则，code-of-conduct），避免不好的行为、言论。 67 | 68 | 对于社区（Community）这个词，不同的人有着不同的理解。本文的社区专指：开源社区（Open Source Community）。 69 | 70 | 在社区运营过程中，有很多好的实践和方法，例如：Technical Oversight Committee (TOC)、SIG、Meetup、Workshop（工作坊）、社交媒体推广等。下面，给出部分组织形式的最佳实践指导。 71 | 72 | ### TOC 73 | 74 | TODO 75 | 76 | ### SIG 77 | 78 | [Special Interest Group，特别兴趣小组](sig.md)，简称 SIG。在大中型开源社区中，这是一种便于社区成员在特定领域交流、讨论，更加聚焦地解决相关问题的组织形式。 79 | 80 | 开源社区中，可以根据不同的领域设立相应的 SIG。每个 SIG 往往会有一名或多名 lead（领队），以及多名活跃的社区成员作为 SIG 的成员（member）。在不同的社区中，领队可能会有不同的叫法，例如：co-chair、co-lead 等。值得注意的是，这里所使用的表述是——“领队”，而不是领导、经理（manager）、管理员（admin）、负责人；领队的重要意义在于维护 SIG 的积极、活跃，而不是特权。 81 | 82 | ### Work Group 83 | 84 | [TODO](workgroup.md) 85 | 86 | ### 活动 87 | 88 | 不管作为开源活动的组织者还是参与者，相信这份[开源活动指南](event.md)可以给你提供一些帮助。 89 | 90 | ## 参考 91 | 92 | * [Google Engineering Practices Documentation](https://github.com/google/eng-practices) 93 | * [开源相关音视频](audios-and-videos.md) 94 | * [开源相关书籍](books.md) 95 | * [英语学习资料](english.md) 96 | * [开源商业公司融资情况](financing.md) 97 | * [有公开展示所依赖开源项目的软件](open-source-credit.md) 98 | * [杂项](others.md) 99 | 100 | ## 采用该实践的项目 101 | 102 | 如果你比较认同这一份最佳实践，欢迎把下面的 badge 添加到你的项目中： 103 | 104 | ``` 105 | [![LinuxSuRen/open-source-best-practice](https://img.shields.io/static/v1?label=OSBP&message=%E5%BC%80%E6%BA%90%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5&color=blue)](https://github.com/LinuxSuRen/open-source-best-practice) 106 | ``` 107 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: linuxsuren/minimal@v0.0.1 2 | title: 开源最佳实践 3 | description: 从落地实践的角度给与开源参与者更多的参考建议 4 | google_analytics: G-ND0BZ81BE4 5 | -------------------------------------------------------------------------------- /audios-and-videos.md: -------------------------------------------------------------------------------- 1 | 我们可以通过很多渠道来了解到开源相关的知识、见解、故事等等，其中音视频是一个非常生动的来源： 2 | 3 | ## 视频 4 | 5 | ### 系列 6 | 7 | | 栏目名称 | 类型 | 描述 | 8 | |---|:---:|---| 9 | | [Koala 聊开源](https://space.bilibili.com/489667127/) | 📼视频 | 个人观点分享 | 10 | | [大咖说开源](https://space.bilibili.com/578074510/channel/seriesdetail?sid=694280) | 📼视频 | 开源软件供应链点亮计划 | 11 | | [COSCon'21 第六届中国开源年会](https://space.bilibili.com/525037536/channel/collectiondetail?sid=63363) | 📼视频 | COSCon'21 第六届中国开源年会线上演讲视频 | 12 | | 开源特训营 | 📼视频 | [开源基础](https://www.bilibili.com/video/BV1Pt4y1S7xj)、[项目启动](https://www.bilibili.com/video/BV1BK4y1Y7Xx)、[GitHub 项目管理](https://www.bilibili.com/video/BV1Sp4y1Y7kR)、[如何运营社区](https://www.bilibili.com/video/BV14p4y1e7PX)、[社区如何评审代码](https://www.bilibili.com/video/BV1Gi4y1E7pQ)、[如何提交一个合格的 PR](https://www.bilibili.com/video/BV1RV411m7Pn) | 13 | | [腾源会](https://space.bilibili.com/1662325245) | 📼视频 | 主要包括：WeOpenTalk | 14 | | [开源青年](https://space.bilibili.com/501806297) | 📼视频 | 优雅地品味软件艺术 | 15 | 16 | ### 单集 17 | 18 | |类型|标题| 19 | |:---:|---| 20 | | 📼视频 | [开源的魅力 - 以 Apache APISIX 为例](https://www.youtube.com/watch?v=A_geiZHnvv8) | 21 | 22 | --- 23 | 24 | ## 播客/音频 25 | 26 | ### 系列 27 | 28 | | 栏目名称 | 类型 | 描述 | 29 | |---|:---:|---| 30 | | [开源面对面](https://github.com/opensource-f2f/episode/) | 🎧播客 | 由个人发起的系列访谈节目 | 31 | | [ALC Beijing Podcast](https://www.ximalaya.com/keji/37853515/) | 🎧播客 | | 32 | | [开源之道 Talking](https://www.ximalaya.com/album/32915040) | 🎧播客 | | 33 | | [OpenTEKr](https://space.bilibili.com/1177021647) | 🎧视频 | 致力于构建一个可持续发展的开放科技生态圈 | 34 | | [The ReadME Podcast](https://github.com/readme/podcast/) | 🎧播客 | GitHub 官方出品，主要介绍（使用英文）开源项目 | 35 | 36 | ### 单集 37 | 38 | |类型|标题| 39 | |:---:|---| 40 | | 🎧播客 | [计算机历史博物馆 - S2E7 和吴晟聊开源工程师是不是/该不该/能不能/有没有赚到盆满钵满？](https://www.xiaoyuzhoufm.com/episode/61eabab94675a08411f514b9) | 41 | | 🎧播客 | [社会人科技评论 - 开源之道：我们与开源](https://techreview.social/14) | 42 | | 🎧播客 | [社会人科技评论 - 商业公司如何拥抱开源（与开源之道 Talking 联合出品）](https://techreview.social/20) | 43 | | 🎧播客 | [社会人科技评论 - 开源公司到底能挣钱吗？都是怎么运作的？与开发者和投资人一起聊聊开源商业化（与开源之道 Talking 联合出品）](https://techreview.social/21) | 44 | | 🎧播客 | [牛油果烤面包 - #70. 和 Vue.js 的创造者尤雨溪聊开源软件）](https://avocadotoast.live/episodes/70/) | 45 | | 🎧播客 | [捕蛇者说 - Ep 08. 如何成为一名开源老司机](https://pythonhunter.org/episodes/8) | 46 | | 🎧播客 | [捕蛇者说 - Ep 10. 和 ctrlsf 的作者 dyng 聊聊 Vim](https://pythonhunter.org/episodes/10) | 47 | | 🎧播客 | [从零道一 - S3E1 \| PINGCAP CTO 黄东旭 - 从 BASIC 到数据库 TIDB，探索开源创业的底层逻辑](https://0011.one/2021/03/06/S3E1/) | 48 | | 🎧播客 | [从零道一 - S3E5 \| Vue.js 作者尤雨溪: 框架设计就是不断地舍取](https://0011.one/2021/07/23/S3E5/) | 49 | | 🎧播客 | [从零道一 - S3E6 \| 涛思数据创始人陶建辉: 爱捣腾的 53 岁程序员](https://0011.one/2021/08/07/S3E6/) | 50 | | 🎧播客 | [编码人声 - vol.333 编码人声：新人该怎样入坑开源项目？](https://dao.fm/2021/12/09/vol-333-%e7%bc%96%e7%a0%81%e4%ba%ba%e5%a3%b0%ef%bc%9a%e6%96%b0%e4%ba%ba%e8%af%a5%e6%80%8e%e6%a0%b7%e5%85%a5%e5%9d%91%e5%bc%80%e6%ba%90%e9%a1%b9%e7%9b%ae%ef%bc%9f/) | 51 | | 🎧播客 | [Vol.22 开放式协作，内容创作者也可以玩起来 |开源年会成都跨界对话（上）](https://www.ximalaya.com/sound/482464145) | 52 | -------------------------------------------------------------------------------- /books.md: -------------------------------------------------------------------------------- 1 | 通过一些音视频、文章，我们可以了解到很多关于开源的知识、见解、理论。但如果希望能够更加深入、完整地理解开源，阅读相关书籍，是个不错的选择。 2 | 3 | > 建议大家购买正版书籍，不要传播盗版电子书。 4 | 5 | | 书名 | 可借阅的图书馆 | 书评 | 6 | |---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------| 7 | | 《新合作思维：从我到我们的商业新逻辑》 | [海图](http://primo.clcn.net.cn:1701/primo_library/libweb/action/display.do?tabs=detailsTab&ct=display&fn=search&doc=CLCN_ALEPH_CN004074352&indx=1&recIds=CLCN_ALEPH_CN004074352&recIdxs=0&elementId=0&renderMode=poppedOut&displayMode=full&frbrVersion=&vl(57223009UI0)=title&frbg=&&dscnt=0&scp.scps=scope%3A%28HD%29&mode=Basic&vid=HD&srt=rank&tab=default_tab&dum=true&vl(freeText0)=%E4%BB%8E%E6%88%91%E5%88%B0%E6%88%91%E4%BB%AC%E7%9A%84%E5%95%86%E4%B8%9A%E6%96%B0%E9%80%BB%E8%BE%91&dstmp=1641713352432) || 8 | | 《大教堂与集市》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=-5764973646437829912&dataSource=ucs01&query=%E5%A4%A7%E6%95%99%E5%A0%82%E4%B8%8E%E9%9B%86%E5%B8%82) | [豆瓣](https://book.douban.com/subject/25881855/) | 9 | | 《开源法则》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=-6131070067175101622&dataSource=ucs01&query=%E5%BC%80%E6%BA%90%E6%B3%95%E5%88%99) | [豆瓣](https://book.douban.com/subject/35263552/) | 10 | | 《不拘一格》 | [海图](http://primo.clcn.net.cn:1701/primo_library/libweb/action/display.do?tabs=detailsTab&ct=display&fn=search&doc=CLCN_ALEPH_CN004969708&indx=2&recIds=CLCN_ALEPH_CN004969708&recIdxs=1&elementId=1&renderMode=poppedOut&displayMode=full&frbrVersion=&vl(57223009UI0)=title&frbg=&&dscnt=0&scp.scps=scope%3A%28HD%29&mode=Basic&vid=HD&srt=rank&tab=default_tab&dum=true&vl(freeText0)=%E4%B8%8D%E6%8B%98%E4%B8%80%E6%A0%BC&dstmp=1641714497149) | [豆瓣](https://book.douban.com/subject/35102294/) | 11 | | 《社区运营的艺术》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=-4491791020951859091&dataSource=ucs01&query=%E7%A4%BE%E5%8C%BA%E8%BF%90%E8%90%A5%E7%9A%84%E8%89%BA%E6%9C%AF) | [豆瓣](https://book.douban.com/subject/26976995/) | 12 | | 《精英的傲慢》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=-4312135015873846037&dataSource=ucs01&query=%E7%B2%BE%E8%8B%B1%E7%9A%84%E5%82%B2%E6%85%A2) | [豆瓣](https://book.douban.com/subject/35586814/) | 13 | | 《海星与蜘蛛》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=1574923584154007493&dataSource=ucs01&query=%E6%B5%B7%E6%98%9F%E4%B8%8E%E8%9C%98%E8%9B%9B) | [豆瓣](https://book.douban.com/subject/2983978/) | 14 | | 《有限与无限的游戏》 | [国图](http://find.nlc.cn/search/showDocDetails?docId=-1395675581501465850&dataSource=ucs01&query=%E6%9C%89%E9%99%90%E4%B8%8E%E6%97%A0%E9%99%90%E7%9A%84%E6%B8%B8%E6%88%8F) | [豆瓣](https://book.douban.com/subject/33438841/) | 15 | | 《增长的文化》 | [海图](http://find.nlc.cn/search/showDocDetails?docId=-6162797880138314178&dataSource=ucs01&query=%E5%A2%9E%E9%95%BF%E7%9A%84%E6%96%87%E5%8C%96) | [豆瓣](https://book.douban.com/subject/34917768/) | 16 | | 《开源之迷》 | | [豆瓣](https://book.douban.com/subject/35716759/) | 17 | |《支配与抵抗艺术》| [海图](http://primo.clcn.net.cn:1701/primo_library/libweb/action/display.do?tabs=detailsTab&ct=display&fn=search&doc=CLCN_ALEPH_CN005057566&indx=1&recIds=CLCN_ALEPH_CN005057566&recIdxs=0&elementId=0&renderMode=poppedOut&displayMode=full&frbrVersion=&vl(57223009UI0)=title&frbg=&&dscnt=0&scp.scps=scope%3A%28HD%29&mode=Basic&vid=HD&srt=rank&tab=default_tab&dum=true&vl(freeText0)=%E6%94%AF%E9%85%8D%E4%B8%8E%E6%8A%B5%E6%8A%97%E7%9A%84%E8%89%BA%E6%9C%AF&dstmp=1644201794309) | [豆瓣](https://book.douban.com/subject/35445082/)| 18 | |《共创未来：打造自由软件神话》| [国图](http://find.nlc.cn/search/showDocDetails?docId=6911219788848429599&dataSource=ucs01&query=%E5%85%B1%E5%88%9B%E6%9C%AA%E6%9D%A5) | [豆瓣](https://book.douban.com/subject/1105751/)| 19 | 20 | 21 | ## 书单 22 | 23 | [开源之书·共读](https://shimo.im/docs/lkqUDDblhE0VKXee) 24 | 25 | ## 其他 26 | 27 | | 标题 | 作者 | 来源| 28 | |---|---|---| 29 | | [如何有效规划时间](https://mp.weixin.qq.com/s/Rn_aazxc-Q-G7nqbOsS7-w) | 适兕 | LFAPAC公众号 | 30 | | [如何成为一名成功的学生导师](https://alc-beijing.github.io/alc-site/post/how_to_be_a_successful_mentor/) | 柯振旭 | ACL Beijing 博客 | 31 | | [夜天之书](https://tisonkun.org/) | [@tisonkun](https://github.com/tisonkun) | 个人博客，包含很多开源治理、开源理解、开源普及相关的文章 | 32 | -------------------------------------------------------------------------------- /cs-student-open-source.md: -------------------------------------------------------------------------------- 1 | > 文章潜在的受众：无竞争力的普通二本科班生！ 2 | > 本文将站在普通二本科班生角度从 1. 写作原因、2. 能获得什么、3. 怎么参与、4. 和其他提升方式的对比四个方面进行描述。 3 | 4 | # 写作原因 5 | 6 | 作者本人，即我现在的身份是二本未毕业的科班生（2024年7月份毕业），我从大二（2022年）开始关注 Github 开源项目。专注于 Java 和 Go 语言，主要参与的开源社区是 Spring Cloud Alibaba、Apache Dubbo 社区。 7 | 8 | 写本篇文章的目的，非常简单，正如开头说的那样——**将从二本科班生的视角去描述如何参与开源和参与开源能得到什么**。给和我有相同经历的伙伴们一些参考。减少自己摸索参与开源的时间、降低参与 Github 开源的难度、有更多的时间去选择自己爱好的方向和社区去获得提升，获得成长！ 9 | 10 | # 参与开源有哪些好处？ 11 | 12 | 首先，我相信大家大多都是兴趣驱动或者利益驱动。没有人无缘无故去做一件事情，都希望从中获取到正向的、积极的正反馈。相信不管是谁都能说出来几条参与开源项目的好处，这里一一列举一下： 13 | 14 | 1. 学习到生产级的项目开发和维护经验； 15 | - 这个怎么描述呢？在我看来，Github 的开源项目可以分为两类： 16 | 17 | - 1：大公司成熟的项目分享出来，例如 Kubernetes 项目，继承自 Google 的 Borg 项目；Higress 项目等； 18 | - 2：来自个人开发者一个不错的想法，作者去实现一个基本的项目，越来越多的人看到，认同作者的观点，参与项目的开发和维护。 19 | 20 | star 数多的项目，大多都经过了生产环境的洗礼，达到了生产可用的级别，从中可以学习到许多优秀的设计模式，代码编写方式等。 21 | 22 | 2. 丰富自己的见识； 23 | 24 | - 一些好的项目，往往伴随着非常多的周边生态项目。例如 Dubbo 的 Dubbo-kubernetes，Dubbo-website，Dubbo 各种客户端实现等等项目。他们都会基于 Dubbo 衍生出一系列的周边生态。在 Dubbo-website 中可以学习到如何编写一篇通俗易懂的说明文章、在 Dubbo 客户端实现中，可以看到不同方案如何用不同语言实现、在 Dubbo 中央仓库中，可以通过 Github Action 看到，如何编写一个系统的，全面的项目测试等等。以上种种，或许可以在学校中见到，但是深度和广度是无法比拟的。 25 | 26 | 3. 锻炼自己的表达能力； 27 | 28 | - 在维护开源项目期间，一些 Issue 和 PR(Pull Request) 的回复都会使用英文表达。如何能够简单，准确的用英文表达出对于问题的看法也是一种能力； 29 | - 开源项目中，经常会有周会或者方案评审的会议等。在参加会议中，需要很明确的讲清楚自己的方案或者自己的想法、观点等等。 30 | 31 | 4. 认识更多志同道合、优秀的人； 32 | 33 | - 这里就不用过多描述了，项目的 Commiter，帮你 review 代码的人等等都是非常好的导师。 34 | 35 | 5. 简历加分； 36 | 37 | - 说到这里，大多就是和利益驱动相关（相信大多数都是这样）了。在一个开源项目中，能够获得 Commiter （或者其他身份）的提名，就说明——你在对项目做出的贡献已经被大家认可，得到了同一个项目中其他贡献者的肯定。面试相关工作岗位的时候，就是强有力的竞争条件之一。比如说现在对校招生要求有微服务经验，如果你是 Apache Dubbo 或者 Spring Cloud 相关项目的 Commiter，肯定非常加分。 38 | 39 | - 参与开源也从侧面表达出来一个信息——你有非常好的自学能力和探索（求知欲望）能力。 40 | - 探索能力：刚开始接触开源，肯定会花费大量时间（自己摸索的情况下）。如何参与这件事情，门路在哪？ 41 | - 自学能力：入门之后，怎么去做好这件事情，找到项目中的问题并参与调研与修复。 42 | 43 | 当然，除了上述罗列出来的几种好处之外，还有非常多的地方。这里一一列举并不能很真切的体会到，**迈出第一步，实践了的人才更有发言权。** 44 | 45 | # 如何参与开源，有哪些途径？ 46 | 47 | > 承接上文，都说万事开头难，那么如何才能迈出这意义非凡的第一步呢？ 48 | 49 | 作为二本科班生来说：学校学习到的东西，接触到的资源肯定是不如 985，211 院校的，这是个不争的事实。或许因为高考失利、或者因为条件限制等等其他因素成为了二本学生。但是这都不是问题，如何在被动环境中提高自己，是我们需要关注的。除了 哔哩哔哩、Youtube 等上面的免费视频课程之外，开源项目可能是最好的选择。不管是出于利益还是出于兴趣爱好出发，在我看来：参与开源都是值得鼓励的！ 50 | 51 | 如果你现在的情况是：想提升自己的编程水平、想认识更多志同道合的，优秀的人、想简历加分但是又苦于当前囧况（技术水平薄弱，资源有效等等）无从下手，或许下面的内容会给你带来一点启发。 52 | 53 | 下面一一列举一下（会以作者认为的难度依次递增）： 54 | 55 | > 这里假设你已经有了自己心仪的项目或者社区。如果没有，可以根据自己的学习方向或者兴趣方向选择。 56 | > 57 | > **直接关注 Github Issues 列表可能是一个好的选择，这里就不对这种方式介绍了！** 58 | 59 | 1. 交流群组： 60 | 61 | - 项目 README.md 文档、Github Wiki 或者 官网都会贴出社区相关的讨论群组，可能以钉钉、Slack、邮件列表等形式出现。找到之后加入，关注一些交流群别人提出的问题，关注上下文，本地复现、研究并解决。（作为一个技术水平相对薄弱的学生而言，直接关注整个项目可能是非常吃力的） 62 | - 积极参与社区周会的讨论，不懂得地方可以向主讲人提问。（00 后可能大多数都是社恐分子，我也是）我的做法是先去网上查，能够理解固然最好，理解不了可以私下加联系方式提问（这里最好是能整理下自己得问题，不要浪费时间，用最短的时间做最高效的事情是一种比较好的方式）。 63 | - 找到更多伙伴——同一时间段，可能和你有相同想法的人很多，共同加入了一个交流群。相互扶持总好过单打独斗！当然，这种方式看机会也看缘分。 64 | 65 | 2. 学长学姐带： 66 | 67 | - 这种方式可能是最适合当前情况下的你。但是为什么把这种方式排在第二呢？因为这样的学长学姐可能不存在、或者他们没过多时间带着你做。当然如果他们愿意帮助你，你也表达了自己的意愿。这是非常好的，可以带来很多他们的经验，少走许多弯路。 68 | 69 | 3. 周边生态项目： 70 | 71 | - 一个好的开源项目，往往社区周边生态都是非常完善的。例如上文中提到的 Kubernets，Dubbo 等等。可以从周边生态开始，慢慢融入社区，做出自己的贡献。这种方式下需要满足几种条件，因此我将其放到了第三的位置上。 72 | 1. 对于官网项目：有文档书写经验，前端经验，刚开始可以以文档纠错为主，逐渐适应社区。（这里具体怎么做呢？说一下我认为比较好的一种方式：边看文档边动手——官网文档中会有项目和其他组件的使用、exmaple 的介绍等等。可以按照文档说的去本地复现，即加深了对项目的理解，又能逐步参与到社区中。） 73 | 2. 对于 awesome-XXX 项目：顾名思义，从名字中就可以看出他的作用。这里项目仓库存放的主要是和项目有关的学习资源，最佳实践等等。学习一个东西肯定要先从怎么使用开始，会使用了才能去深入研究并改进他。（这里也体现出了另外一种参与开源项目的方式，从使用中发现问题进而解决问题！） 74 | 3. 其他仓库类似，但是要求相对较高。例如 Dubbo-go（Dubbo go 语言的客户端实现）对 Go 语言要求较高。 75 | 76 | 4. OSPP/GSOP： 77 | 78 | > OSPP：Open Source Promotion Plan，每年 3 月份初开始，11 月份结束，GSOP：Google Summer of Code，每年 2 月未开始，9 月份结束。 79 | 80 | 这种大型开源活动，往往是全国乃至全球性的。在参加过程中，有导师指导。可以快速融入开源项目中，活动结束之后项目社区也是希望继续能够在项目中贡献。但是对选手要求较高（二本科班生几乎没竞争力，因此放到了最后一个位置上）。有句古话说得好——笨鸟先飞，可以在感兴趣的社区中贡献一段时间，要是项目有参加 OSPP/GSOP 的名额，或许会被选中。 81 | 82 | 83 | # 其他方式的对比 84 | 85 | 我们生活在信息时代，获取知识，消息的渠道非常之多。大家在平时学习过程中可能会使用浏览器查找一些资源，或者去自媒体网站看一些教程等等。这些都是非常好的获取知识的渠道。那么以上几种方式和开源相比，*孰优*孰劣？相信这是个比较难选择的问题，即在有限的时间、精力内如何利益最大化。 86 | 87 | ## 参与开源和编程比赛的对比 88 | 89 | 1. 各自优势： 90 | 91 | - 参与开源的优势上文已经列举过了，这里就不再过多赘述。 92 | - 编程比赛的优势： 93 | 1. 有钱拿（相信这是最大的优势）； 94 | 2. 有资格证书，比赛完成之后，一般都会颁发证书； 95 | 3. 投入时间/精力相对一段时间内集中。 96 | 97 | 2. 缺点： 98 | 99 | > **任何事物都有两面性，有利必然有弊。** 100 | 101 | - 参与开源的缺点： 102 | 1. 投入时间多，战线长； 103 | 2. 没有直接的经济收入（Github 支持除外）； 104 | 3. 很难在短时间内获得提名。 105 | - 编程比赛的缺点： 106 | 1. 难度大（这是毋庸置疑的，奖金越高的比赛，难度必然越大）； 107 | 2. 对基础要求高（参加项目选题之前，要求必须有相关经验。在短时间内学会项目要求的东西，过于困难了）； 108 | 3. 需要组队（找到水平相当的人去参加比赛，这在二本学校中非常困难，个人体会）。 109 | 110 | 之上呢，是对参加开源和编程比赛进行了大致对比。从中我们可以看出，都有各自的优势和劣势。但是我认为这两者是不冲突的。为什么这样说呢？首先我们要知道编程比赛大的背景，比如最近举办的 《[开放原子开源基金会 x Apache Dubbo，下一代云原生微服务挑战赛](https://github.com/apache/dubbo-kubernetes/issues/150)》便是由 Dubbo 社区组织的比赛，题目也和 Dubbo 开源项目相关。提前参与开源社区，能提前了解开源项目需要的技术栈，认识到更多有相同兴趣的人。对参加比赛也有帮助！ 111 | 112 | 殊途同归，不管是参与比赛也好，参与开源项目也罢。都是为了提升自己，如果有充足时间的前提下，我的建议是参与开源项目！ 113 | 114 | ## 参与开源和 Leetcode 的对比 115 | 116 | 这两者我认为也是不冲突的？之前参与编程比赛不冲突，这里又不冲突？听我分析一波： 117 | 118 | 刷 Leetcode 的目的是什么？（站在我的角度分析） 119 | 120 | 1. 提高编程思维，锻炼基础代码能力； 121 | 2. 应对笔试； 122 | 3. 算法竞赛。 123 | 124 | 不冲突的原因是什么？ 125 | 126 | 1. 学算法，锻炼思维是为了写出更优秀的代码。代码的最终落地应该是写到项目中去，两者应该是属于地基和大楼的关系，地基牢固了，才能保证大楼不会歪斜乃至倒坍。 127 | 2. 开源项目正好是当前可以接触的大型项目，其中有非常多优秀的项目，被应用到生产环境中去。你可以在这里大展拳脚； 128 | 3. 刷题准备面试也一样，笔试成绩通过才能有面试机会。开源项目经验也能简历初筛，面试加分。 129 | 130 | 刷题往往是一个枯燥的过程。一些困难的题目，学习难度是非常大的。这点对比开源是类似的，当有大的 feat 更新时，往往需要很多的调研才能慢慢完成。两者都需要投入大量时间和精力才能获得收益，这点是相似的。 131 | 132 | 因此我认为两者并不冲突，可以一起进行！好的地基，好的大楼都是我们需要的。 133 | 134 | # 文末总结 135 | 136 | 文章中，主要是对参加开源能够获得哪些好处和如何参与开源做了描述，受众人群是二本科班生。我相信受众人群是非常广的。 137 | 138 | 因为个人经历尚浅，只能尽自己所能写出有限的内容。希望你在阅读了本文章之后，能够在如何参与开源上给你一些启发。 139 | -------------------------------------------------------------------------------- /data/financing/financing.tpl: -------------------------------------------------------------------------------- 1 | #!yaml-readme -p data/financing/*.yaml --output financing.md 2 | 越来越多的商业公司依靠开源得到了融资，欢迎对开源商业化感兴趣的朋友们一起维护下面的列表（融资记录 {{len .}}）： 3 | 4 | | 日期 | 公司名称 | 融资情况 | 投资方 | 5 | |---|---|---|---| 6 | {{- range $val := .}} 7 | | [{{$val.date}}]({{$val.fullpath}}) | {{$val.name}} | {{$val.summary}} | {{$val.investors}} | 8 | {{- end}} 9 | 10 | ## 名词解释 11 | 12 | |名词|描述| 13 | |---|---| 14 | | VC | Venture Capital，即风险投资 | 15 | | PE | Private Equity，即私募股权融资 | 16 | | FA | Financial Advisor，财务顾问 | 17 | -------------------------------------------------------------------------------- /data/financing/item-1.yaml: -------------------------------------------------------------------------------- 1 | date: '2017年8月' 2 | name: '[Zilliz](https://github.com/milvus-io)' 3 | summary: '数千万元天使轮' 4 | investors: '晨兴资本，松禾资本，云启资本，靖亚资本' 5 | domain: '数据库' 6 | -------------------------------------------------------------------------------- /data/financing/item-10.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年4月' 2 | name: '飞轮科技' 3 | summary: '天使轮和天使 + 轮，超 3 亿元' 4 | investors: 'IDG 资本、红杉中国等 VC' 5 | -------------------------------------------------------------------------------- /data/financing/item-11.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年底' 2 | name: '[燧炻创新](https://fydeos.com/content/career/)' 3 | summary: 'Pre-A 数千万元' 4 | investors: '青云科技领投' 5 | domain: '操作系统' 6 | -------------------------------------------------------------------------------- /data/financing/item-12.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年' 2 | name: '[燧炻创新](https://fydeos.com/content/career/)' 3 | summary: '数百万元' 4 | investors: '北京佰才邦技术有限公司领投，北京鲸鲮信息系统技术有限公司与北京即联即用创业投资有限公司跟投' 5 | domain: '操作系统' 6 | -------------------------------------------------------------------------------- /data/financing/item-13.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年6月' 2 | name: '[天谋科技（Timecho）](https://www.timecho.com/)' 3 | summary: '近亿元人民币天使轮融资' 4 | investors: '红杉中国领投，考拉基金、戈壁创投、云智慧共同跟投' 5 | domain: '数据库' 6 | -------------------------------------------------------------------------------- /data/financing/item-14.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年7月14日' 2 | name: '[北京白鲸开源信息科技有限公司](https://dolphinscheduler.apache.org/)' 3 | summary: '数千万元' 4 | investors: '凯泰资本领投、蓝驰创投跟投，沧澜担任本轮独家财务顾问' 5 | domain: 'DataOps' 6 | -------------------------------------------------------------------------------- /data/financing/item-15.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年3月23日' 2 | name: '[支流科技](https://www.apiseven.com/)' 3 | summary: 'A 轮，数百万美元' 4 | investors: '顺为资本领投、真格基金跟投的' 5 | domain: 'API 网关' 6 | -------------------------------------------------------------------------------- /data/financing/item-16.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年2月4日' 2 | name: '[支流科技](https://www.apiseven.com/)' 3 | summary: '[Pre-A 轮，百万美元](https://www.infoq.cn/article/2Ntyh07rOjXxGO6YeJP6)' 4 | investors: '真成投资领投，真格基金跟投' 5 | domain: 'API 网关' 6 | -------------------------------------------------------------------------------- /data/financing/item-17.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年08月' 2 | name: '[星汉未来](https://github.com/galaxy-future)' 3 | summary: '天使轮，数百万美元' 4 | investors: '初心资本，明势资本' 5 | domain: '' 6 | -------------------------------------------------------------------------------- /data/financing/item-18.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年6月18日' 2 | name: '[支流科技](https://www.apiseven.com/)' 3 | summary: '[A+ 轮](https://segmentfault.com/a/1190000040195514)，数百万美元' 4 | investors: '经纬中国领投，顺为资本和真格基金跟投' 5 | domain: 'API 网关' 6 | -------------------------------------------------------------------------------- /data/financing/item-19.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年1月17日' 2 | name: '[深势科技](https://github.com/deepmodeling)' 3 | summary: 'B 轮，数千万美元' 4 | investors: '源码资本、启明创投共同领投，老股东高瓴创投、经纬创投等继续加码，奇迹资本担任本轮融资的独家FA' 5 | domain: 'AI' 6 | -------------------------------------------------------------------------------- /data/financing/item-2.yaml: -------------------------------------------------------------------------------- 1 | date: '2018年5月' 2 | name: '[Zilliz](https://github.com/milvus-io)' 3 | summary: 'A 轮 1000 万美元' 4 | investors: '晨兴资本，松禾资本，云启资本，靖亚资本' 5 | domain: '数据库' 6 | -------------------------------------------------------------------------------- /data/financing/item-20.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年2月25日' 2 | name: '[Allegro 熹乐科技](https://github.com/yomorun/)' 3 | summary: '天使轮，300 万美元' 4 | investors: '耀途资本独投，源合资本担任独家财务顾问' 5 | domain: '' 6 | -------------------------------------------------------------------------------- /data/financing/item-21.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年2月10日' 2 | name: '[澜舟科技](https://github.com/Langboat)' 3 | fullname: '北京澜舟科技有限公司' 4 | summary: 'Pre-A轮，近亿元' 5 | investors: '联想创投、斯道资本共同领投和创新工场跟投' 6 | domain: '' 7 | -------------------------------------------------------------------------------- /data/financing/item-22.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年1月' 2 | name: '[SphereEx](https://www.sphere-ex.com/)' 3 | fullname: '北京思斐软件技术有限公司' 4 | summary: 'Pre-A轮，近千万美元' 5 | investors: '嘉御资本领投，红杉中国种子基金、初心资本、指数创投跟投，指数资本担任独家财务顾问' 6 | domain: '' 7 | -------------------------------------------------------------------------------- /data/financing/item-23.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年11月22日' 2 | name: '[Jina AI](https://github.com/jina-ai/)' 3 | fullname: '北京极纳科技有限公司' 4 | summary: 'A轮，3000 万美元' 5 | investors: '新投资方美国投资机构 Canaan Partners 领投，Mango Capital 以及原投资方 GGV纪源资本、SAP.iO 和云启资本参与跟投' 6 | domain: '' 7 | -------------------------------------------------------------------------------- /data/financing/item-24.yaml: -------------------------------------------------------------------------------- 1 | date: '2020年11月16日' 2 | name: '[欧若数网](https://github.com/vesoft-inc)' 3 | fullname: '杭州欧若数网科技有限公司' 4 | summary: 'Pre-A+ 轮，近千万美元' 5 | investors: '源码资本领投，经纬中国、红点创投和中国基金本轮跟投' 6 | domain: '' 7 | -------------------------------------------------------------------------------- /data/financing/item-25.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年5月24日' 2 | name: '[涛思数据](https://github.com/taosdata)' 3 | fullname: '北京涛思数据科技有限公司' 4 | summary: 'B轮，4700万美元' 5 | investors: '经纬中国领投，红杉资本中国基金、GGV纪源资本、指数资本跟投，指数资本担任独家财务顾问' 6 | domain: '物联网' 7 | -------------------------------------------------------------------------------- /data/financing/item-26.yaml: -------------------------------------------------------------------------------- 1 | date: '2019年07月17日' 2 | name: '[Second State](https://github.com/second-state)' 3 | fullname: 'Second State' 4 | summary: 'A 轮，300 万美元' 5 | investors: '海纳亚洲资金' 6 | domain: '区块链' 7 | -------------------------------------------------------------------------------- /data/financing/item-27.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年08月25日' 2 | name: '[Zilliz](https://github.com/milvus-io)' 3 | summary: '6000 万美元，B+ 轮' 4 | investors: '沙特阿美（Aramco Ventures）旗下的多元化成长基金 Prosperity7 Ventures 领投，老股东淡马锡旗下 Pavilion Capital 、高瓴创投、五源资本和云启资本继续加注，多维资本担任独家财务顾问' 5 | domain: '数据库' 6 | -------------------------------------------------------------------------------- /data/financing/item-28.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年09月06日' 2 | name: '[ILLA Cloud艾拉云科](https://github.com/illa-family)' 3 | summary: '数百万美元，天使轮融资' 4 | investors: '源码一粟，高瓴创投联合领投' 5 | domain: '效能' 6 | -------------------------------------------------------------------------------- /data/financing/item-29-primihub.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年11月1日' 2 | name: '[原语科技](https://github.com/primihub)' 3 | summary: '数千万人民币，天使轮' 4 | investors: '泰岳梧桐资本、相泰投资' 5 | domain: '隐私计算' 6 | -------------------------------------------------------------------------------- /data/financing/item-3.yaml: -------------------------------------------------------------------------------- 1 | date: '2019年' 2 | name: '[StreamNative](https://streamnative.io/)' 3 | summary: '天使轮' 4 | investors: '红杉中国' 5 | -------------------------------------------------------------------------------- /data/financing/item-30-vesoft.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年9月' 2 | name: '[欧若数网](https://github.com/vesoft-inc)' 3 | fullname: '杭州欧若数网科技有限公司' 4 | summary: '数千万美元，A 轮融资' 5 | investors: '经纬创投' 6 | domain: '图数据库' 7 | -------------------------------------------------------------------------------- /data/financing/item-31-vesoft.yaml: -------------------------------------------------------------------------------- 1 | date: '2019年3月' 2 | name: '[欧若数网](https://github.com/vesoft-inc)' 3 | fullname: '杭州欧若数网科技有限公司' 4 | summary: '300 万美元，天使轮' 5 | investors: '经纬投资领投' 6 | domain: '图数据库' 7 | -------------------------------------------------------------------------------- /data/financing/item-32.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年03月17日' 2 | name: '和鲸科技' 3 | fullname: '上海和今信息科技有限公司' 4 | summary: '数千万元，A+ 轮' 5 | investors: '考拉基金领投，翊翎资本、线性资本、中驰源道、五源资本等跟投' 6 | domain: '数据科学协同' 7 | -------------------------------------------------------------------------------- /data/financing/item-33.yaml: -------------------------------------------------------------------------------- 1 | date: '2019年11月08日' 2 | name: '和鲸科技' 3 | fullname: '上海和今信息科技有限公司' 4 | summary: '数百万美元，A 轮' 5 | investors: '晨兴资本领投' 6 | domain: '数据科学协同' 7 | -------------------------------------------------------------------------------- /data/financing/item-34.yaml: -------------------------------------------------------------------------------- 1 | date: '2023年6月' 2 | name: '飞轮科技' 3 | summary: '数亿元' 4 | investors: '数亿元' 5 | -------------------------------------------------------------------------------- /data/financing/item-35.yaml: -------------------------------------------------------------------------------- 1 | year: 2021 2 | date: '2021年10月' 3 | name: '[快猫星云](https://github.com/flashcatcloud)' 4 | summary: '天使轮' 5 | investors: '高瓴创投，初心资本' 6 | domain: '' 7 | -------------------------------------------------------------------------------- /data/financing/item-4.yaml: -------------------------------------------------------------------------------- 1 | date: '2020年8月' 2 | name: '[StreamNative](https://streamnative.io/)' 3 | summary: 'Pre-A 轮 数百万' 4 | investors: '源码资本领投、红杉中国跟投' -------------------------------------------------------------------------------- /data/financing/item-5.yaml: -------------------------------------------------------------------------------- 1 | date: '2020年11月13日' 2 | name: '[Zilliz](https://github.com/milvus-io)' 3 | summary: 'B 轮 4300 万美元' 4 | investors: '高瓴创投领投，挚信资本和 Pavilion Capital 跟投' 5 | -------------------------------------------------------------------------------- /data/financing/item-6.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年' 2 | name: '[Datafuse Labs](https://github.com/datafuselabs)' 3 | summary: '种子轮' 4 | investors: '华创资本领投、九合创投跟投' 5 | -------------------------------------------------------------------------------- /data/financing/item-7.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年' 2 | name: '[Datafuse Labs](https://github.com/datafuselabs)' 3 | summary: '天使轮' 4 | investors: '高瓴创投领投，老股东华创资本、九合创投跟投' 5 | -------------------------------------------------------------------------------- /data/financing/item-8.yaml: -------------------------------------------------------------------------------- 1 | date: '2021年9月14日' 2 | name: '[StreamNative](https://streamnative.io/)' 3 | summary: 'A 轮 2300 万美元' 4 | investors: '沙特阿美旗下多元化风投基金 Prosperity7 Ventures 与华泰证券旗下另类投资子公司华泰创新联合领投，老股东红杉中国、源码资本继续加码' 5 | -------------------------------------------------------------------------------- /data/financing/item-9.yaml: -------------------------------------------------------------------------------- 1 | date: '2022年2月7日' 2 | name: '[太极图形](https://github.com/taichi-dev)' 3 | summary: '[5000 万美元 A 轮](https://mp.weixin.qq.com/s/4PjdQuwX4HRtm7z_xghQvA)' 4 | investors: '由源码资本、GGV 纪源资本、BAI 资本联合领投，老股东红杉中国持续加码' 5 | -------------------------------------------------------------------------------- /encourage-community-members.md: -------------------------------------------------------------------------------- 1 | # 如何通过适当的机制给予社区贡献者一定的激励 2 | 首先，需要明确的是：激励不能等同于劳务报酬，更加不是“外快”，激励是要对有意愿和动力的贡献者加以认可，给予一定的物质反馈。 3 | 4 | 激励的形式，可以有：社区活动相关的差旅补助、周边礼品、社区荣誉、社区重要角色提名、资金赞助等。 5 | 6 | ## 差旅补助 7 | 对于在社区中有重大贡献的，在类似于社区年度大会中，给予一定的差旅报销额度。对此，我们需要解决下面的问题： 8 | 9 | * 什么算是重大贡献 10 | * 差旅报销额度 11 | * 同一贡献者给予补助的周期（例如：不可连续） 12 | * 资金来源、资金池的管理 13 | 14 | ## 周边礼品 15 | 16 | ## 社区荣誉 17 | 常见的社区荣誉有：Top Ambassdor、Top Contributor、New Ambassdor 18 | 19 | ## 重要角色提名 20 | 根据社区的实际组织架构，这里的重要角色可以有：SIG Co-leader、TOC member 21 | 22 | 对于已经在社区中作出重大贡献（不局限于代码），尤其是已经体现出来一定的领导力的贡献者，社区应该及时提名担任更加重要的角色。这对于社区和贡献者都有着重要的意义。 23 | 24 | ## 资金赞助 25 | 26 | # 如何让外部贡献者更加有动力 27 | 贡献者包括两类：游客（偶发性、简单的）、实际用户。对于这两种贡献者都要加以重视，但需施以不同的策略。 28 | 29 | ## 游客 30 | 最核心的是——要把参与贡献的难度降到最低，让短暂、偶发性贡献成为可能。 31 | 32 | ## 实际用户 33 | 社区的实际用户参与贡献是有切实的、可持续的动力的，这应该成为我们重点。 -------------------------------------------------------------------------------- /encourage.md: -------------------------------------------------------------------------------- 1 | > 目标读者：了解参与开源的益处，希望能激励更多团队成员参与开源。 2 | 3 | 如果你已经深刻地明白了参与开源的各种益处，那么，该如何鼓励、激励团队中其他成员积极地参与到开源社区建设中呢。 4 | 5 | 我们首先需要认识到，开源项目和闭源项目的协作方式上，有非常大的区别。单纯地给团队成员分享参与开源的好处，往往是收效甚微。每个人的过往经历各不相同，思维方式，认知等都有着不同程度的差异。甚至，在特定的阶段中，并不是每个人都适合参与开源。因此，设定一个合适的激励政策就非常重要了，需要通过挖掘、鼓励、激励的方式让一部分人先动起来，让这部分人尝到了好处、感受到开源的氛围。然后，再进一步巩固参与开源的成果。 6 | 7 | 参与开源并不只有提交代码这一种方式，有参与开源的兴趣、热情就成功了一半。每个人都可以应该先做自己擅长的事情，以增加参与的自信心。 8 | 9 | ## 积分制度 10 | 在条件允许的情况下，可以参考如下的激励制度： 11 | 12 | 实行参与开源积分制，并定期（或不定期）根据积分来兑换奖励 13 | 14 | * 公开演讲 15 | * meetup 演讲，200 积分 16 | * 技术峰会、Conference，500 积分 17 | * 全球大型技术峰会，800 积分 18 | * 对于使用第二语言（非母语）进行分享的情况，额外增加 100 积分 19 | * 向上游社区提交 PR 20 | * 普通缺陷修复、小的功能点，100 积分 21 | * 重大缺陷、大的功能，300 积分 22 | * 以组织者、志愿者等身份参与社区活动 23 | * 在开源社区、开源基金会中被选为 Ambassador， 200 积分 24 | * 在开源社区、开源基金会上给予年度性的奖励（例如：最佳贡献者、最佳布道者等），200～500 积分 25 | * 在其他社区担任 SIG Leader 等角色，500 积分 26 | * 成为上游社区项目的 Member，500 积分 27 | * 成为上游社区项目的 Maintainer，1000 积分 28 | * 此处，可根据不同的上游社区的要求的高低给予不同的积分 29 | 30 | 以上的活动建议以及积分数只是方向性指导，具体实施时应根据具体情况来定。建议 1 积分对应 1 人民币，达到 1000 积分后，可以消费积分来购买等价的商品，团队给予全额报销。 31 | 32 | > 开源社区内，非常需要跨技能的合作，例如：运营、研发、测试等角色之间互相了解、配合。因此，建议对于跨职能的贡献行为予以鼓励和支持。同样地，对于运营、产品等职位的同学，公开演讲在某些团队中如果是作为本职工作的话，不建议参与积分。 33 | 34 | ## 方向选择 35 | 为了让大家在选择上游社区时，更加聚焦、对团队帮忙更大，建议优先选择如下的项目： 36 | 37 | * 团队项目中所依赖的核心上游项目 38 | * 团队相关领域的，托管到 Linux Foundation、Apache 等大型国际开源基金会的项目 39 | * 主仓库的贡献 40 | 41 | > 对于和团队项目的技术栈、领域不相关的开源上游项目，不建议予以积分奖励。只有让团队成员积极地参与到相关领域的上游社区，才能让激励制度正向循环。 42 | 43 | 在具体实施时，建议明确地列出来希望大家参与的上游开源项目，鼓励大家新增上游项目并给出理由。 44 | 45 | ## 总结交流 46 | 互相感染，要远比说教、任务安排来的效果要好。设定一个周期，让大家互相交流参与上游社区的经验、成果，甚至可以晒晒各自的积分。例如，可以是每个季度进行一次交流。 47 | 48 | ## 导师制度 49 | 集体交流，不合适太频繁。我们需要更多小的、高效的交流，导师制度会让参与开源社区经验较少的同学少走弯路，更加自信。 50 | 51 | 而且，传帮带、师徒关系，会让团队成员之间合作更加默契。在条件允许的情况下，设置适合的导师制度。 52 | 53 | 开源协作中没有身份、没有特权，不要等着被领导，每个人都是解决问题的中坚力量。 54 | -------------------------------------------------------------------------------- /english.md: -------------------------------------------------------------------------------- 1 | 英文虽然不是参与开源的必要能力，但却与是否可以深度参与开源有着很大的关系。如果你希望能进一步提高自己的英文水平的话， 2 | 可以试试下面给出的一些资料，也欢迎帮忙补充！ 3 | 4 | | 名称 | 形式 | 适合级别 | 5 | |---|---|---| 6 | | [All Ears English](https://www.xiaoyuzhoufm.com/podcast/5e2946c5418a84a0463972a4) | 播客，全英文 | 中级 | 7 | | [潘吉 Jenny 告诉你-学英语聊美国-开言英语](https://www.xiaoyuzhoufm.com/podcast/5e285480418a84a046275af8) | 播客，中英混合 | 初级 | 8 | -------------------------------------------------------------------------------- /etiquette.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LinuxSuRen/open-source-best-practice/7c36f9800d9e1818df3ceb1437f57968ca89d380/etiquette.md -------------------------------------------------------------------------------- /event.md: -------------------------------------------------------------------------------- 1 | 为达成特定目标，开源社区、组织、个人往往会采用活动（Event）的形式，将相关人群聚集在一起，借助主题分享、动手实践、成果展示等来增强相互间的联系，亦或是宣传、推广特定信息。 2 | 3 | 从物理空间上来看，可以将活动划分为两大类：线下活动、线上活动（online）。 4 | 5 | 从时间跨度上来看，常见有：半天、一整天、三天、以及更长时间范围的活动。诸如 Meetup、沙龙等通常是半天的时间；而某某峰会可能会持续一整天或者更长一点的时间；三天左右的活动往往会是面向国际的大型会议，人数可能也会超过 1000 人；而那种跨越一个季度甚至更久的活动，多半是线上的、需要持续参与的活动，例如：开源之夏、Google Summer of Code。 6 | 7 | 从面向的主要受众来看，也会有很多不同的情况，例如：面向企业、商业的，面向生态，面向开发者，面向最终用户（end user）等。 8 | 9 | 从活动主办方来看，可能会是政府、行业协会、商业公司、社区、个人等发起或主办。 10 | 11 | ## 写给活动组织者 12 | 鉴于本人没有组织大型（超过一天）会议的经验，本文仅提供小型活动的一些建议。 13 | 14 | ### 线下活动 15 | 线下活动提供的是一种面对面交流的形式，可以让参会者之间产生形象的、深刻的影响。线下活动有着明显的优势，但同时也需要活动组织则付出更多的精力。 16 | 17 | 以下是线下活动大致会涉及到的一些要素和类型（可重叠）： 18 | 19 | | 要素/活动类型 | 聚会 | 分享 | 互动 | 直播 | 20 | |---|---|---|---|---| 21 | | 场地 | 人数决定场地大小 | 投影（或电视），音响、麦克风，翻页笔 | 扇形座位摆放便于互动 | 摄像机、捕音设备 | 22 | | 宣传 | 聚会形式 | 提前确认讲师分享题目以及讲师背景介绍 | | 给出直播观看渠道 | 23 | | 人员 | 签到，拍照 | 跟踪讲师分享资料，现场时间把控 | 主持人，抽奖 | 直播技术保障 | 24 | | 报名 | 提供清晰的活动描述，背景等 | 如有需要可以提供 CFP | | | 25 | 26 | 场地无疑是线下活动最重要的要素之一，不同的活动类型，对场地有着不同的要求。首先，选择交通便利的位置，避免那些路标不清晰的地方。如果场地物业有门禁要求的话，提前与场地提供方约定进入产地的方法，例如：入口安排专人接待，与前台约定进门暗号、口令等，佩戴特定胸牌。为方便参会者及时找到会场房间，可以在入口处、转角处摆放易拉宝或张贴指路牌。接下来就是场地房间的配置了，有演讲诉求的，需要确认投影仪、音响、麦克风等设备可用，以及可容纳的人数。另外，对于驱车到会场的参会者，场地是否支持停车位也非常重要。 27 | 28 | 按照活动规模的预期，可以选择不同的宣传策略、渠道。例如：小规模的、随缘的聚会活动，可能在私域社交圈宣传下即可，诸如在微信朋友圈发布。而有一定参会人数期望的话，需要适当地加强对宣传的重视，可以选择诸如：[活动行](https://www.huodongxing.com/)、[百格活动](https://www.bagevent.com/cn/)、[Meetup](https://www.meetup.com/) 等专业活动网站，社区（或组织）的社交媒体账号发布活动，联合具有相关性的社区（或组织）转发活动信息（这时候可以与对方进行资源交换，例如：Logo、品牌露出等）。 29 | 30 | 通常可以提前三周左右对活动进行宣传，分别在第一周、第三周发布宣传文章。活动结束后，可以再发布一篇活动回顾的文章，内容可以包括：活动当天情况概述、到会人数、照片、感谢对活动支持的人或组织。如果是系列活动，或者多场活动之间有着强的相关性的话，建议有一个集中的地址可以看到每一期的活动信息，以方便后了解到活动的人翻阅。 31 | 32 | 人员组织方面，活动发起人需要对活动进行统筹安排，确保活动的关键环节没有被遗漏。为避免发生遗漏情况发生，建议每个重要环节都有专人负责，活动发起人（或出品人）与具体环节的负责人进行对接。 33 | 34 | * 嘉宾邀请，需要跟踪以及收集嘉宾的分享文稿，必要时通过微信、电话等方式提醒嘉宾交稿时间。 35 | * 现场主持人，出品人往往是比较适合充当这个角色。 36 | * 拍照、摄影以及后期整理。 37 | * 现场签到，现场引导。 38 | * 直播技术保障。 39 | * 嘉宾演讲时间控制，可以考虑用沙漏，或者是志愿者在会场后面举牌的方式。 40 | 41 | 对于报名环节，通常专业的活动发布平台会同时支持报名、统计等功能。如果没有采用专业活动平台的话，也可以考虑问卷系统报名（例如：[腾讯问卷](https://wj.qq.com)）。按照经验来看，一般热度的线下活动，实际到场人数会占到报名人数的 50%。也就是说，如果希望能有 30 人到场的话，尽量确保有 60 左右的报名人数。 42 | 43 | 礼品、茶歇。主办方可以根据自身条件，提供适当的茶歇，例如：矿泉水、饮料、点心、面包等。也可以考虑寻找活动支持方提供。常见一些周边礼品，包括：T恤、开源项目贴纸、书包、帆布袋、书籍等等。 44 | 45 | 有直播诉求的活动，主要考虑现场设备、直播工具、直播平台等问题。现场设备，可以考虑配置面向参会者以及演讲嘉宾的摄像头，以及更好拾音效果的领夹麦克风。常见的直播平台有：哔哩哔哩、视频号等。如果想要使用免费的直播推流工具，可以考虑 [OBS](https://github.com/obsproject/obs-studio) 这个开源的工具。 46 | 47 | 活动当天的流程参考： 48 | 49 | * 活动组织者、志愿者，至少提前一个小时到达现场，完成场地布置、设备调试等 50 | * 场地引导、参会签到 51 | * 主持人开场（1 分钟） 52 | * 活动主体 53 | * 适当的中场休息 54 | * 选择人数最多的时候（可能会有人提前离场），合影留念 55 | * 活动结束后，清理垃圾，座位恢复摆放等 56 | 57 | > 会议开始前，需要提醒参会者主动将喝完的饮料瓶、吃完的食品包装袋扔到指定垃圾箱，保持会场干净、整洁。 58 | > 如果条件允许的话，可以提供类似于沙漏、计时器等工具来提示讲师的演讲时长。但这些提示工具需要摆放在讲师正对面。 59 | > 为了能够持续改进活动体验，在结束后邀请大家填写匿名反馈问卷。 60 | > 避免卷入太多角色、利益方，否则会让活动本身变得不再单纯，进而四不像 61 | > 讲师的选择问题上，尽量只包含一位经验不丰富的讲师 62 | 63 | ### 线上活动 64 | TODO 65 | 66 | ## 写给活动参与者 67 | 我们每个人的精力都是有限而且宝贵的，了解活动的性质以及相关背景信息是非常有必要的。 68 | 69 | 比如，对于希望了解、学习以及应用技术的同学，建议尽量避开面向商业、生态的会议，这一类会议中大比例的内容不会提及具体的技术内容，商业产品推广、广告内容会让你倍感失落。 70 | -------------------------------------------------------------------------------- /financing.md: -------------------------------------------------------------------------------- 1 | > This file was generated by [financing.tpl](financing.tpl) via [yaml-readme](https://github.com/LinuxSuRen/yaml-readme), please don't edit it directly! 2 | 3 | 越来越多的商业公司依靠开源得到了融资，欢迎对开源商业化感兴趣的朋友们一起维护下面的列表（融资记录 35）： 4 | 5 | | 日期 | 公司名称 | 融资情况 | 投资方 | 6 | |---|---|---|---| 7 | | [2023年6月](data/financing/item-34.yaml) | 飞轮科技 | 数亿元 | 数亿元 | 8 | | [2022年9月](data/financing/item-30-vesoft.yaml) | [欧若数网](https://github.com/vesoft-inc) | 数千万美元，A 轮融资 | 经纬创投 | 9 | | [2022年7月14日](data/financing/item-14.yaml) | [北京白鲸开源信息科技有限公司](https://dolphinscheduler.apache.org/) | 数千万元 | 凯泰资本领投、蓝驰创投跟投，沧澜担任本轮独家财务顾问 | 10 | | [2022年6月](data/financing/item-13.yaml) | [天谋科技（Timecho）](https://www.timecho.com/) | 近亿元人民币天使轮融资 | 红杉中国领投，考拉基金、戈壁创投、云智慧共同跟投 | 11 | | [2022年4月](data/financing/item-10.yaml) | 飞轮科技 | 天使轮和天使 + 轮，超 3 亿元 | IDG 资本、红杉中国等 VC | 12 | | [2022年2月7日](data/financing/item-9.yaml) | [太极图形](https://github.com/taichi-dev) | [5000 万美元 A 轮](https://mp.weixin.qq.com/s/4PjdQuwX4HRtm7z_xghQvA) | 由源码资本、GGV 纪源资本、BAI 资本联合领投，老股东红杉中国持续加码 | 13 | | [2022年2月25日](data/financing/item-20.yaml) | [Allegro 熹乐科技](https://github.com/yomorun/) | 天使轮，300 万美元 | 耀途资本独投，源合资本担任独家财务顾问 | 14 | | [2022年2月10日](data/financing/item-21.yaml) | [澜舟科技](https://github.com/Langboat) | Pre-A轮，近亿元 | 联想创投、斯道资本共同领投和创新工场跟投 | 15 | | [2022年1月17日](data/financing/item-19.yaml) | [深势科技](https://github.com/deepmodeling) | B 轮，数千万美元 | 源码资本、启明创投共同领投，老股东高瓴创投、经纬创投等继续加码，奇迹资本担任本轮融资的独家FA | 16 | | [2022年1月](data/financing/item-22.yaml) | [SphereEx](https://www.sphere-ex.com/) | Pre-A轮，近千万美元 | 嘉御资本领投，红杉中国种子基金、初心资本、指数创投跟投，指数资本担任独家财务顾问 | 17 | | [2022年09月06日](data/financing/item-28.yaml) | [ILLA Cloud艾拉云科](https://github.com/illa-family) | 数百万美元，天使轮融资 | 源码一粟，高瓴创投联合领投 | 18 | | [2022年08月25日](data/financing/item-27.yaml) | [Zilliz](https://github.com/milvus-io) | 6000 万美元，B+ 轮 | 沙特阿美（Aramco Ventures）旗下的多元化成长基金 Prosperity7 Ventures 领投，老股东淡马锡旗下 Pavilion Capital 、高瓴创投、五源资本和云启资本继续加注，多维资本担任独家财务顾问 | 19 | | [2022年03月17日](data/financing/item-32.yaml) | 和鲸科技 | 数千万元，A+ 轮 | 考拉基金领投，翊翎资本、线性资本、中驰源道、五源资本等跟投 | 20 | | [2021年底](data/financing/item-11.yaml) | [燧炻创新](https://fydeos.com/content/career/) | Pre-A 数千万元 | 青云科技领投 | 21 | | [2021年9月14日](data/financing/item-8.yaml) | [StreamNative](https://streamnative.io/) | A 轮 2300 万美元 | 沙特阿美旗下多元化风投基金 Prosperity7 Ventures 与华泰证券旗下另类投资子公司华泰创新联合领投，老股东红杉中国、源码资本继续加码 | 22 | | [2021年6月18日](data/financing/item-18.yaml) | [支流科技](https://www.apiseven.com/) | [A+ 轮](https://segmentfault.com/a/1190000040195514)，数百万美元 | 经纬中国领投，顺为资本和真格基金跟投 | 23 | | [2021年5月24日](data/financing/item-25.yaml) | [涛思数据](https://github.com/taosdata) | B轮，4700万美元 | 经纬中国领投，红杉资本中国基金、GGV纪源资本、指数资本跟投，指数资本担任独家财务顾问 | 24 | | [2021年3月23日](data/financing/item-15.yaml) | [支流科技](https://www.apiseven.com/) | A 轮，数百万美元 | 顺为资本领投、真格基金跟投的 | 25 | | [2021年2月4日](data/financing/item-16.yaml) | [支流科技](https://www.apiseven.com/) | [Pre-A 轮，百万美元](https://www.infoq.cn/article/2Ntyh07rOjXxGO6YeJP6) | 真成投资领投，真格基金跟投 | 26 | | [2021年11月22日](data/financing/item-23.yaml) | [Jina AI](https://github.com/jina-ai/) | A轮，3000 万美元 | 新投资方美国投资机构 Canaan Partners 领投，Mango Capital 以及原投资方 GGV纪源资本、SAP.iO 和云启资本参与跟投 | 27 | | [2021年11月1日](data/financing/item-29-primihub.yaml) | [原语科技](https://github.com/primihub) | 数千万人民币，天使轮 | 泰岳梧桐资本、相泰投资 | 28 | | [2021年10月](data/financing/item-35.yaml) | [快猫星云](https://github.com/flashcatcloud) | 天使轮 | 高瓴创投，初心资本 | 29 | | [2021年08月](data/financing/item-17.yaml) | [星汉未来](https://github.com/galaxy-future) | 天使轮，数百万美元 | 初心资本，明势资本 | 30 | | [2021年](data/financing/item-7.yaml) | [Datafuse Labs](https://github.com/datafuselabs) | 天使轮 | 高瓴创投领投，老股东华创资本、九合创投跟投 | 31 | | [2021年](data/financing/item-6.yaml) | [Datafuse Labs](https://github.com/datafuselabs) | 种子轮 | 华创资本领投、九合创投跟投 | 32 | | [2021年](data/financing/item-12.yaml) | [燧炻创新](https://fydeos.com/content/career/) | 数百万元 | 北京佰才邦技术有限公司领投，北京鲸鲮信息系统技术有限公司与北京即联即用创业投资有限公司跟投 | 33 | | [2020年8月](data/financing/item-4.yaml) | [StreamNative](https://streamnative.io/) | Pre-A 轮 数百万 | 源码资本领投、红杉中国跟投 | 34 | | [2020年11月16日](data/financing/item-24.yaml) | [欧若数网](https://github.com/vesoft-inc) | Pre-A+ 轮，近千万美元 | 源码资本领投，经纬中国、红点创投和中国基金本轮跟投 | 35 | | [2020年11月13日](data/financing/item-5.yaml) | [Zilliz](https://github.com/milvus-io) | B 轮 4300 万美元 | 高瓴创投领投，挚信资本和 Pavilion Capital 跟投 | 36 | | [2019年3月](data/financing/item-31-vesoft.yaml) | [欧若数网](https://github.com/vesoft-inc) | 300 万美元，天使轮 | 经纬投资领投 | 37 | | [2019年11月08日](data/financing/item-33.yaml) | 和鲸科技 | 数百万美元，A 轮 | 晨兴资本领投 | 38 | | [2019年07月17日](data/financing/item-26.yaml) | [Second State](https://github.com/second-state) | A 轮，300 万美元 | 海纳亚洲资金 | 39 | | [2019年](data/financing/item-3.yaml) | [StreamNative](https://streamnative.io/) | 天使轮 | 红杉中国 | 40 | | [2018年5月](data/financing/item-2.yaml) | [Zilliz](https://github.com/milvus-io) | A 轮 1000 万美元 | 晨兴资本，松禾资本，云启资本，靖亚资本 | 41 | | [2017年8月](data/financing/item-1.yaml) | [Zilliz](https://github.com/milvus-io) | 数千万元天使轮 | 晨兴资本，松禾资本，云启资本，靖亚资本 | 42 | 43 | ## 名词解释 44 | 45 | |名词|描述| 46 | |---|---| 47 | | VC | Venture Capital，即风险投资 | 48 | | PE | Private Equity，即私募股权融资 | 49 | | FA | Financial Advisor，财务顾问 | 50 | -------------------------------------------------------------------------------- /good-first-issue.md: -------------------------------------------------------------------------------- 1 | 开源项目的贡献者群体，大致呈倒金字塔的形态。 2 | 3 | 项目的管理、规划、主要特性开发或重大缺陷的修复，这些通常是由少量核心的贡献者完成，这可以认为是金字塔的顶部驱动。 4 | 5 | 还有一些贡献者，提交记录不是很多，但项目参与度也比较紧密；这类贡献者的数量通常也不少，可以认为是金字塔中间力量。 6 | 7 | 数量最大的部分，是那些有着零星贡献提交记录的贡献者，也正是我们现在讨论的重点：“游客”贡献者。这些“游客”虽然不会贡献重量级的内容，但对一个开源项目而言，同样是有着非常重要的意义： 8 | 9 | * 每一位重要的贡献者都是从“游客”开始的，我们想要增加贡献者的数量和“质量”也要从这里着手 10 | * 源源不断的“游客”加入，可以让项目呈现出繁荣的景象 11 | * 新人友好程度是开源项目的成熟标志之一 12 | 13 | 那么，什么样的 [issue](https://guides.github.com/features/issues/) 可以标记为 `good-first-issue` 呢？从字面上看，这是对新人（初次接触）友好的 issues，也就是对于这类贡献者而言比较容易解决的 issue。 14 | 15 | 因此，判断是否应该把一个 issue 标记为 `good-first-issue` 可以从这两个角度考虑： 16 | 17 | 1. 如何定义“新人”？ 18 | 19 | 1. 如何定义“友好”？这里的“友好”，一方面是指参与流程的清晰（当然，这是更广泛的社区治理的范畴），另一方面是指参与要求的明确 20 | 21 | * 有清晰的技术栈要求 22 | * “新人”和技术水平的高低无关，只表明初次接触某个项目 23 | * 从更加客观的角度来讲，issue 的创建者可以列举出来完成这个 issue 所需要的技能 24 | * 有清晰的上下文描述 25 | * 即使技术水平”高“的贡献者，在不了解 issue 的上下文、背景的前提下，依然是很难去完成 26 | * 解决 issue 需要的技能 27 | * 没有明显（或潜在）的时间约束 28 | * 我们不清楚“新人”什么时候会关注到这些 issue，因此，不要把这些 issue 和你的 milestone（或其他版本发布计划）挂钩 29 | * 有助于贡献者了解项目结构（可选） 30 | * “新人”完成 `good-first-issue` 的价值不仅仅是可以增加贡献者数量，更有意义的地方在于：可以帮忙更多贡献者进一步熟悉、了解项目的贡献流程以及项目本身 31 | 32 | ## 模板 33 | 34 | 为了方便大家对 `good-first-issue` 有更形象的认识，我下面给出一个模板： 35 | 36 | ``` 37 | ## Background 38 | 39 | ## Technical requirement 40 | 41 | ## Expect 42 | 43 | ## Potential TODO list 44 | ``` 45 | 46 | ## 工具 47 | 48 | 自动化工具的应用，对于一个开源项目而言是极为重要的。来自 [Kubernetes](https://github.com/kubernetes) 社区的 [Prow](https://github.com/kubernetes/test-infra/blob/master/prow/plugins/help/help.go) 可以帮助项目维护者更好地使用标签。 49 | 50 | ## 其他 51 | 52 | GitHub 还提供了一个隐藏（没有直接调整的按钮或菜单等）的页面，参考如下——在某个开源项目的仓库地址后加 `contribute` 即可访问： 53 | 54 | https://github.com/LinuxSuRen/open-source-best-practice/contribute 55 | -------------------------------------------------------------------------------- /how-to-contribute.md: -------------------------------------------------------------------------------- 1 | # Get started 2 | 仔细阅读项目自述文件（README），遵循贡献指南（CONTRIBUTION）中给出的流程。 3 | 4 | 面对一个新的项目，尤其是在相对不熟悉的领域，有如下的方法可以帮助你提供前期的贡献： 5 | * 文档贡献，这是非常有效的一种了解项目的方式，通常我们可以在阅读文档的过程中，修复一些错别字、标点符号、语法错误、无效链接等等 6 | * [good-first-issue](good-first-issue.md)，对于希望收到更多贡献的项目而言，会在一些容易上手的 issues 上添加该标签 7 | 8 | ## Issues 9 | 常见误区： 10 | * 只有标题，没有内容 11 | * 只有结果、现象，没有提供上下文 12 | * 问题出现的可能性千千万，没有人能猜到你的环境、操作步骤 13 | * 只有截图，不提供错误、异常、上下文的关键文字 14 | * 没有文字的话，不便于其他人进行检索 15 | 16 | 最佳实践： 17 | * 现有的 issues 中没有提到过该问题时再提交新的 18 | * 熟悉语言一定要遵循对应社区期望的规定 19 | * 标题要简洁、规范 20 | * 做好分类，可以通过标签或者标题前缀来分类 21 | * 常见的标题分类法：Question: xxx, Proposal: xxx, Bug: xxx 22 | * 和 UI 相关的 issues 要给出截图 23 | 24 | ## Pull Request 25 | 常见误区： 26 | * 使用单一分支（例如：master）提交变更 27 | * 单个 PR 中包含多个不同的优化、缺陷修复 28 | * 单个 PR 不断新增内容 29 | * 合并自己提交的 PR 30 | * 通过及时聊天工具催促特定的人 review 你的 PR 31 | 32 | 最佳实践： 33 | * 首次提交 PR 前，浏览已经成功合并过的 PR 评论列表以及格式等 34 | * 如果要修复的问题已经有对应的 issue，请确保没有人提交对应的 PR，然后，请留言说明你的修复计划 35 | * 如果估计你提交的变更比较多，请首先创建 issue，并依据具体情况（难易程度、争议性等）描述你的想法 36 | * 一个 PR 只能包含一类修改 37 | * 对于 feature 或者 bugfix 相对复杂的情况，也要考虑到如何能给 reviewer 减轻 review 压力 38 | * 首先，思考下是否可以把一个“大型” PR 分成多个 39 | * 在提交 PR 之前，确保已经进行了充分的自测，并一定要关注下你的 commit 记录（相当于“卷面分”），只保留你希望被合并到上游的记录（其他的都可以提前 squash） 40 | * 小技巧：可以先在自己的 fork 后的仓库中提交一个 PR 来复查下，看看是否足够“优雅” 41 | * 每次提交都需要新增一个分支进行 42 | * 避免同一个主题的 PR 反复关闭、新建 43 | * 避免在同一个 PR 中频繁地提交，这对于 reviewers 来说将会是极大的困扰 44 | * 如果你的 PR 还没有准备好接受 review，请在标题上添加前缀 `WIP: `，直到你自测充分 45 | * 在根据 reviewers 提出的建议进行修改时，避免使用强制推送 `--force`，这对于 reviewers 来说将无法轻松地看到你最新修改的部分 46 | * 尽可能保持你的 commit 记录比较优雅，万一多次 review 后的记录比较多的话，项目 owners 会在合并时决定是否会 squash 你的提交记录 47 | * 尽可能多地给出当前 PR 的详情，包括但不限于：相关 issues、解决的问题、任何方便 review 的上下文 48 | * 涉及到 UI 的改动，给出修改前后的效果截图 49 | * 视情况给出你的自测过程 50 | * 对于可能引起争议的部分，给出你的解释 51 | * 如果你认为当前 PR 合并后可以修复对应的 issue，那么，请使用类似于 `close #123` 的[表达式](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue)。 52 | * 如果你的 PR 超过一周没有得到 review，可以尝试 cc 相关的 team 53 | * 如果没有相关的 team 可以 cc 的话，可以找最近合并过类似 PR 的人，并说明是由于找不到其他的方式，以及表示抱歉打扰 54 | 55 | 以下是常见的流程： 56 | ![image](https://user-images.githubusercontent.com/1450685/206119968-07e3d729-70d5-4f0a-8e5e-8edf21d792e6.png) 57 | -------------------------------------------------------------------------------- /insist.md: -------------------------------------------------------------------------------- 1 | “坚持就是胜利”，这是非常普通，却很实用的一句话。 2 | 3 | 参与开源，相比于你做其他事情，并没有什么特殊的地方，只要能坚持足够长的一段时间，就一定能有所收获。 4 | 5 | 关于坚持这件事情，是最容易、同时也可能是最难做到的。我们可以举出很多的例子来：坚持每天背 5 个英语单词、坚持跑步等等。事情本身往往比较容易，这里难的地方在于：只说要坚持了，却没有给自己一个清晰的时间限制。那么，如何才能解决“坚持”的问题呢，首先，让我们针对可能导致“坚持不下去”的因素做个分析。 6 | 7 | * 环境 8 | * 动力 9 | * 方法 10 | * 时限 11 | * 情绪 12 | 13 | 对于现阶段的机器（人）、程序而言，只要有合适的环境（软硬件）、足够的电力、可运行的代码（指令），几乎是（忽略损耗部分）可以永久性地坚持的。相比于动物、人类而言，这是机器天然具有的、极大的优势。 14 | 15 | 对于绝大部分的普通人来说，总是会有各种各样的情绪存在，而情绪则极大地影响我们能在某件事情上投入的时间、精力，甚至于还能影响到智力的发挥。例如，当你的大脑中充满困意，很想休息，却有和你息息相关的意外发生时，困意几乎可以是瞬间就消失了。有情绪（或感情），是人与动物得以区分的重要特点之一，这一点自然是无法断绝的。实际上，比较容易控制的一个因素就是“时限”。与其两级分化，动辄“宣称”永久做什么，亦或企图“立竿见影”，不如耐下心来认真地给自己设定一个期限。一些简单的事情，努力一年大致会有一个阶段性成果；复杂一些的事情，也许需要三到五年；而你如果希望能做到顶尖级别的，可以试着了解下[“一万小时定律”](https://wiki.mbalib.com/wiki/%E4%B8%80%E4%B8%87%E5%B0%8F%E6%97%B6%E5%AE%9A%E5%BE%8B)。 16 | 17 | 个人参与开源，至少给你自己一年的时间（机会）。选择一个适合自己的开源社区（项目），积极地参与一年。这样可以让你加深对开源的认识，也只有这样你才能有理由来说服自己是否要在开源领域投入自己更多的精力。 18 | 19 | 那么，一年内都该做哪些事情呢？做到什么程度可以认为是“积极地”参与呢？大致上，可以分为两种方法：设定一些数字化指标（目标、flag）；感性的认识。 20 | 21 | 数字化的目标，容易理解，但仅供参考，请避免一味地追求数字。根据自己的情况，选定一个开源社区，从如下列表中选择部分作为你的目标： 22 | 23 | * 10~15 个代码类的贡献 24 | * 提交 20 个 issue 25 | * 20 个文档类贡献 26 | * 参加 10 次社区例会，积极参与发言 27 | * 积极参与社区线上线下活动：议题分享、志愿者 28 | * 其他 29 | 30 | 所为感性的认识，可以理解为通过一些 contribution 让社区成员可以熟悉你，经常看到你的“身影”。 31 | 32 | 参与开源，从某个层面上理解，可以认为是一种基于特定主题的“社交活动”。如果只是“观察式”的，被动地参与，不去主动地和社区成员交流，可能算不上是积极。 33 | -------------------------------------------------------------------------------- /mentor-plan.md: -------------------------------------------------------------------------------- 1 | # 如何让开源社区持续保持活跃 2 | 3 | # 开源导师计划 4 | 5 | 开源导师计划，为了给有兴趣深入参与开源，并希望得到一定指导的人一次共同学习的机会。 6 | 7 | 需要注意的是，导师制并不是要培训、讲解如何参与开源，更不是教你学习任何具体的技术。这个计划大致的形式是：导师给出一系列任务，参与者来完成任务。以下是细节： 8 | 9 | ## 周期 10 | 一年 11 | 12 | ## 参与者人数 13 | 不超过两人 14 | 15 | ## 进度同步 16 | 两周一次 17 | 18 | ## 任务 19 | 参与者需要和导师共同制定要完成的任务，并明确完成的标准。导师应该根据学员的具体情况给出相应的指导意见。 20 | 21 | ### 选择一上游社区并跟进 22 | 形式包括但不限于： 23 | * 每月至少参与一次社区例会 24 | * 了解社区运营方式 25 | * 至少参与一次社区的活动 26 | * 提交一次代码 PR，已经其他 PR 若干 27 | 28 | ### 跟进本社区的一名外部贡献者 29 | 形式包括但不限于： 30 | * 积极跟进对方提的 issue 或者 PR 31 | * 了解对方在参与奔社区过程中遇到的困境，并设法解决 32 | * 进行2～3次的访谈，并形成文字记录 33 | 34 | ## 成果展示 35 | 一个季度一次 36 | 37 | * 技术博文 38 | * 社区动态介绍，包括：技术、社区活动 39 | * 视频教程 40 | * 所跟进的外部贡献者的成果，收到的反馈 41 | 42 | ### 通用技能 43 | * 英语（听说读写） 44 | * 演讲 45 | 46 | ## 同步、交流 47 | * 例会，两周一次 48 | * 成果展示，每月一次 49 | -------------------------------------------------------------------------------- /motivation.md: -------------------------------------------------------------------------------- 1 | ## 开源是什么 2 | 3 | 在很多地方，开源更多的是在说“开源软件”。但，除了软件以外，开源精神最具有启发性的在于——人和人之间的协作方式上，平等、开放、协作、共享。 4 | 5 | * 平等，人与人之间没有等级、阶层之分，主要体现在讨论问题、决策过程中，大家基于共识而不是权利 6 | * 开放，这一点强调的是，整个开源活动应该是公开的，包括：提议、过程、结果 7 | * 协作，避免单打独斗、英雄主义、个人主义 8 | * 共享，乐于分享协作成果，以及成果的二次创作 9 | 10 | ## 为什么要参与开源 11 | 12 | 基于开源协作的特性，你的舞台不再局限于某个公司、某个团队，你所需要思考的也不再只是编码、测试、设计、推广等单一的角度。对于不同（岗位）角色的人来说，参与开源的意义略有不同，下面会分别讨论。但，确认无疑的是，你一定是有机会去从不同的视角来考虑问题、承担责任。 13 | 14 | ### 研发 15 | 16 | 对于在从事研发类（包括：开发、架构设计、测试、运维等）工作的人而言，是非常适合参与开源的。通过在开源社区的磨砺，大致可以从如下几个方面得到提升： 17 | 18 | * 技术成长 19 | * 软实力 20 | * 职业方向多样化 21 | * 其他 22 | 23 | #### 技术成长 24 | 25 | 企业内部项目的生命流程，通常都会和公司的商业模式、市场价值、经营水平有着密切的关系，企业为了追求价值的最大化，完全可以新开发一个项目、或者直接下线一个项目。尤其对于普通的研发人员，往往是没有任何发言权的。而对于项目上的技术、框架选型，在垂直型结构的团队中也是“领导”决定的。 26 | 27 | 因而，可以想象到，普通的研发人员在日常的研发工作中往往会处于被动的地位，被动地去学习、使用某种技术，被动地去完成某项任务。在这种环境下，大部分人的创新、主管能动性是难以调动起来的。很多 IT 从业人员，也就会有“打工”、“北漂”的深切感受。 28 | 29 | 在开源项目中，往往是没有明显的阶级、等级之分，所有的任务（issues）都是自愿、主动在做，而每个人都可以向社区提出你的提议，社区成员也会基于共识、规范来 review 你的 PR 或者提议。而在 review（不是审核、审查）过程中，你也许会收到在这个领域非常资深、经验丰富的贡献者的反馈。 30 | 31 | #### 软实力 32 | 33 | 好的沟通能力，在开源项目中是很基础的能力之一。在开源协作过程中，由于地域、文化、时区的不同，大部分的交流是异步进行的。也正是由于无法实时收到回复，大家在交流的过程中，通常会事先把事情的来龙去脉尽量弄明白，并给出自己的调查结果、建议、不同方案的对比等等。 34 | 35 | 声誉，也许是很多 IT 从业人员还没有意识到的一项宝贵资产。简历是极容易作假的环节，良好的表达能力也可以让候选人通过面试，及时是背景调查也无法让面试官了解到候选人过往的细节。因此，是否有大厂经历、高学历，（或者是运气）在很大程度上决定着我们是否可以进入到更大的平台中。 36 | 37 | 然而，参与开源的经历、成就则通常是公开的，任何人都可以查阅到。因此，对于参与开源的每一位贡献者都会很关注自己的行为，以及带来的影响。而对于用人单位，也同样是可以对此很放心。 38 | 39 | #### 职业方向多样化 40 | 41 | 开源项目的健康发展，不仅仅需要优质的代码，更加需要不同角色的人的共同努力。从需求的收集、整理，功能实现、问题修复，以及技术推广、问题反馈等，一个正向的闭环机制是开源社区长久健康发展的秘诀。 42 | 43 | 从技术推广的角度来讲，通常的方法有：编写技术博客、视频教程、技术分享等等。做这些工作，会对技术总结、演讲技巧上有极大的提高。这对于以后考虑选择技术布道师这个岗位来说，应该会有很大的帮助。 44 | 45 | 如果平时在社区活动组织、协助上付出比较多的话，之后也许是可以走向开源社区运营的方向。 46 | 47 | 在企业内部，通常是职责分明，大多数研发没有机会直接接触到客户（用户），因而也难以培养产品思维。而对于开源项目的维护者，则为了让自己的产品更有竞争力、更加贴近最终用户的需求，则需要从产品整体来思考、规划、设计。借此，走向产品经理的路，自然也是极为可能。 48 | 49 | #### 其他 50 | 51 | 有一些刚刚踏入 IT 行业从事软件研发工作，但英文水平比较一般的人，在经过几年的工作后可能会觉得英文水平的高低似乎也不会对本职工作有多大影响。之后，不管是在搜索资料，还是阅读文档时，逐渐会对英文的资料敬而远之。甚至，当遇到把英文作为第一交流语言的开源社区、开源项目时，表示很不理解；明明都是中国人，却非要用英文。 52 | 53 | 这里，我们不讨论开源项目中到底应该以何种语言为首选。确认无疑的是，只要你愿意暂时放下已有的观念，潜心地、虚心地参与到开源社区中来，对于学习语言的看法一定会有很大改变的。人随心动，放空自我，随着社区一起成长，英文水平的大幅提高几乎是必然会发生的事情。 54 | 55 | 除了语言本身的学习、成长之外，参与开源还可以让你的思维方式、理念保持长久的年轻、不僵化。人总是会容易骄傲自满、固步自封，然而如果你始终坚持开源的基本原则的话，不管你获得过多大的成就，你也还会乐意和新加入的朋友一起畅聊。 56 | 57 | ## 参与开源的原动力 58 | 59 | 我们做任何事情，都由一定的动力驱使的，不管是内在的，还是外来的；抑或只是一个借口或者理由。不同的人，参与开源有着不同的原因。但，弄明白这个动因，是极为重要的。 60 | 61 | 有不少的声音提到，参与开源需要用“爱”发电。不知道第一次提出这个说法的人想要传达的信息是什么，但这句话极易使得对开源接触不深入的人产生误解。在经济和时间上都不富有的情况下，“爱好”显然不是一个强有力的驱动。很难想象到，仅凭借“爱好”就可以让你改变思维模式、在一个领域长久地耕耘。 62 | 63 | 如果把我们自身比作航行在大海上的一艘船的话，“爱好”可以帮助我们“导航”，而真正让我们得以“远航”的“发动机“还是和我们的职业密切相关的。至少，在社会主义实现之前应该是这样的。 64 | 65 | 参与开源的过程中，在选择技术领域、开源项目上，“爱好”在发挥着作用。但是，千万不要偏离了你的“全职工作”。至少，你需要找到二者之间的结合点。 66 | -------------------------------------------------------------------------------- /open-source-credit.md: -------------------------------------------------------------------------------- 1 | 开源项目几乎无处不在，不管是我们日常使用的手机应用，还是访问的网页服务中，都有着大量开源项目的身影，例如：使用极为广泛的 Linux 操作系统（通常不为普通用户所见）、安卓（Android）操作系统等等。大部分的（不管是商业，还是开源的）软件，却很少提到他们所使用的开源项目有哪些，这样也正是绝大部分非软件工程师的普通人对开源无感知的其中一个原因；而随着开源逐渐被更多人认可、拥护，有一些个人、软件公司，已经迈出了非常值得肯定的一步。 2 | 3 | 为了表示对这些个人、软件公司行为的肯定，以下是收集的部分公开展示了所依赖的开源项目的软件： 4 | 5 | > 如果你之前没有注意过你所使用的软件是否公开展示了所依赖的开源项目，从此刻可以考虑关注下，并帮助完善下面的列表： 6 | 7 | | 软件公司（个人） | 软件名称 | 查看路径 | 8 | |---|---|---| 9 | | 阿里巴巴 | [支付宝](https://www.alipay.com/) | 关于=>版权信息 | 10 | | 阿里巴巴 | [淘宝](https://www.taobao.com/)，移动客户端 | 关于淘宝=>版权信息 | 11 | | 田稼东 | [Noteday](https://app.sixiluo.com/noteday/) | 关于 | 12 | -------------------------------------------------------------------------------- /open-source-write-guide.md: -------------------------------------------------------------------------------- 1 | # 为什么要写本篇文章 2 | 3 | 写作本篇文章的目的是：在编写和开源实践有关的文档内容时，遵守此文档写作规范。以便初次参与开源的人能够更好的理解文章描述内容，找到自己的方向。 4 | 5 | ## 写作指南 6 | 7 | > 文档编写可以参考：https://github.com/ruanyf/document-style-guide 8 | 9 | 1. 注意文章写作格式，一些 Markdown 的语法等，灵活使用，使文章内容更具有条理性和可读性； 10 | 11 | 2. 使用正确的标点符号（中英文符号）； 12 | 13 | ```markdown 14 | 例如一句话结尾时： 15 | 16 | 错误：今天太阳很好. 17 | 18 | 正确：今天太阳很好。 19 | ``` 20 | 21 | 3. 注意专有名词的书写（英文文档注意词性）； 22 | 23 | ```markdown 24 | 错误：我们将会使用 spring cloud openfeign 完成服务调用。 25 | 26 | 正确：我们将会使用 Spring Cloud OpenFeign 完成服务调用。 27 | ``` 28 | 29 | 4. 避免出现缩写内容（或者文章第一次出现时说明）； 30 | 31 | ```markdown 32 | 错误：下文中，将使用 SCA 的服务治理能力。 33 | 34 | 正确： 35 | 1. 下文中，将使用 Spring Cloud Alibaba 的服务治理能力。 36 | 2. 使用 Spring Cloud Alibaba（后文简称SCA）声明 37 | 38 | 5. 使用 Markdown 时为不同的代码块指定对应的语言； 39 | 40 | 1. 错误 41 | 42 | ```xml 43 | { 44 | "user": "zhangsan", 45 | "age": "12" 46 | } 47 | ``` 48 | 49 | 2. 正确 50 | 51 | ```json 52 | { 53 | "user": "zhangsan", 54 | "age": "12" 55 | } 56 | ``` 57 | 58 | 6. 对文章中一些专有名词提供链接； 59 | 60 | ```markdown 61 | 错误：下文中将使用 Github Action 来完成 CI/CD。 62 | 63 | 正确：下文中将使用 [Github Action](https://docs.github.com/zh/actions) 来完成 [CI/CD](https://www.redhat.com/en/topics/devops/what-is-ci-cd)。 64 | ``` 65 | 66 | 7. 对重点内容使用加粗，下划线等着重强调； 67 | 68 | 8. 明确文章的受众群体，站在受众群体思考，确保对当前受众群体而言，有一定的参考价值。 69 | 70 | 9. 使用合适的人称代词； 71 | 72 | 10. 文章完成之后，**自己阅读一下，避免出现错误问题！** 73 | -------------------------------------------------------------------------------- /ospp.md: -------------------------------------------------------------------------------- 1 | 本文试图探索一种以尽量客观地评估开源项目议题（题目）申请人与项目契合度的方法。其中，结合了本人参与[开源之夏](https://summer-ospp.ac.cn/)、[GSoC](https://summerofcode.withgoogle.com/) 的经验。 2 | 3 | 开源之夏组委会给出的办法是，项目议题申请人（学生）与项目（mentor）通过双选的方式来进行匹配。以下，通过一些考察点来给申请者打分、排序： 4 | 5 | | 考察点 | 分值范围 | 说明 | 6 | |---|---|---| 7 | | 前期沟通 | 0-10 | 推荐以公开沟通为主，私下沟通为辅，例如：邮件（列表）、issue 或即时通讯 | 8 | | 项目前期参与 | 0-10 | 有简单的 issue 或 PR 提交并完成，最多得 6 分；有与议题难度相当的 PR 可得 4 分 | 9 | | 综合能力 | 0-10 | 沟通过程是否顺畅，是否可以按照项目 CONTRIBUTION 描述的方式参与，是否可以顺利完成 PR 的合并，代码是否规范、是否有相应文档 | 10 | | 申请书 | 0-10 | 是否可以清晰、完整地描述设计 | 11 | -------------------------------------------------------------------------------- /others.md: -------------------------------------------------------------------------------- 1 | 还有一些其他的比较推荐的习惯、方法： 2 | 3 | * 习惯查看邮件 4 | * 一定要把自己常用的邮箱地址关联到 GitHub 上，这样才能及时收到 issues 和 PR 中的互动信息 5 | * 通过电脑、手机来管理自己的日程 6 | * 开源社区总会有各种各样的会议，如果没有使用日历的习惯的话，非常容易遗忘重要的事情 7 | -------------------------------------------------------------------------------- /platforms.md: -------------------------------------------------------------------------------- 1 | 国内外，有很多平台可以帮助建设、发展开源社区。包括有：代码托管、音视频、文章、社交动态等等。 2 | 3 | | 类型 | 名称 | 描述 | 4 | |------|-------------------------------------------------|----------------------------------------------| 5 | | 代码托管 | [GitHub](https://github.com/) | 面向全球，约 5600 万用户。 | 6 | | 代码托管 | [Gitee](https://gitee.com/) | 主要面向中国用户，界面有中英文支持，基于 Gitlab | 7 | | 代码托管 | [极狐](https://jihulab.com/explore/) | [极狐](https://gitlab.cn/) 旗下的代码托管仓库，基于 Gitlab | 8 | | 代码托管 | [GitLab](https://gitlab.com/explore) | | 9 | | 代码托管 | [GitCode](https://gitcode.net/) | [CSDN](https://www.csdn.net/) 旗下的代码托管仓库，基于 Gitlab | 10 | | 视频 | [YouTube](https://www.youtube.com/) | 全球最大的视频分享网站，以英文为主。部分国家（或地区）可能无法访问。支持多账号管理模式。 | 11 | | 视频 | [哔哩哔哩](https://www.bilibili.com/) | 中国最大的视频分享网站，以中文为主。 | 12 | | 播客 | [喜马拉雅](https://www.ximalaya.com/) | 中文播客 | 13 | | 播客 | [小宇宙](https://www.xiaoyuzhoufm.com/) | | 14 | | 文章 | [微信公众号](https://mp.weixin.qq.com/) | 以发布文章为主，同时支持音视频。 | 15 | | 文章 | [V2EX](https://www.v2ex.com/?r=linuxsuren) | 以中文用户为主，虽然没有看到社区账号注册，但内容质量非常不错。 | 16 | | 文章 | [开源中国](https://www.oschina.net/) | 以中文用户为主。 | 17 | | 文章 | [思否](https://segmentfault.com/) | 包含问答、文章专栏、招聘等板块。以中文用户为主。 | 18 | | 文章 | [InfoQ](https://www.infoq.cn/topic/opensource) | | 19 | | 文章 | [DEV](https://dev.to/) | 以英文用户为主。 | 20 | | 文章 | [reddit](https://www.reddit.com/) | 以英文用户为主。 | 21 | | 社交动态 | [Twitter](https://twitter.com/) | 面向全球。部分国家（或地区）可能无法访问。支持多账号管理模式。 | 22 | | 社交动态 | [领英](https://www.linkedin.com/) | | 23 | | 社交动态 | [即刻](https://www.okjike.com/) | | 24 | | 活动发布 | [活动行](https://www.huodongxing.com/) | 以中文用户为主。 | 25 | | 活动发布 | [百格活动](https://www.bagevent.com/) | 以中文用户为主。 | 26 | | 活动发布 | [Meetup](https://www.meetup.com/) | 面向全球，没有中文支持。 | 27 | | 即时沟通 | [Slack](https://slack.com/) | | 28 | | 即时沟通 | [Gitter](https://gitter.im/) | | 29 | | 即时沟通 | [微信](https://weixin.qq.com/) | 中国最流行的交流工具。 | 30 | | 即时沟通 | [telegram](https://telegram.org/) | | 31 | | 即时沟通 | [飞书](https://www.feishu.cn/) | 支持的群模式：对话、话题式。入群二维码支持设置自定义有效期（包括永久有效）。 | 32 | | 捐助 | [爱发电](https://afdian.net/) | | 33 | | 捐助 | [Open Collective](https://opencollective.com/) | 面向全球。部分国家（或地区）可能无法访问。 | 34 | | 文档协作 | [Google Document](https://docs.google.com/) | 面向全球。部分国家（或地区）可能无法访问。 | 35 | | 文档协作 | [HackMD](https://hackmd.io/) | 以 Markdown 的方式编辑。部分国家（或地区）可能无法访问。支持多账号管理模式。 | 36 | | 文档协作 | [石墨文档](https://shimo.im/) | | 37 | | 在线会议 | [Google Meet](https://meet.google.com/) | 在浏览器中运行，无需安装客户端。不支持录屏。 | 38 | | 在线会议 | [腾讯会议](https://meeting.tencent.com/) | 以中文用户为主，录屏方式支持本地、云录制。有降噪功能，但偏弱。 | 39 | | 在线会议 | [飞书](https://www.feishu.cn/) | 支持：录制、虚拟形象、虚拟背景。 | 40 | | 日程管理 | [Doodle](https://doodle.com/) | 可用于多人以投票的形式选择合适（活动、会议）的时间段。 | 41 | | 日程管理 | [Google Calendar](https://calendar.google.com/) | 可作为社区公开的、可订阅的活动、会议的日历 | 42 | | 日程管理 | [飞书日历](https://www.feishu.cn) | 亮点，可以同步第三方日历，如 Google Calendar、Outlook、Exchange 等。更多可见：https://www.feishu.cn/hc/zh-CN/articles/665183342590 | 43 | 44 | > 欢迎读者帮忙推荐更多的平台，以及完善平台的描述。 45 | > 46 | > 推荐标准： 47 | > 48 | > * 在某个领域有较大的影响力 49 | > * 可以帮助开源社区做技术传播（列举出某个知名社区在该平台上有活跃的账号） 50 | > * 支持免费使用 51 | -------------------------------------------------------------------------------- /practice/community-first.md: -------------------------------------------------------------------------------- 1 | 对于部分开源社区而言，会把构建、建设社区本身当作很重要的事情，我们可以从多个维度体验到这一点。 2 | 3 | GitHub 支持置顶 6 个代码仓库，开源社区通常会把最重视的仓库作为置顶项目。因而，从这个角度来看， 4 | 如果某个开源社区把名为 community 的仓库置顶的话，可能是相对更重视社区建设的。下面是部分置顶 community 仓库的社区： 5 | 6 | | 社区 | 领域 | 最新近一次更新 | 7 | |---|---|---| 8 | | [CHAOSS](https://github.com/chaoss/community) | 度量 | ![](https://img.shields.io/github/last-commit/chaoss/community) | 9 | | [KubeSphere](https://github.com/kubesphere/community) | 云原生 | ![](https://img.shields.io/github/last-commit/kubesphere/community) | 10 | | [Tekton](https://github.com/tektoncd/community) | 持续交付 | ![](https://img.shields.io/github/last-commit/tektoncd/community) | 11 | | [Flux](https://github.com/fluxcd/community) | GitOps | ![](https://img.shields.io/github/last-commit/fluxcd/community) | 12 | | [Kubernetes](https://github.com/kubernetes/community) | 云原生 | ![](https://img.shields.io/github/last-commit/kubernetes/community) | 13 | | [TensorFlow](https://github.com/tensorflow/community) | | ![](https://img.shields.io/github/last-commit/tensorflow/community) | 14 | | [GitHub](https://github.com/community/community) | 代码托管 | ![](https://img.shields.io/github/last-commit/community/community) | 15 | | [Istio](https://github.com/istio/community) | 微服务 | ![](https://img.shields.io/github/last-commit/istio/community) | 16 | | [Knative](https://github.com/knative/community) | 云原生 | ![](https://img.shields.io/github/last-commit/knative/community) | 17 | | [Helm](https://github.com/helm/community) | 云原生 | ![](https://img.shields.io/github/last-commit/helm/community) | 18 | | [Kubeflow](https://github.com/kubeflow/community) | | ![](https://img.shields.io/github/last-commit/kubeflow/community) | 19 | | [PingCap](https://github.com/pingcap/community) | 数据库 | ![](https://img.shields.io/github/last-commit/pingcap/community) | 20 | -------------------------------------------------------------------------------- /review.md: -------------------------------------------------------------------------------- 1 | 2 | * 开源最基本原则的体现，公开、透明 3 | * 如果连 review 都不做的话，何谈开源？要公开的绝不仅仅是结果，更关键的是要公开过程 4 | * review 绝对不是审核的意思，任何人都可以是 reviewer，大家都有可以在这个过程中有所收获 5 | * 生命周期 6 | * PR 不适用于有紧急合并需求的情况 7 | * 提交完 PR 后，作者首先应该自行检查一遍，如果发现还有问题的话，请标记为“进行中” 8 | * 我们可以把还没准备好 review 的 PR 的标题加上前缀：`WIP:` 9 | * 作者如果对某些代码（文档）不是很确定，可以直接把你的观点以评论的形式表述出来 10 | * 在 2～7 天内完成 review 并合并 11 | * 礼仪 12 | * 没有人有义务对你的 PR 进行 review，包括维护者 13 | * 每一位 reviewer 都对你的 PR 合并提供了帮助，对他们表示感谢 14 | * 在最佳的 review 周期内，不要去催促任何人对你的 PR 进行 review 15 | * 如果确实需要请求 review 帮助，请给出说明，并且优先 @ 某个 team，其次才是直接 @ 某个人，并对打扰表示歉意 16 | * 明确你的观点 17 | * 尽量避免给出模棱两可的评论，作者需要根据你给出的建议来决定是否要进行修改 18 | * 对于你不是很确定问题，可以这么表述：”我感觉这里可能有问题，给出建议的做法以及理由，并指明该评论不阻碍 PR 的合并“ 19 | * 对于你很确定有问题的部分，给出可以证明你观点的信息或者数据，如果有相关权威资料的话，一并给出链接 20 | * 例如：PR 中代码注释不规范，给出官方社区的文档链接 21 | * reviewer 22 | * 任何人都可以是 reviewer，只要是你认为有问题（或可以改进）的地方，都可以提出来，并且给出可以证明你观点的证据、资料链接 23 | * 优先请求一个 team 帮忙 review，这样的话，你可以得到更多人的帮助 24 | * 通常情况下，每一个文件都是由多名贡献者共同完善的，可以考虑让最后一次修改该文件的贡献者帮忙 review 25 | * 如果你尝试解决的问题或者新增的特性来自另外一名贡献者创建的 issue，那也可以尝试寻求该贡献者的帮助 26 | * 自动化流程 27 | * 利用类似于 [Lighthouse](https://github.com/jenkins-x/lighthouse) 的自动化工具来管理 review 流程 28 | * 合并之前尽可能多地运行自动化测试（单元测试、e2e 测试、压力测试等） 29 | * 避免人为干预自动化过程 30 | * 如果 review 完成，但还需要一些人工验证的话，为避免过早自动合并，可以通过评论命令来阻碍 31 | * 例如：通过评论 `/hold` 来阻止机器人账号自动合并 32 | -------------------------------------------------------------------------------- /sig.md: -------------------------------------------------------------------------------- 1 | SIG 是个不错的组织形式，但 SIG 并不是“银弹”，并不能适用于所有社区。具体是否要采用 SIG 机制，还是得根据社区当前的情况而定。 2 | 3 | ## 发起 4 | 5 | SIG 往往是为了让部分社区成员以相对集中的形式讨论、改善、解决某个领域，而社区也会给与 SIG 一定授权。SIG 的创立通常需要至少一名发起人作为 lead， 6 | 至少三名对该领域感兴趣的成员。 7 | 8 | 社区为了更好地管理 SIG，也通常会给出相关的制度（或章程），希望发起一个新 SIG 的成员基本按照约定完成相应流程即可。例如下面的模板： 9 | 10 | ```markdown 11 | 背景介绍，重点阐述社区现状（问题、希望改善的地方）。 12 | 13 | 成立 SIG 后，说明希望解决的问题，以及大致的运作模式。 14 | 15 | SIG 成员列表。建议成员的构成具有一定的多样性，也就是尽量是来自不同的企业、或是以个人身份加入。 16 | 17 | 给出 SIG 的交流、沟通渠道，例如：邮件列表、Slack、例会，以及讨论的记录（文字、视频等）。 18 | ``` 19 | 20 | ## 会议 21 | 22 | SIG 通常是以线上（online）的形式存在，而例会则是非常重要的部分。大家可以在会议上分享社区动态、项目进度，也可以就某些问题、提议进行讨论。 23 | 24 | 以下是会议主持人通常需要考虑的： 25 | 26 | * 会议时间的选择，尽量考虑多数人的需求 27 | * 通过 [Doodle](https://doodle.com/en/) 或类似的工具供大家投票选择 28 | * 每次会议都要有会议开始和结束的表述 29 | * 可以参加在线例会的成员，毕竟是有限的。因此，可能会有很多人通过视频回放的方式来“参加”例会。对于首次参加例会，或观看视频回放的成员来说，如果主持人不对例会做简单概述的话，可能难以理解会议内容、融入 SIG 活动。 30 | * 例如：现在开始我们今天的例会，主要的议题是xxx；结束时可以说：“非常感谢各位参加今天的社区例会”等等的 31 | * 热情地欢迎首次参加例会的成员，并鼓励做自我介绍 32 | * 做必要的上下文介绍 33 | * 假设参加会议的大部分成员，对要讨论的内容并不熟悉 34 | * 不管是拨入会议还是观看回放的人，都可能是首次参与，缺少上下文会导致他们难以明白相关讨论 35 | * 如果有文字性的上下文介绍，尽量在会议记录文档中有体现 36 | * 主持人要把控会议时间、节奏 37 | * 尽量控制在 1 小时内，未讨论完的议题放到下次讨论 38 | * 在讨论过程中帮助、引导得出结论 39 | * 使用适当的表述方式 40 | * 避免使用类似于“我们昨天讨论过xxx”的表述，社区成员无法了解到你们讨论的内容 41 | * 确保例会的周期性 42 | * 通常情况下，每两周一次的例会比较适中 43 | * 当参与者人数相对较多，而且分布在不同时区的话，结合参与者的意见可以分两个会议 44 | * 当可以主持会议的人都无法参加，或者其他需要取消例会的情况，尽早地通知社区会议取消 45 | * 主要成员所在国家（地区）的法定节假日前，也应该提前取消 46 | * 会议记录 47 | * 文字记录，可以使用 [Google Document](https://docs.google.com/document/u/0/) 或者[腾讯文档](https://docs.qq.com/) 48 | * 会议的录屏文件，可以根据会议参与者使用的语言不同，中文可以选择[哔哩哔哩](https://www.bilibili.com/)，英文可以选择 [YouTube](https://www.youtube.com/) 49 | 50 | ## 原则 51 | 52 | SIG 的健康发展，离不开公开、透明、多元化等原则，流于形式的、不符合开源精神的 SIG 没有存在的意义。 53 | 54 | ## 退休 55 | 56 | 定期（例如一年）考察每个 SIG 的运转情况，如果长期没有会议进行，SIG lead 及成员也没有意愿（可以通过 GitHub issue 或其他渠道来确认）继续维护的话， 57 | 可以考虑将 SIG 关闭或退休（retire）掉。 58 | 59 | 长期不活跃的 SIG，会给新关注到社区的人带来很大的“误解”或困惑，他们可能认为这个社区缺乏治理、活力。因此，社区的 lead 如果希望能有源源不断的新成员加入的话， 60 | 就不能任由 SIG 的“堕落”。 61 | 62 | ## 采用 SIG 的开源社区 63 | 64 | | 名称 | 备注 | 65 | |---|---| 66 | | [CD Foundation](https://github.com/cdfoundation/toc/tree/master/sigs) | [Linux 基金会](https://www.linuxfoundation.org/) 旗下的子基金会 | 67 | | [Jenkins](https://www.jenkins.io/sigs/) | CI/CD 领域 | 68 | | [KubeSphere](https://github.com/kubesphere/community) | 由[青云](https://www.qingcloud.com/) 发起，聚焦在云原生领域 | 69 | | [openEuler](https://www.openeuler.org/zh/sig/sig-list/) | 由[开放原子开源基金会](https://www.openatom.org/) （OpenAtom Foundation）孵化及运营的开源项目 | 70 | | [云原生社区](https://cloudnative.to/community/sig/) | | 71 | | [Kubernetes](https://github.com/kubernetes-sigs) | 容器调度平台 | 72 | | [KubeEdge](https://github.com/kubeedge/community) | 边缘计算 | 73 | | [OpenHarmony](https://gitee.com/openharmony/community/tree/master/sig) | 操作系统 | 74 | | [MindSpore](https://gitee.com/mindspore/community/tree/master/sigs) | 人工智能 | 75 | | [openGauss](https://gitee.com/opengauss/community) | 关系型数据库 | 76 | 77 | ## FAQ 78 | 79 | * SIG 可以等同于社区的技术领域划分吗？ 80 | * SIG 不仅仅是领域的划分，更重要的是一个供社区成员交流、讨论以及行动的场所。 81 | 82 | ## 参考 83 | 84 | * [Special interest group - Wikipedia](https://en.wikipedia.org/wiki/Special_interest_group) 85 | -------------------------------------------------------------------------------- /what/community-manager.md: -------------------------------------------------------------------------------- 1 | 社区运营的工作基本是通过适合的形式（宣传资料、活动等）让开源项目的目标人群（开发者、最终用户等）了解到项目的特性、动态、参与方式等。 2 | 可以认为社区运营做的是牵线搭桥的事情，可能是让最终用户自行阅读文档、查看视频并体验项目，抑或是让项目的开发者（maintainer、contributor） 3 | 分享他们经验、观点等。 4 | 5 | ## 技能清单 6 | 作为社区运营，可能需要拥有以下多项技能： 7 | > 考虑对能力进行分组，难易程度区别 8 | 9 | * 沟通能力（线上、线下） 10 | * 文案编辑 11 | * 对相关媒体平台的了解、使用 12 | * 活动组织 13 | * 基本的数据统计、分析 14 | * 业内人脉圈 15 | * 音视频剪辑 16 | * 基本的图片编辑能力 17 | * 公开演讲（分享） 18 | * 公开活动主持 19 | * 相关（开源项目）技术的理解力 20 | 21 | ## 分工 22 | TODO 23 | 24 | ## 误区 25 | TODO 26 | 27 | ## 薪资范围 28 | TODO 29 | 30 | ## 机遇和挑战 31 | 作为社区运营，成长轨迹如何，又有哪些机遇和挑战呢？ 32 | 33 | ## 致谢 34 | 本文的形成，得益于以下业内朋友的支持、观点。 35 | 36 | TODO 37 | -------------------------------------------------------------------------------- /what/devrel.md: -------------------------------------------------------------------------------- 1 | > This file was generated by [devrel.tpl](devrel.tpl) via [yaml-readme](https://github.com/LinuxSuRen/yaml-readme), please don't edit it directly! 2 | 3 | > 考虑到绝大部分做 DevRel 工作的人，是需要面向全球的，应该都有一定的英语基础，以下都采用英文编写。 4 | 5 | ## People 6 | Learning from other people who is doing the DevRel work might be a good idea. 7 | Please feel free to mainaintain the following table with me. 8 | 9 | | Name | Organization | Contact | 10 | |---|---|---| 11 | | Adam DuVander | | [:octocat:](https://github.com/adamd) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/adamd) | 12 | | Anthony Kiplimo | | [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/AnthonyLimo) | 13 | | [April Speight](https://www.vogueandcode.com/) | | [:octocat:](https://github.com/aprilspeight) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/vogueandcode) [![youtube](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcRY4no9kYJtEAHXBEY2GDprV__HH1zc94olyS6G6fT5isS71bPyqvIi7-9VE1MMy3_3vsNOQLAerwcSQqGNyADWfxKpd2hLc8HuacZdgEjgZc_WLN8)](https://www.youtube.com/vogueandcode)| 14 | | Arkodyuti Saha | | [:octocat:](https://github.com/arkodyuti) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/arkodyutisaha) | 15 | | [Hassan El Mghari](https://www.elmghari.com/) | [Vercel](https://github.com/vercel) | [:octocat:](https://github.com/nutlope) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/nutlope) | 16 | | Jen Sable Lopez | | [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/jennita) | 17 | | [Jono Bacon](https://www.jonobacon.com/) | | [:octocat:](https://github.com/jonobacon) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/jonobacon) [![youtube](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcRY4no9kYJtEAHXBEY2GDprV__HH1zc94olyS6G6fT5isS71bPyqvIi7-9VE1MMy3_3vsNOQLAerwcSQqGNyADWfxKpd2hLc8HuacZdgEjgZc_WLN8)](https://www.youtube.com/jonobacon)| 18 | | Mary Thengvall | | [:octocat:](https://github.com/nutlope) | 19 | | [Matthew Revell](https://www.matthewrevell.com/) | | [:octocat:](https://github.com/matthewrevell) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/matthewrevell) | 20 | | [Michael Heap](https://michaelheap.com/) | [Kong](https://github.com/Kong) | [:octocat:](https://github.com/mheap) [![twitter](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcTA3XDrUCnqJvmP3gfZKpXtV8ZO23EalnKszft6-V73d8G2Lt54v9TEnnkeO_MXseXmT5ERutOo0yPqoODJkFPtvxCeQbg_PYDJjXDAFfIMzM2p4bI)](https://twitter.com/mheap) [![youtube](https://encrypted-tbn3.gstatic.com/favicon-tbn?q=tbn:ANd9GcRY4no9kYJtEAHXBEY2GDprV__HH1zc94olyS6G6fT5isS71bPyqvIi7-9VE1MMy3_3vsNOQLAerwcSQqGNyADWfxKpd2hLc8HuacZdgEjgZc_WLN8)](https://www.youtube.com/mheap89)| 21 | 22 | ## Others 23 | * [Jobs in DevRel](https://jobsindevrel.com/) 24 | * https://developerrelations.com/jobs 25 | * https://devrelweekly.com/ 26 | * https://tinyletter.com/developeravocados 27 | -------------------------------------------------------------------------------- /what/devrel.tpl: -------------------------------------------------------------------------------- 1 | #!yaml-readme -p what/items/devrel-*.yaml --output what/devrel.md 2 | > 考虑到绝大部分做 DevRel 工作的人，是需要面向全球的，应该都有一定的英语基础，以下都采用英文编写。 3 | 4 | ## People 5 | Learning from other people who is doing the DevRel work might be a good idea. 6 | Please feel free to mainaintain the following table with me. 7 | 8 | | Name | Organization | Contact | 9 | |---|---|---| 10 | {{- range $val := .}} 11 | | {{link $val.name (default "" $val.blog)}} | {{$val.org}} | {{ghEmoji (default "" $val.github)}} {{twitterLink (default "" $val.twitter)}} {{youTubeLink (default "" $val.youtube)}}| 12 | {{- end}} 13 | 14 | ## Others 15 | * [Jobs in DevRel](https://jobsindevrel.com/) 16 | * https://developerrelations.com/jobs 17 | * https://devrelweekly.com/ 18 | * https://tinyletter.com/developeravocados 19 | -------------------------------------------------------------------------------- /what/items/devrel-adamd.yaml: -------------------------------------------------------------------------------- 1 | name: Adam DuVander 2 | twitter: adamd 3 | github: adamd 4 | -------------------------------------------------------------------------------- /what/items/devrel-anthonyLimo.yaml: -------------------------------------------------------------------------------- 1 | name: Anthony Kiplimo 2 | twitter: AnthonyLimo 3 | -------------------------------------------------------------------------------- /what/items/devrel-aprilspeight.yaml: -------------------------------------------------------------------------------- 1 | name: April Speight 2 | blog: https://www.vogueandcode.com/ 3 | twitter: vogueandcode 4 | github: aprilspeight 5 | youtube: vogueandcode 6 | -------------------------------------------------------------------------------- /what/items/devrel-arkodyuti.yaml: -------------------------------------------------------------------------------- 1 | name: Arkodyuti Saha 2 | twitter: arkodyutisaha 3 | github: arkodyuti 4 | -------------------------------------------------------------------------------- /what/items/devrel-hasson.yaml: -------------------------------------------------------------------------------- 1 | name: Hassan El Mghari 2 | blog: https://www.elmghari.com/ 3 | twitter: nutlope 4 | github: nutlope 5 | org: "[Vercel](https://github.com/vercel)" 6 | -------------------------------------------------------------------------------- /what/items/devrel-jennita.yaml: -------------------------------------------------------------------------------- 1 | name: Jen Sable Lopez 2 | twitter: jennita 3 | -------------------------------------------------------------------------------- /what/items/devrel-jono.yaml: -------------------------------------------------------------------------------- 1 | name: Jono Bacon 2 | blog: https://www.jonobacon.com/ 3 | twitter: jonobacon 4 | github: jonobacon 5 | youtube: jonobacon 6 | -------------------------------------------------------------------------------- /what/items/devrel-mary_grace.yaml: -------------------------------------------------------------------------------- 1 | name: Mary Thengvall 2 | github: nutlope 3 | -------------------------------------------------------------------------------- /what/items/devrel-matthewrevell.yaml: -------------------------------------------------------------------------------- 1 | name: Matthew Revell 2 | blog: https://www.matthewrevell.com/ 3 | twitter: matthewrevell 4 | github: matthewrevell 5 | youtube: 6 | -------------------------------------------------------------------------------- /what/items/devrel-michael.yaml: -------------------------------------------------------------------------------- 1 | name: Michael Heap 2 | blog: https://michaelheap.com/ 3 | twitter: mheap 4 | github: mheap 5 | youtube: mheap89 6 | org: "[Kong](https://github.com/Kong)" 7 | -------------------------------------------------------------------------------- /what/items/job-4paradigm.yaml: -------------------------------------------------------------------------------- 1 | name: 第四范式 2 | link: https://www.4paradigm.com/ 3 | jobs: 4 | - name: 开源社区运营 5 | link: https://app.mokahr.com/apply/4paradigm/5072#/job/216263fc-615f-4984-898b-790e6aebf643 6 | postDate: 2022-05-07 7 | -------------------------------------------------------------------------------- /what/items/job-aloudata.yaml: -------------------------------------------------------------------------------- 1 | name: 浙江大应科技 2 | link: https://aloudata.com/ 3 | jobs: 4 | - name: 开源布道师 5 | link: https://www.lagou.com/wn/jobs/10645168.html 6 | postDate: 2022-07-01 7 | package: 40k-60k·15薪 8 | -------------------------------------------------------------------------------- /what/items/job-amazon.yaml: -------------------------------------------------------------------------------- 1 | name: Amazon 2 | link: https://www.amazon.com/ 3 | jobs: 4 | - name: Senior Developer Advocate 5 | link: https://www.linkedin.cn/incareer/jobs/view/3072707705 6 | postDate: 2022-07-01 7 | -------------------------------------------------------------------------------- /what/items/job-bytedance.yaml: -------------------------------------------------------------------------------- 1 | name: 字节跳动 2 | link: https://www.bytedance.com/ 3 | jobs: 4 | - name: 开源布道师（数据仓库） 5 | link: https://www.lagou.com/wn/jobs/10491104.html 6 | postDate: 2022-07-01 7 | -------------------------------------------------------------------------------- /what/items/job-chainlink.yaml: -------------------------------------------------------------------------------- 1 | name: Chainlink 2 | link: https://chain.link/ 3 | jobs: 4 | - name: Developer Advocate 5 | link: https://mp.weixin.qq.com/s/cm1JaCi7V8syMBXP54_-7w 6 | postDate: 2022-02-20 7 | remote: true 8 | -------------------------------------------------------------------------------- /what/items/job-consensys.yaml: -------------------------------------------------------------------------------- 1 | name: ConsenSys 2 | link: https://consensys.net/ 3 | jobs: 4 | - name: Lead Developer Advocate (Snaps Platform) 5 | link: https://www.linkedin.cn/incareer/jobs/view/3117245696 6 | postDate: 2022-07-01 7 | -------------------------------------------------------------------------------- /what/items/job-illacloud.yaml: -------------------------------------------------------------------------------- 1 | name: 艾拉云科 2 | link: https://www.illacloud.com/ 3 | jobs: 4 | - name: 开源布道师 5 | link: https://www.zhipin.com/job_detail/f95573139a5220ad1Xd83968FVtT.html 6 | postDate: 2022-07-20 7 | package: 30-50K 8 | -------------------------------------------------------------------------------- /what/items/job-injoying.yaml: -------------------------------------------------------------------------------- 1 | name: 秒如科技 2 | link: http://www.lnjoying.com/ 3 | jobs: 4 | - name: 开源布道师 5 | link: https://www.zhipin.com/job_detail/75f964534f24dc6f1XZ_3d2-F1tQ.html 6 | postDate: 2022-07-20 7 | package: '28-55K·14薪' 8 | -------------------------------------------------------------------------------- /what/items/job-jetbrains.yaml: -------------------------------------------------------------------------------- 1 | name: Jetbrains 2 | link: https://www.jetbrains.com 3 | jobs: 4 | - name: Web and JavaScript Developer Advocate 5 | link: https://www.jetbrains.com/careers/jobs/web-and-javascript-developer-advocate-841/ 6 | postDate: 2022-02-20 7 | remote: true 8 | - name: Developer Advocate (PyCharm) 9 | link: https://www.linkedin.cn/incareer/jobs/view/2691921529 10 | postDate: 2022-01-01 -------------------------------------------------------------------------------- /what/items/job-jinaai.yaml: -------------------------------------------------------------------------------- 1 | name: Jina AI 2 | link: https://jina.ai/ 3 | jobs: 4 | - name: Open Source Technical Evangelist 5 | link: https://jobs.lever.co/jina-ai 6 | postDate: 2022-02-20 7 | remote: true 8 | -------------------------------------------------------------------------------- /what/items/job-nebula-graph.yaml: -------------------------------------------------------------------------------- 1 | name: Nebala Graph 2 | link: https://www.vesoft.com/ 3 | jobs: 4 | - name: 开发者布道师 5 | link: https://www.vesoft.com/cn/careers/#operation 6 | postDate: 2022-06-01 7 | remote: true 8 | - name: 技术社区运营总监 9 | link: https://www.vesoft.com/cn/careers/#operation 10 | postDate: 2022-06-01 11 | remote: false 12 | -------------------------------------------------------------------------------- /what/items/job-openKylin.yaml: -------------------------------------------------------------------------------- 1 | name: 麒麟软件 2 | link: https://www.kylinos.cn/ 3 | jobs: 4 | - name: 开源布道师 5 | link: https://www.zhipin.com/job_detail/2b774d6d010c392b1Xd-0ty6FVNV.html 6 | postDate: 2022-07-20 7 | package: '18-35K' 8 | -------------------------------------------------------------------------------- /what/items/job-orbit.yaml: -------------------------------------------------------------------------------- 1 | name: Orbit 2 | link: https://orbit.love/ 3 | jobs: 4 | - name: DevRel Analyst 5 | link: https://developerrelations.com/jobs/devrel-analyst-orbit 6 | postDate: 2022-05-24 7 | remote: true 8 | -------------------------------------------------------------------------------- /what/items/job-starrocks.yaml: -------------------------------------------------------------------------------- 1 | name: 鼎石纵横科技 2 | link: https://www.starrocks.com/ 3 | jobs: 4 | - name: 技术布道师 5 | link: https://www.zhipin.com/job_detail/2e3ae0fe37a900c31XVy3N6_EVVQ.html 6 | postDate: 2022-07-20 7 | package: '25-50K·16薪' 8 | -------------------------------------------------------------------------------- /what/items/job-streamnative.yaml: -------------------------------------------------------------------------------- 1 | name: StreamNative 2 | link: https://streamnative.io/ 3 | jobs: 4 | - name: evangelist 5 | link: https://www.v2ex.com/t/772924 6 | remote: true 7 | postDate: 2022-06-01 8 | -------------------------------------------------------------------------------- /what/items/job-taos.yaml: -------------------------------------------------------------------------------- 1 | name: 涛思数据 2 | link: https://www.taosdata.com/ 3 | jobs: 4 | - name: 开发者布道师 5 | link: https://www.zhipin.com/job_detail/9fa9fd4cfd10a8da1Xd_2NS0GVRW.html 6 | postDate: 2022-07-20 7 | package: '28-40K·16薪' 8 | -------------------------------------------------------------------------------- /what/items/job-weave.yaml: -------------------------------------------------------------------------------- 1 | name: Weaveworks 2 | link: https://www.weave.works/ 3 | jobs: 4 | - name: Developer Advocate/Experience Engineer 5 | link: https://developerrelations.com/jobs/developer-advocate-experience-engineer-weaveworks 6 | postDate: 2022-05-19 7 | remote: true 8 | -------------------------------------------------------------------------------- /what/jobs.md: -------------------------------------------------------------------------------- 1 | > This file was generated by [jobs.tpl](jobs.tpl) via [yaml-readme](https://github.com/LinuxSuRen/yaml-readme), please don't edit it directly! 2 | 3 | > 本文中，如没有特指的话，指的都是开源相关的，例如：社区指的是开源社区 4 | 5 | 本文介绍有哪些工作是与开源紧密关联的 6 | 7 | * 社区运营（Community Manager） 8 | * 开发者关系（DevRel，Developer Relations） 9 | * 技术布道师（Evangelist） 10 | * 文档工程师（Technical Writer） 11 | * 研发（Developer） 12 | 13 | ## Community Manager 14 | TODO 15 | 16 | ## DevRel 17 | DevRel（Developer Relations, or Develoepr Advocacy），在全球范围内还是相对比较新的一个岗位， 18 | 尤其在国内鲜有设立全职的岗位。很多在维护（主导）开源项目的公司，会让研发或社区运营人员兼职地做 DevRel 相关 19 | 的工作。 20 | 21 | DevRel 是一个有着成本投入却无法看到直接营收的团队。[Michael Heap](https://www.youtube.com/watch?v=tF-yhxOWEck&t=629s) 22 | 在 2021 年的 DevRelCon 上有着非常形象的描述：DevRel is a cost centre. 想要了解更多有关 DevRel 这个 23 | 岗位的资料，请查看[这里](devrel.md)。 24 | 25 | ## Evangelist 26 | TODO 27 | 28 | ## Technical Writer 29 | 通常来说，当开源商业化公司发展到一定阶段时，会招聘专职的 Technical Writer（技术文档工程师）。对于一个开源项目而言， 30 | 文档是极其重要的，因为文档可以让用户完整、详细地了解到项目。从内容输出的角度来看，文字相较于音频、视频而言是一种 31 | 成本相对低廉的形式，而且易于开源社区成员协作、共创。 32 | 33 | 更多有关改岗位的介绍，请查看[这里](tw.md)。 34 | 35 | ## Developer 36 | 对于技术类开源项目，研发人员显然是非常重要的一个角色，人数占比也比较大，甚至以开源项目为基础创业的商业公司的早期阶段中所有人员 37 | 都是研发。而越来越多的研发类 JD（Job Description）会把参与开源项目作为加分项之一。 38 | 39 | 但由于商业化模式的不同，对研发人员的要求也有着不同的要求，例如：关注项目最终用户数量的公司，与普通的商业化公司相差无几； 40 | 可那些关注开发者体验的公司，则更希望研发人员认同、拥抱开源理念。因此，研发人员在开源领域中寻找新的工作机会时，还是有必要事先 41 | 了解下目标公司的开源商业模式的。 42 | 43 | ## 公司 44 | > 如果您所在（或了解）的公司在维护开源项目，有响应的开源工作岗位的话，欢迎一起完善下面的列表。 45 | > 收录方式：请在目录 [items](items) 下添加文件名（格式：`job-xxx.yaml`）的 YAML 文件。 46 | > 文件内容请参考其他文件中的字段。 47 | 48 | > 注意：本列表只收集至少有一半工作时间在做开源相关事情的岗位。 49 | 50 | | Company | Job | Package | Remote | 51 | |---|---|---|---| 52 | | [第四范式](https://www.4paradigm.com/) | [开源社区运营](https://app.mokahr.com/apply/4paradigm/5072#/job/216263fc-615f-4984-898b-790e6aebf643) | | | 53 | | [浙江大应科技](https://aloudata.com/) | [开源布道师](https://www.lagou.com/wn/jobs/10645168.html) | 40k-60k·15薪 | | 54 | | [Amazon](https://www.amazon.com/) | [Senior Developer Advocate](https://www.linkedin.cn/incareer/jobs/view/3072707705) | | | 55 | | [字节跳动](https://www.bytedance.com/) | [开源布道师（数据仓库）](https://www.lagou.com/wn/jobs/10491104.html) | | | 56 | | [Chainlink](https://chain.link/) | [Developer Advocate](https://mp.weixin.qq.com/s/cm1JaCi7V8syMBXP54_-7w) | | :white_check_mark: | 57 | | [ConsenSys](https://consensys.net/) | [Lead Developer Advocate (Snaps Platform)](https://www.linkedin.cn/incareer/jobs/view/3117245696) | | | 58 | | [艾拉云科](https://www.illacloud.com/) | [开源布道师](https://www.zhipin.com/job_detail/f95573139a5220ad1Xd83968FVtT.html) | 30-50K | | 59 | | [秒如科技](http://www.lnjoying.com/) | [开源布道师](https://www.zhipin.com/job_detail/75f964534f24dc6f1XZ_3d2-F1tQ.html) | 28-55K·14薪 | | 60 | | [Jetbrains](https://www.jetbrains.com) | [Web and JavaScript Developer Advocate](https://www.jetbrains.com/careers/jobs/web-and-javascript-developer-advocate-841/) | | :white_check_mark: | 61 | | [Jetbrains](https://www.jetbrains.com) | [Developer Advocate (PyCharm)](https://www.linkedin.cn/incareer/jobs/view/2691921529) | | | 62 | | [Jina AI](https://jina.ai/) | [Open Source Technical Evangelist](https://jobs.lever.co/jina-ai) | | :white_check_mark: | 63 | | [Nebala Graph](https://www.vesoft.com/) | [开发者布道师](https://www.vesoft.com/cn/careers/#operation) | | :white_check_mark: | 64 | | [Nebala Graph](https://www.vesoft.com/) | [技术社区运营总监](https://www.vesoft.com/cn/careers/#operation) | | :x: | 65 | | [麒麟软件](https://www.kylinos.cn/) | [开源布道师](https://www.zhipin.com/job_detail/2b774d6d010c392b1Xd-0ty6FVNV.html) | 18-35K | | 66 | | [Orbit](https://orbit.love/) | [DevRel Analyst](https://developerrelations.com/jobs/devrel-analyst-orbit) | | :white_check_mark: | 67 | | [鼎石纵横科技](https://www.starrocks.com/) | [技术布道师](https://www.zhipin.com/job_detail/2e3ae0fe37a900c31XVy3N6_EVVQ.html) | 25-50K·16薪 | | 68 | | [StreamNative](https://streamnative.io/) | [evangelist](https://www.v2ex.com/t/772924) | | :white_check_mark: | 69 | | [涛思数据](https://www.taosdata.com/) | [开发者布道师](https://www.zhipin.com/job_detail/9fa9fd4cfd10a8da1Xd_2NS0GVRW.html) | 28-40K·16薪 | | 70 | | [Weaveworks](https://www.weave.works/) | [Developer Advocate/Experience Engineer](https://developerrelations.com/jobs/developer-advocate-experience-engineer-weaveworks) | | :white_check_mark: | 71 | 72 | And you could find open-source-related jobs from the following resources: 73 | - [todogroup/job-descriptions](https://github.com/todogroup/job-descriptions) 74 | -------------------------------------------------------------------------------- /what/jobs.tpl: -------------------------------------------------------------------------------- 1 | #!yaml-readme -p what/items/job-*.yaml --output what/jobs.md 2 | > 本文中，如没有特指的话，指的都是开源相关的，例如：社区指的是开源社区 3 | 4 | 本文介绍有哪些工作是与开源紧密关联的 5 | 6 | * 社区运营（Community Manager） 7 | * 开发者关系（DevRel，Developer Relations） 8 | * 技术布道师（Evangelist） 9 | * 文档工程师（Technical Writer） 10 | * 研发（Developer） 11 | 12 | ## Community Manager 13 | TODO 14 | 15 | ## DevRel 16 | DevRel（Developer Relations, or Develoepr Advocacy），在全球范围内还是相对比较新的一个岗位， 17 | 尤其在国内鲜有设立全职的岗位。很多在维护（主导）开源项目的公司，会让研发或社区运营人员兼职地做 DevRel 相关 18 | 的工作。 19 | 20 | DevRel 是一个有着成本投入却无法看到直接营收的团队。[Michael Heap](https://www.youtube.com/watch?v=tF-yhxOWEck&t=629s) 21 | 在 2021 年的 DevRelCon 上有着非常形象的描述：DevRel is a cost centre. 想要了解更多有关 DevRel 这个 22 | 岗位的资料，请查看[这里](devrel.md)。 23 | 24 | ## Evangelist 25 | TODO 26 | 27 | ## Technical Writer 28 | 通常来说，当开源商业化公司发展到一定阶段时，会招聘专职的 Technical Writer（技术文档工程师）。对于一个开源项目而言， 29 | 文档是极其重要的，因为文档可以让用户完整、详细地了解到项目。从内容输出的角度来看，文字相较于音频、视频而言是一种 30 | 成本相对低廉的形式，而且易于开源社区成员协作、共创。 31 | 32 | 更多有关改岗位的介绍，请查看[这里](tw.md)。 33 | 34 | ## Developer 35 | 对于技术类开源项目，研发人员显然是非常重要的一个角色，人数占比也比较大，甚至以开源项目为基础创业的商业公司的早期阶段中所有人员 36 | 都是研发。而越来越多的研发类 JD（Job Description）会把参与开源项目作为加分项之一。 37 | 38 | 但由于商业化模式的不同，对研发人员的要求也有着不同的要求，例如：关注项目最终用户数量的公司，与普通的商业化公司相差无几； 39 | 可那些关注开发者体验的公司，则更希望研发人员认同、拥抱开源理念。因此，研发人员在开源领域中寻找新的工作机会时，还是有必要事先 40 | 了解下目标公司的开源商业模式的。 41 | 42 | ## 公司 43 | > 如果您所在（或了解）的公司在维护开源项目，有响应的开源工作岗位的话，欢迎一起完善下面的列表。 44 | > 收录方式：请在目录 [items](items) 下添加文件名（格式：`job-xxx.yaml`）的 YAML 文件。 45 | > 文件内容请参考其他文件中的字段。 46 | 47 | > 注意：本列表只收集至少有一半工作时间在做开源相关事情的岗位。 48 | 49 | | Company | Job | Package | Remote | 50 | |---|---|---|---| 51 | {{- range $val := .}} 52 | 53 | {{- range $job := $val.jobs}} 54 | | {{link $val.name $val.link}} | [{{$job.name}}]({{$job.link}}) | {{$job.package}} | {{render $job.remote}} | 55 | {{- end}} 56 | 57 | {{- end}} 58 | 59 | And you could find open-source-related jobs from the following resources: 60 | - [todogroup/job-descriptions](https://github.com/todogroup/job-descriptions) 61 | -------------------------------------------------------------------------------- /what/tw.md: -------------------------------------------------------------------------------- 1 | > This file was generated by [tw.tpl](tw.tpl) via [yaml-readme](https://github.com/LinuxSuRen/yaml-readme), please don't edit it directly! 2 | 3 | > 本文主要讨论在开源项目中的 Technical Writter（以下简称 TW） 4 | 5 | ## 基本要求 6 | 众所周知，开源是面向全球的，通常都会对英语写作能力有着较高的要求。 7 | 8 | 下面是部分团队对英文的要求： 9 | 10 | * [通过英语专业八级考试（TEM-8，Test for English Majors-Band 8）](https://baike.baidu.com/item/%E8%8B%B1%E8%AF%AD%E4%B8%93%E4%B8%9A%E5%85%AB%E7%BA%A7%E8%80%83%E8%AF%95/6297184) 11 | 12 | 在不少的开源团队中，研发、TW 都会首先输出英文资料（文档、教程、博客等），而其他语言（中文、小语种）可能会考虑通过社区协作、内部员工等方式来输出。 13 | 14 | ## 常规工作 15 | TW 最基本的工作可以包括以下三部分： 16 | 17 | * 技术文档输出，这一点基本会随着开源项目的 feature 来迭代 18 | * Release notes、Changelog 19 | * 教程（文字、视频） 20 | 21 | 对于技术文档来说，要比其他两个相对复杂一些，往往需要 TW 对所负责的开源项目在技术层面有相对比较深入的了解，至少需要能够做到：了解必要的技术背景、简单的环境搭建、熟练地使用项目完成基本的 use case 等。除技术本身外，由于开源项目通常都会按照版本进行划分，而文档自然也需要提供对应的版本。 22 | 23 | 在语言之外，以下是开源项目中的主流技术搭配使用，也几乎可以认为是对 TW 的基本要求： 24 | 25 | * [熟练使用 GitHub](https://skills.github.com/)，以及可以在终端熟练地使用 [git](https://git-scm.com/) 命令 26 | * [Markdown](https://www.markdownguide.org/basic-syntax/) 常见语法的使用 27 | * [Hugo](https://github.com/gohugoio/) 等静态网站构建工具 28 | * Linux 基本操作 29 | 30 | ## 更多工作 31 | 在 TW 团队规模较大的情况下，往往会有更细致的分工，以及更多的职责。例如：社区具有一定规模的请下，TW 可能需要组织社区共建者（Contributor）参与到多语言的共建（Contribution）中，甚至还可能会成立、组织 SIG（Special Intested Group），并定期组织社区例会。 32 | 33 | 这时候，作为 TW 仅仅能完成技术文档的输出可能就显得不够了，熟悉、践行开源理念，并与开源同行进行更多的交流、互动会显得日益重要。如果说，某个开源项目的共建者（Contributors）都隶属于某家商业公司的话，从开源的角度来看这个项目其实是失败的，即便这个项目有着再多的 star 数，对于代码或文档类项目都是如此。 34 | 35 | ## 协作 36 | 作为 TW 往往需要与不同角色的人进行合作，例如：产品经理、研发、测试、运营、市场等，尤其会和研发有着紧密的协作。在与不同角色、背景的人合作时，如果能了解、掌握一些沟通技巧时，往往可以有事半功倍的效果。以下，针对不同角色的人合作，提供一些技巧。 37 | 38 | 在国内很多人交流后，有个相对普遍的观点是：研发往往不太喜欢写文档，工作安排普遍紧张（难以抽出时间来），写的文档容易出现省略基本的技术背景介绍等等。（在没有数据统计的情况下，这些论断可能是相对主观的，仅供参考）针对以上提出来的一些问题，笔者认为都是有相应原因的，了解这些背后的缘由，则可以帮助我们更好地互相理解、协作。 39 | 40 | 选择从事研发工作的人，往往对逻辑性的问题比较有兴趣，而在他们的职业生涯中如果没有对文档编写有过硬性要求的话，随着时间的推移，对文字编写、自然语言的技能则逐渐弱化。而从心理学的角度来看，人们通常会不由自主地选择逃避自己的“短板”。这可能是“研发不爱写文档”的一个典型原因。 41 | 42 | 而对于研发工作量大、没时间写文档等，则是一个具体的现象，并不是 TW 在与研发合作编写文档时遇到的困境的原因。假如，研发负责人（甚至在整个公司、团队的理念、文化中）并不认为文档属于软件交付过程中不可缺少的一部分，或者是认为研发只要输出代码即可，那么，在安排工作时就不会给文档编写预留足够的时间。在这样的公司理念的影响下，研发人员就会自然地以工作繁忙为理由选择推脱甚至拒绝相应的文档工作。简单来说，这是自上而下产生的问题。 43 | 44 | 至于文档编写过程中，可能会缺少一些必要的技术背景介绍，则也许是由于缺少训练而导致的一个普遍性的问题。除非是有着非常资深背景的人，在很多情况下，研发人员不会有编写大量文档的机会，很难在短时间内克服；这也正是需要专业 TW 加入的理由。 45 | 46 | 从每一位 TW 和整个公司、团队的角度，可以考虑不同的解决方案： 47 | 48 | 在自上而下管理风格的团队中，想要通过提出建议而改善情况有可能会逐渐演变为你讨厌团队的导火索。但笔者追求的是，把感性的烦恼转换为理性的思考，以更加健康、可持续的姿态来对面问题、解决问题。当然，这里不是反对大家给团队提出你的宝贵建议，而提倡的是以“无心插柳”的心态来提建议。以人为本，把与你合作的研发当做良师益友来看，他（她）也会有职业上、工作上的困扰，试着去了解并与之一起解决，至少可以推心置腹地进行几次沟通；相信在帮助对方过程中，他（她）也会尊重、理解、配合你的工作。 49 | 50 | 如果有能力从整个公司、团队角度来改善、解决这个问题的话，可以考虑强制约束研发要写文档，以及在新人招聘的流程中加上对文档技能的考察，并告知公司对文档编写的相关规定。当然，团队管理本身是一个非常复杂的话题，这里无法一一展开，实际落地过程中也会遇到各种各样的问题，坚持做对的事情并及时复盘（review）可以助你一臂之力。 51 | 52 | ## 成长路径 53 | 对于 TW 的成长路径，笔者认为除了可以从初级、中级、高级这些职级上来衡量，也可以从对 TW 这个行业甚至跨行业的视角从细节到整体再到细节的来考量，稍微具体一点的话，可以参考下面的表述： 54 | 55 | * 完成团队分配到自己的任务 56 | * 能够发现本职工作以外的问题并协同解决 57 | * 能够组织同事（同行）解决更大层面上的问题 58 | * 开始关注、了解整个行业的现象、事件与发展趋势 59 | * 逐渐能够在行业交流（会议、论坛、社交网络）中发表自己的观点 60 | * 未知的跨域探索 61 | 62 | ## Credit 63 | 64 | Thanks for all those friends who helped me with this project. 65 | 66 | * [Sherlock Xu](https://github.com/Sherlock113) (Content Strategist | Localisation Engineer | Kubernetes Certified (CKS/CKA/CKAD)) 67 | * [Sylvia](https://github.com/SylviaBABY) (🍓づ♡ど🍓) 68 | * [Fei Han](https://github.com/hf400159) (Study hard and you'll improve everyday.) 69 | -------------------------------------------------------------------------------- /what/tw.tpl: -------------------------------------------------------------------------------- 1 | #!yaml-readme -p *.yaml --output what/tw.md 2 | > 本文主要讨论在开源项目中的 Technical Writter（以下简称 TW） 3 | 4 | ## 基本要求 5 | 众所周知，开源是面向全球的，通常都会对英语写作能力有着较高的要求。 6 | 7 | 下面是部分团队对英文的要求： 8 | 9 | * [通过英语专业八级考试（TEM-8，Test for English Majors-Band 8）](https://baike.baidu.com/item/%E8%8B%B1%E8%AF%AD%E4%B8%93%E4%B8%9A%E5%85%AB%E7%BA%A7%E8%80%83%E8%AF%95/6297184) 10 | 11 | 在不少的开源团队中，研发、TW 都会首先输出英文资料（文档、教程、博客等），而其他语言（中文、小语种）可能会考虑通过社区协作、内部员工等方式来输出。 12 | 13 | ## 常规工作 14 | TW 最基本的工作可以包括以下三部分： 15 | 16 | * 技术文档输出，这一点基本会随着开源项目的 feature 来迭代 17 | * Release notes、Changelog 18 | * 教程（文字、视频） 19 | 20 | 对于技术文档来说，要比其他两个相对复杂一些，往往需要 TW 对所负责的开源项目在技术层面有相对比较深入的了解，至少需要能够做到：了解必要的技术背景、简单的环境搭建、熟练地使用项目完成基本的 use case 等。除技术本身外，由于开源项目通常都会按照版本进行划分，而文档自然也需要提供对应的版本。 21 | 22 | 在语言之外，以下是开源项目中的主流技术搭配使用，也几乎可以认为是对 TW 的基本要求： 23 | 24 | * [熟练使用 GitHub](https://skills.github.com/)，以及可以在终端熟练地使用 [git](https://git-scm.com/) 命令 25 | * [Markdown](https://www.markdownguide.org/basic-syntax/) 常见语法的使用 26 | * [Hugo](https://github.com/gohugoio/) 等静态网站构建工具 27 | * Linux 基本操作 28 | 29 | ## 更多工作 30 | 在 TW 团队规模较大的情况下，往往会有更细致的分工，以及更多的职责。例如：社区具有一定规模的请下，TW 可能需要组织社区共建者（Contributor）参与到多语言的共建（Contribution）中，甚至还可能会成立、组织 SIG（Special Intested Group），并定期组织社区例会。 31 | 32 | 这时候，作为 TW 仅仅能完成技术文档的输出可能就显得不够了，熟悉、践行开源理念，并与开源同行进行更多的交流、互动会显得日益重要。如果说，某个开源项目的共建者（Contributors）都隶属于某家商业公司的话，从开源的角度来看这个项目其实是失败的，即便这个项目有着再多的 star 数，对于代码或文档类项目都是如此。 33 | 34 | ## 协作 35 | 作为 TW 往往需要与不同角色的人进行合作，例如：产品经理、研发、测试、运营、市场等，尤其会和研发有着紧密的协作。在与不同角色、背景的人合作时，如果能了解、掌握一些沟通技巧时，往往可以有事半功倍的效果。以下，针对不同角色的人合作，提供一些技巧。 36 | 37 | 在国内很多人交流后，有个相对普遍的观点是：研发往往不太喜欢写文档，工作安排普遍紧张（难以抽出时间来），写的文档容易出现省略基本的技术背景介绍等等。（在没有数据统计的情况下，这些论断可能是相对主观的，仅供参考）针对以上提出来的一些问题，笔者认为都是有相应原因的，了解这些背后的缘由，则可以帮助我们更好地互相理解、协作。 38 | 39 | 选择从事研发工作的人，往往对逻辑性的问题比较有兴趣，而在他们的职业生涯中如果没有对文档编写有过硬性要求的话，随着时间的推移，对文字编写、自然语言的技能则逐渐弱化。而从心理学的角度来看，人们通常会不由自主地选择逃避自己的“短板”。这可能是“研发不爱写文档”的一个典型原因。 40 | 41 | 而对于研发工作量大、没时间写文档等，则是一个具体的现象，并不是 TW 在与研发合作编写文档时遇到的困境的原因。假如，研发负责人（甚至在整个公司、团队的理念、文化中）并不认为文档属于软件交付过程中不可缺少的一部分，或者是认为研发只要输出代码即可，那么，在安排工作时就不会给文档编写预留足够的时间。在这样的公司理念的影响下，研发人员就会自然地以工作繁忙为理由选择推脱甚至拒绝相应的文档工作。简单来说，这是自上而下产生的问题。 42 | 43 | 至于文档编写过程中，可能会缺少一些必要的技术背景介绍，则也许是由于缺少训练而导致的一个普遍性的问题。除非是有着非常资深背景的人，在很多情况下，研发人员不会有编写大量文档的机会，很难在短时间内克服；这也正是需要专业 TW 加入的理由。 44 | 45 | 从每一位 TW 和整个公司、团队的角度，可以考虑不同的解决方案： 46 | 47 | 在自上而下管理风格的团队中，想要通过提出建议而改善情况有可能会逐渐演变为你讨厌团队的导火索。但笔者追求的是，把感性的烦恼转换为理性的思考，以更加健康、可持续的姿态来对面问题、解决问题。当然，这里不是反对大家给团队提出你的宝贵建议，而提倡的是以“无心插柳”的心态来提建议。以人为本，把与你合作的研发当做良师益友来看，他（她）也会有职业上、工作上的困扰，试着去了解并与之一起解决，至少可以推心置腹地进行几次沟通；相信在帮助对方过程中，他（她）也会尊重、理解、配合你的工作。 48 | 49 | 如果有能力从整个公司、团队角度来改善、解决这个问题的话，可以考虑强制约束研发要写文档，以及在新人招聘的流程中加上对文档技能的考察，并告知公司对文档编写的相关规定。当然，团队管理本身是一个非常复杂的话题，这里无法一一展开，实际落地过程中也会遇到各种各样的问题，坚持做对的事情并及时复盘（review）可以助你一臂之力。 50 | 51 | ## 成长路径 52 | 对于 TW 的成长路径，笔者认为除了可以从初级、中级、高级这些职级上来衡量，也可以从对 TW 这个行业甚至跨行业的视角从细节到整体再到细节的来考量，稍微具体一点的话，可以参考下面的表述： 53 | 54 | * 完成团队分配到自己的任务 55 | * 能够发现本职工作以外的问题并协同解决 56 | * 能够组织同事（同行）解决更大层面上的问题 57 | * 开始关注、了解整个行业的现象、事件与发展趋势 58 | * 逐渐能够在行业交流（会议、论坛、社交网络）中发表自己的观点 59 | * 未知的跨域探索 60 | 61 | ## Credit 62 | 63 | Thanks for all those friends who helped me with this project. 64 | 65 | * {{gh "Sherlock113" true}} 66 | * {{gh "sylviababy" true}} 67 | * {{gh "hf400159" true}} 68 | -------------------------------------------------------------------------------- /why/why-open-source.md: -------------------------------------------------------------------------------- 1 | 本文从以下几个角度来探讨为什么要参与开源 2 | * 为什么要把软件（项目）开源 3 | * 个人为什么要开源 4 | * 企业为什么要开源 5 | * 什么项目适合开源 6 | * 什么人可以参与开源 7 | * 我们为什么要参与开源 8 | -------------------------------------------------------------------------------- /workgroup.md: -------------------------------------------------------------------------------- 1 | 2 | ## 采用 Work Group 的开源社区 3 | 4 | | 名称 | 备注 | 5 | |---|---| 6 | | [Harbor](https://github.com/goharbor/community) | 由 VMware 开源出来的镜像管理平台 | 7 | | [KubeEdge](https://github.com/kubeedge/community) | 边缘计算 | 8 | -------------------------------------------------------------------------------- /workshop.md: -------------------------------------------------------------------------------- 1 | 对于技术类社区，Workshop（工作坊）是一种比较常见的活动形式，可以作为 Meetup 的配合或补充。不像 Meetup 那样，Workshop 通常没有主题分享， 2 | 而是以动手为主。因此，有时候大家也把 Workshop 叫做“动手训练营”。 3 | 4 | 在 Workshop 中，大致会有三类角色的人参与： 5 | 6 | * 教练（导师），通过演示、安排任务等方式来给参与者展示某种技术的使用方法 7 | * 助理，对于人数相对较多（例如：20+）情况，教练可能无法做到对所有参与者的疑问一一解答，这时候助理就可以帮助解答 8 | * 学员，也就是对某种技术感兴趣的人群 9 | 10 | 活动形式上，相比于常规的分享类活动，也有一些要求： 11 | 12 | * 确保每位参与者都有放置**笔记本电脑**的座椅 13 | * 足够的**插线板** 14 | * 尽量有公共可用的 **WIFI** 15 | 16 | ## 常规 17 | 18 | TODO 19 | 20 | ## 沉浸式 21 | 22 | 所谓“沉浸式"旨在让参与者有机会深度了解、参与到某个开源项目中，甚至能“及时”收到项目维护者（maintainer、reviewer）的反馈。 23 | 这对于接触开源时间不长的人群，是非常有帮助的。 24 | 25 | 为了让参与者可以相对容易地了解某个开源项目的参与方式，预先准备 [good-first-issue](good-first-issue.md) 若干。 26 | 准备好的 issue 可以在发布活动时一并给出，方便感兴趣的参与者提前了解。 27 | 28 | 另外，非常重要的一个环节是 reviewer 团队。建议事先邀请一些 reviewer，在活动期间及时给与 PR（Pull Request）相应反馈（comment）。 29 | 如果 reviewer 分别在线上、线下（活动现场）都有的话，更符合常规的开源贡献流程，效果更佳。 30 | 31 | 活动的流程可以参考如下： 32 | 33 | * 开场，介绍本次活动的背景、大致流程 34 | * 参考时间：10 分钟 35 | * 介绍活动中涉及的 issue，可以讲解下相关技术背景、大致解决思路 36 | * 参考时间：30 分钟 37 | 38 | * 大家自行挑选 issue 来做 39 | * 参考时间：2 小时，和 review 同步 40 | * 项目维护者对提交的 PR 进行 review 41 | * 大家共同讨论、分析参与者的参与过程，并给出建议 42 | * 参考时间：2 小时 43 | 44 | 建议给活动预留 5 个小时左右，让项目维护者与贡献者得以充分交流。 45 | --------------------------------------------------------------------------------