Cộng đồng thật khó khăn. Chúng khó xây dựng, khó duy trì và khó phát triển. Tuy nhiên, xây dựng cộng đồng là một trong những điều bổ ích nhất trong sự nghiệp của tôi, bởi vì tôi đã gặp rất nhiều người tuyệt vời và buộc phải học hỏi cũng như làm những việc ngoài vùng an toàn của mình.
Tôi nhớ hơn 10 năm trước, tôi đã tham dự hội nghị công nghệ nhỏ đầu tiên của mình - CouchConf ở Berlin. May mắn thay, có một Cuộc gặp gỡ BerlinJS diễn ra cùng thời điểm và tôi đã rất ấn tượng với cộng đồng và mọi người. Họ có kho lưu trữ GitHub được thiết lập cho trang web và các cuộc thảo luận được gửi dưới dạng Vấn đề về GitHub. Tôi rất ngạc nhiên trước sự đơn giản và minh bạch của quy trình, vì vậy tôi đã phân nhánh repo và thành lập BarcelonaJS vài tuần sau đó. Đây là sự khởi đầu trong hành trình tổ chức của riêng tôi.
Một giai thoại nhỏ về một trải nghiệm thường xuyên và rất bực bội: Bạn đã dành hàng giờ để chuẩn bị, giao tiếp, tìm và mời diễn giả, tìm và đảm bảo ngày và địa điểm, nói chuyện với các nhà tài trợ về đồ ăn và đồ uống để cùng nhau tổ chức một sự kiện tuyệt vời. Và khi đến lúc, bạn đang ngồi đó một mình hoặc với một phần nhỏ những người mà bạn nghĩ sẽ đến, bởi vì Meetup nói "150 người trả lời CÓ". Và trong một trường hợp hiếm hoi đó chỉ là do thời tiết không may mắn, nhưng sau đó thường xuyên hơn khi nói chuyện với mọi người, tôi nghe thấy điều này:
Điều này thật tuyệt vời, tôi ước gì mình đã ở đó, nhưng tôi không biết!
Cụm từ này là động lực để tôi bắt đầu khám phá GitHub như một công cụ cộng đồng vì GitHub là một trong những nền tảng tuyệt vời nhất về tự động hóa và đó là điều bạn cần làm với tư cách là người tổ chức: tự động hóa mọi thứ để xuất bản sự kiện trên Eventbrite, Meetup, Twitter, Facebook, Telegram Groups, WhatsApp, Email, Lịch, v.v., v.v. và thực hiện điều đó 2 tuần trước, 1 tuần trước, 3 ngày trước, 1 ngày trước, 1 giờ trước sự kiện để không ai có thể nói gì sau đó : "Tôi không biết về điều này". Bởi vì suy cho cùng, bạn không làm điều này vì bản thân mà vì cộng đồng.
Trong chuyến du lịch của mình, tôi đã gặp các cộng đồng Node.js và JavaScript trên Meetup với hàng nghìn thành viên, nhưng không có một sự kiện nào sắp diễn ra hoặc gần đây. Điều này có thể xảy ra vì nhiều lý do, nhưng thường là do ban tổ chức không có thời gian hoặc đã chuyển sang việc khác và khó tìm được người kế nhiệm để duy trì hoạt động. Meetup và các nền tảng khác rất tốt cho việc khám phá cộng đồng và sự kiện, nhưng chúng khiến các thành viên khó tiếp cận với cộng đồng trong trường hợp người tổ chức không còn hoạt động và tiếp quản/hồi sinh cộng đồng.
Là một nhà phát triển, tôi dành nhiều thời gian cho GitHub và quen thuộc với các công cụ cũng như quy trình làm việc, vì vậy tôi bắt đầu khám phá cách sử dụng GitHub làm nền tảng cộng đồng.
Lợi ích đầu tiên và rõ ràng nhất là các kho lưu trữ công khai trên GitHub là Nguồn mở. Điều này có nghĩa là tất cả nội dung, vấn đề và cuộc thảo luận đều được công khai và bất kỳ ai cũng có thể phân nhánh, sao chép và sử dụng lại. Điều này rất tốt cho cộng đồng vì nó có nghĩa là nếu cộng đồng bị bỏ rơi thì bất kỳ ai cũng có thể phân nhánh và tiếp tục công việc. Điều đó cũng có nghĩa là nếu bạn muốn bắt đầu một cộng đồng mới, bạn có thể phân nhánh một cộng đồng hiện có và điều chỉnh nó cho phù hợp với nhu cầu của bạn.
GitHub đã tích hợp sẵn tính năng quản lý người dùng/nhóm/tổ chức, vì vậy bạn không cần phải tự mình xây dựng bất cứ thứ gì. Thật dễ dàng để mời ai đó vào tổ chức hoặc thêm các nhóm có các quyền khác nhau của tổ chức.
Hầu hết chúng ta đều biết cách sử dụng GitHub và truy cập trang web hàng ngày, do đó không cần phải đánh dấu trang bổ sung để quản trị cơ sở dữ liệu, quản lý nội dung hoặc các công cụ khác. Với GitHub Actions, chúng tôi có thể chạy các tác vụ tự động theo lịch trình hoặc theo yêu cầu và với Trang GitHub, chúng tôi có thể lưu trữ trang web cộng đồng của mình miễn phí.
Đối với tôi, một trong những lợi ích quan trọng nhất của việc xây dựng cộng đồng trên GitHub là tính minh bạch hoàn toàn và giao tiếp cởi mở. Mọi thứ[1] đều công khai nên không cần phải lo lắng về việc ai có quyền truy cập vào nội dung gì. Điều này có nghĩa là bất kỳ ai cũng có thể đóng góp cho cộng đồng và bất kỳ ai cũng có thể xem điều gì đang diễn ra. Điều này rất tốt cho việc xây dựng lòng tin và xây dựng một cộng đồng hòa nhập và chào đón tất cả mọi người.
Mục tiêu của tôi với các cộng đồng như BarcelonaJS, CDC, v.v. là tạo ra không gian mở và miễn phí để các nhà phát triển chia sẻ và kết nối. Và "miễn phí" là nơi cần có sự minh bạch. Trước đây, tôi luôn tránh xa việc đóng góp tài chính. Nếu một công ty muốn tài trợ, họ có thể đặt đồ ăn hoặc đồ uống trực tiếp đến địa điểm, nhưng tôi sẽ không tạo điều kiện. Nhờ có Open Collective , việc này đã trở nên dễ dàng hơn nhiều và giờ đây chúng tôi có thể chấp nhận các khoản đóng góp tài chính và làm cho chúng trở nên minh bạch với cộng đồng. Ví dụ: chúng được sử dụng để thanh toán cho (các) tên miền, mua đồ ăn và đồ uống, chạy chiến dịch quảng cáo, v.v.
[1] tất nhiên, bạn cũng có thể tạo một kho lưu trữ riêng cho các cuộc thảo luận của người tổ chức nội bộ, v.v.
GitHub không phải là Nền tảng cộng đồng/sự kiện như Meetup, vì vậy có một số lưu ý. Tôi đã quen với việc coi Vấn đề là "Sự kiện" hoặc "Đề xuất thảo luận" và Biểu mẫu vấn đề GitHub để cấu trúc nội dung gửi. Nhưng nó không lý tưởng và cần có thời gian để người mới hiểu "Tạo vấn đề để gửi bài nói". Không có "tính năng tiện lợi" nào để chọn ngày, vị trí trên bản đồ, v.v. và kích hoạt thông báo email đơn giản tới hàng trăm người.
Toàn bộ khái niệm này chủ yếu tập trung vào các nhà phát triển và kỹ sư vì nó phát triển dựa trên GitHub và IssueOps. Để đưa ra ý tưởng về kinh nghiệm trước đây của tôi, đây là một số cộng đồng và hội nghị mà tôi đã giúp xây dựng:
Trong khi xây dựng những thứ này, tôi đã liên tục làm việc trên một bộ công cụ, quy trình làm việc và tự động hóa để giúp cuộc sống của những người tổ chức trở nên dễ dàng hơn vì đó là một công việc khó khăn và thường không được cảm ơn. Vì vậy, đây là Khái niệm Cộng đồng Mở của tôi về cách tôi xây dựng một cộng đồng công khai trên GitHub.
Bước đầu tiên là thành lập tổ chức GitHub và tạo hai kho lưu trữ:
Những cái tên này rất rõ ràng: trong kho sự kiện là các mẫu để tạo sự kiện mới và trong kho lưu trữ các cuộc thảo luận là các mẫu để gửi đề xuất thảo luận . Các cuộc thảo luận có thể được liên kết với các sự kiện để xây dựng chương trình nghị sự và nếu bạn thu hút được sự tham gia từ cộng đồng (hãy nhớ: thật khó!), các nhận xét và phản ứng như 👍 hoặc ❤️ có thể được sử dụng để bỏ phiếu cho các cuộc thảo luận.
Bạn cũng có thể sử dụng Dự án GitHub để quản lý vòng đời sự kiện thông qua các giai đoạn đề xuất, lên lịch và thông báo:
Ở Síp, chúng tôi đã thêm nhãn cho các khu vực khác nhau trên đảo, nhưng quan trọng nhất là cần có nhãn "Đã phê duyệt". Tất cả các vấn đề mới được tạo với nhãn "Sự kiện", nhưng chỉ người nào có quyền "phân loại" (nhóm tổ chức) mới có thể "phê duyệt" sự kiện. Điều này rất quan trọng để tránh thư rác và đảm bảo sự kiện có liên quan.
Bây giờ đã có một tổ chức, một số kho lưu trữ có vấn đề và một số cấu trúc đã sẵn sàng, đã đến lúc tự động hóa.
GitEvents / GitEvents trên GitHub đã quay trở lại (2014) và bắt đầu với cái tên gitup
như một sự hợp tác "hack cuối tuần" giữa Nhóm người dùng nút London (LNUG) và Nhóm Barccelona Node.js. Trước đó, GitHub Actions chưa tồn tại và chúng tôi đã cố gắng sử dụng Webhooks để giải quyết các vấn đề nhằm xây dựng dữ liệu có cấu trúc cho các trang web được lưu trữ trên GitHub dựa trên dữ liệu Meetup.com. Việc thiết lập rất phức tạp và dự án đã bị bỏ dở một thời gian.
Ngày nay, GitEvents là một tập hợp các Hành động GitHub đơn giản để tự động hóa quy trình xử lý sự cố. "Git Ops" dành cho các cuộc gặp gỡ và sự kiện. Tất cả những gì cần thiết là Tổ chức GitHub và Ứng dụng GitHub. Một số tính năng là:
iCal
là một tiêu chuẩn cho các sự kiện lịch. Mọi người chỉ có thể thêm phần này dưới dạng đăng ký vào lịch của mình để cập nhật các sự kiện cộng đồng. Chúng tôi đã tạo một chuyển hướng đến tệp github để mọi người có thể đăng ký lịch bằng một liên kết đơn giản: https://calendar.cdc.cy .
Mọi thứ đều "cắm và chạy" nên bạn có thể chọn Hành động mình thích và việc kết hợp chúng thành quy trình làm việc tương đối dễ dàng. Để biết ví dụ, hãy xem Quy trình làm việc của Cộng đồng nhà phát triển Síp .
Nếu bạn muốn bắt đầu với GitEvents và cần một số trợ giúp, vui lòng liên hệ với Máy chủ Discord của chúng tôi. GitEvents là một công việc đang được tiến hành và luôn có nhiều việc phải làm , đặc biệt là với việc tích hợp với các nền tảng khác, v.v. Nếu bạn muốn trợ giúp, vui lòng liên lạc.
Biểu mẫu phát hành vẫn là một tính năng tương đối ít được biết đến trên GitHub. Thay vì các mẫu Markdown thông thường, tệp YAML có thể được cung cấp cấu hình biểu mẫu.
Điều này khá thú vị để có được đầu vào có cấu trúc, nhưng sau khi được lưu dưới dạng "Vấn đề", dữ liệu sẽ vô dụng về mặt ngữ nghĩa vì đó chỉ là Markdown. Tôi đã thử nghiệm với Cột mốc, tiêu đề Markdown, Nhãn, v.v. để thêm thông tin ngữ nghĩa như ngày, vị trí, v.v. vào một vấn đề, nhưng không có gì hoạt động tốt. Vì vậy, tôi bắt đầu xây dựng GitHub Issue Forms Body Parser . Điều này giúp phân tích cú pháp một vấn đề được tạo thông qua một biểu mẫu để trích xuất ngày tháng, liên kết, hình ảnh, danh sách, v.v. và chuyển đổi chúng thành dữ liệu JSON có cấu trúc. Điều này có thể được chuyển trực tiếp sang các nền tảng khác như Discord, EventBrite, Meetup, v.v. hoặc được sử dụng trong gửi thư, tweet, v.v.
Trình phân tích nội dung biểu mẫu phát hành cũng có sẵn trên npm
dưới dạng thư viện để phân tích bất kỳ văn bản Markdown nào. Chỉ gần đây tôi mới nhận ra toàn bộ tệp README.md
có thể được phân tích cú pháp để cấu trúc dữ liệu cho một trang web:
query ($organization: String!, $repository: String!) { repository(owner: $organization, name: $repository) { id name object(expression: "main:README.md") { ... on Blob { text } } } }
Đây là truy vấn để truy xuất nội dung tệp từ nhánh main
của kho lưu trữ và bạn có thể chuyển nội dung đó vào "trình phân tích cú pháp nội dung":
const structuredData = await bodyParser(readmeFile()?.repository.object.text)
Thay vì giữ lại một bản sao mô tả cộng đồng của bạn, giờ đây bạn có thể tìm nạp phần About
từ tệp README.md
và sử dụng nó trên trang web của mình.
Với trang web https://cdc.cy mới nhất, tôi muốn khám phá và vượt qua ranh giới về những gì có thể làm được với Sự cố, tệp README.md
và dữ liệu JSON có cấu trúc và tôi khá hài lòng với kết quả này:
README.md
hoặc .json
trên GitHub; mọi người đều có thể chỉnh sửa, không cần CMS hoặc tài khoản, v.v.events
)
Tất cả các tính năng này đều có thể thực hiện được thông qua API GraphQL và bằng cách phân tích cú pháp các tệp Markdown bằng trình phân tích cú pháp nội dung.
Tôi đã nghiên cứu ý tưởng này được một thời gian và thỉnh thoảng nó vẫn thay đổi hình dạng. Nhưng những ý tưởng cơ bản tôi áp dụng từ BerlinJS vẫn không thay đổi:
Việc xây dựng tất cả những thứ này đã tiêu tốn rất nhiều thời gian và sức lực và vẫn còn thiếu rất nhiều thứ mà tôi không có thời gian để làm:
Nếu bạn cho rằng điều này có thể giúp ích cho bạn và cộng đồng của bạn cũng như muốn tham gia vào việc ghép các câu đố lại với nhau, vui lòng liên hệ trên Máy chủ Discord của gevents , trên Thảo luận GitHub hoặc trực tiếp trên một trong các Vấn đề của GitHub .
Nếu bạn ở Síp hoặc Barcelona , vui lòng tham gia và hỗ trợ các nhóm nhà phát triển địa phương.