Các công cụ cơ bản để quản lý một dự án do cộng đồng dẫn dắt

Essential tools for running a community-led project

By Ross Gardler, Published: 22 February 2011, Reviewed: 13 February 2012

Theo: http://www.oss-watch.ac.uk/resources/communitytools

Bài được đưa lên Internet ngày: 13/02/2012

Lời người dịch: Có rất nhiều công cụ để quản lý một dự án phần mềm nguồn mở do cộng đồng dẫn dắt. Tuy nhiên, bộ công cụ nào là phù hợp nhất cho dự án của bạn, cần có sự lựa chọn cân nhắc. “Có các công cụ đúng cho dự án của bạn sẽ làm cho dễ dàng hơn để quản lý bản thân dự án, bất kể liệu bạn có lôi cuối được một cộng đồng hay không. Tuy nhiên, việc có các công cụ chỉ là sự khởi đầu, bạn cũng cần sử dụng chúng theo một cách nhất quán và dự đoán trước được. Nếu bạn sử dụng các công cụ đúng từ đầu thì bạn sẽ tránh được nhiều đau đớn và tạo ra được những điều kiện có thể là tốt nhất cho việc xây dựng một cộng đồng (bản dịch tiếng Việt) xung quanh dự án của bạn khi thời gian là đúng”.

Không có cách duy nhất đúng nào để xây dựng và quản lý một dự án do cộng đồng dẫn dắt, nhưng có những công cụ và những thực tiễn chung mà chúng ta có thể sử dụng để hỗ trợ cho công việc của chúng ta. Mấu chốt là sử dụng các công cụ phù hợp cho cộng đồng của bạn và giữ cho chúng là tối thiểu trần trụi. Trong tài liệu này, chúng tôi xem xét các công cụ là phổ biến cho hầu hết các dự án nguồn mở và gợi ý các cách thức theo đó bạn có thể sử dụng chúng để xây dựng cộng đồng.

Các công cụ nên tạo thuận lợi, chứ không áp đặt

Nhiều người nghĩ rằng việc mở trong một dự án là về việc bỏ ra một lượng thời gian thất thường để thông báo cho mọi người về các hoạt động hiện hành. Nhưng điều cần thiết này không phải là thế. Nếu bạn thận trọng về việc lựa chọn các công cụ và qui trình phát triển mà bạn sử dụng chúng, thì mức độ phù hợp của giao tiếp với bên ngoài đơn giản sẽ là một qui trình phát triển theo sản phẩm.

Để hiểu được cách mà điều này có thể là đúng, chúng ta đầu tiên cần hiểu được rằng mục tiêu của việc mở không phải để đảm bảo rằng mọi người hiểu những gì đang diễn ra tại bất kỳ thời điểm nào trong sự phát triển. Thay vào đó, nó là việc việc xúc tác cho những người với lợi ích đủ để tìm ra thông tin mà họ cần. Bằng việc chỉ tập trung vào những người có đủ quan tâm để làm công việc ở nhà, chúng ta giảm thiểu nhu cầu đối với các thành viên hiện đang tồn tại của cộng đồng để nắm tay dẫn dắt những người mới tới. Điều này cho phép họ tập trung đầy đủ hơn vào việc có được các kết quả mà họ tìm kiếm. Điều này có thể dường như được tính tới mục tiêu của việc xây dựng cộng đồng, vì thế hãy chọn nó ra ngoài lề một chút.

Trong một dự án do cộng đồng dẫn dắt, mọi người tham gia để làm thỏa mãn các nhu cầu của riêng họ - bạn có thể gọi nó là 'gãi từng tí một'. Vì thế động lực chính của một cá nhân sẽ không phải là xây dựng một cộng đồng, mà để giải quyết một vấn đề cụ thể mà họ đối mặt trong công việc, học tập hoặc sở thích riêng của họ. Vì lý do này, dự án nên được quản lý theo một cách thức sao cho qui trình và cộng đồng về tổng thể không đi vào con đường của những người đang theo đuổi những lợi ích của họ.

Nói vậy, một dự án nguồn mở được quản lý tốt (bản dịch tiếng Việt) sẽ có một tập hợp các qui trình và công cụ nhẹ nhàng mà cung cấp được một sự thỏa hiệp nhạy cảm giữa việc giữ được mọi người được thông báo đầy đủ và cho phép họ có được với 'gãi từng tí một của riêng họ'. Chúng ta sẽ xem xét những qui trình và công cụ đó trong các phần tiếp sau.

Cơ sở

Nhiều người mới tới với nguồn mở có sai lầm khi nghĩ họ cần cung cấp tập hợp các công cụ rộng rãi nhất có thể để cho phép các bên có quan tâm tham gia theo một cách thức phù hợp với họ. Tuy nhiên, điều này thường là một sai lầm. Một công cụ chỉ nên được giới thiệu khi có một nhu cầu rõ rằng cho nó. Việc giới thiệu một công cụ quá sớm cùng gây lúng túng cho những người sử dụng ('công cụ nào tôi sử dụng để làm công việc X?') và tiềm tàng chia tách hoạt động xuyên qua nhiều công cụ, vì thế việc tạo ra một ấn tượng về hoạt động bị suy giảm.

Đối với một dự án nguồn mở, có 4 công cụ cơ bản và một đống toàn bộ những công cụ không cơ bản. Các công cụ cốt lõi mà tất cả các dự án nên bắt đầu với (và tự giới hạn chúng) gồm:

• website: cho việc giao tiếp ý định và tình trạng của dự án tại bất kỳ thời điểm nào
• danh sách thư của những người lập trình: cho sự thay đổi các ý tưởng, thiết kế và thông tin đang diễn ra
• kiểm soát phiên bản: để quản lý mã nguồn và giao tiếp những thay đổi của mã nguồn khi rà soát lại
• Trình theo dõi các vấn đề: để lên kế hoạch và giao tiếp với các hoạt động được lên lịch và hiện hành

Quy trình cốt lõi cho sự phát triển, có sử dụng các công cụ, điển hình sẽ giống thứ gì đó thế này:

• ghi lại một vấn đề (lỗi, tính năng mới, cải tiến, …) sẽ được giải quyết trong trình theo dõi các vấn đề
• giao vấn đề cho một lập trình viên
• [Tùy có thể chọn hay không] nếu công việc là phức tạp hoặc sẽ giới thiệu những thay đổi đáng kể, hãy đưa những ý định vào danh sách thư của các lập trình viên (thường thì điều này là một thư được tự động sinh ra khi trình theo dõi vấn đề được cập nhật).
• tiếp tục với công việc (tham gia với cộng đồng phát triển rộng lớn hơn thông qua danh sách thư khi cần thiết)

• [Nếu người đề xuất] đề xuất sớm và thường tới kiểm soát phiên bản; điều này sẽ gửi một thông điệp tự động tới danh sách thư của các lập trình viên và cho phép mã nguồn sẽ được rà soát lại và nếu cần những thay đổi cần thiết được yêu cầu
• [Nếu không phải người đề xuất] đề xuất các bản vá (bản dịch tiếng Việt) thường xuyên cho trình theo dõi vấn đề; điều này sẽ gửi một thông điệp tự động tới danh sách thư của các lập trình viên, cho phép bản vá đó sẽ được rà soát lại và, nếu cần, những thay đổi được yêu cầu
• lặp lại cho tới khi hoặc công việc được hoàn tất và tất cả những yêu cầu rà soát lại được thỏa mãn.
• đánh dấu vấn đề là hoàn tất (nó sẽ gửi đi một thông báo tới danh sách thư)
• cập nhật website khi thấy phù hợp

Một điều quan trọng để lưu ý về qui trình này là nó mất rất ít nỗ lực về phía của lập trình viên để giữ cho cộng đồng được thông tin đầy đủ. Lập trình viên không làm bất kỳ thứ gì mà họ có thể thường không phải làm trong một dự án phần mềm được quản lý tốt. Hầu hết các cập nhật của cộng đồng được các công cụ tạo ra một cách tự động, chứ không từ con người. Vì thế việc đạt được giao tiếp mở không đòi hỏi bất kỳ nỗ lực bổ sung nào ngoài việc thiết lập các công cụ đó đúng ngay từ đầu.

Bây giờ chúng ta hiểu về các công cụ cơ bản và vai trò của chúng trong qui trình phát triển cốt lõi, chúng ta sẽ xem xét từng công cụ một cách chi tiết. Chúng ta cũng sẽ xem xét một số ưu và nhược điểm của các công cụ khác mà dự án của bạn có thể áp dụng khi nó chín muồi.

Các công cụ giao tiếp

Giao tiếp là chìa khóa để thành công của một dự án nguồn mở. Nó có ở 2 dạng: phổ biến và thảo luận. Ở dạng đầu, mục tiêu là để nói cho mọi người mọi thứ; ở dạng sau, là để nhờ mọi người chia sẻ các ý tưởng và kinh nghiệm. Trong phần này, chúng ta sẽ xem xét cả 2 dạng giao tiếp.

Khi thiết kế một chiến lược giao tiếp, chúng ta cần nhớ rằng những người sử dụng và những người đóng góp có thể không ở cùng một nơi cùng một lúc rất thường xuyên, hoặc thậm chí hoàn toàn. Chính vì thế điều sống còn phải có một hạ tầng giao tiếp cho phép mọi người làm việc trong dự án khi họ muốn và theo cách mà họ muốn. Hạ tầng này là hòn đá tảng của toàn bộ dự án. Điều này mà sai thì những người tham gia trong dự án của bạn sẽ không có khả năng cộng tác.

Một danh sách thư chỉ là cơ chế được yêu cầu cho giao tiếp 2 chiều trong một dự án nguồn mở, nhưng có nhiều cơ chế khác mà các dự án có thể sử dụng. Trong phần này, chúng tôi sẽ xem xét vì sao một danh sách thư là cơ bản và vì sao mọi điều khác là một sự trệch hướng tiềm tàng khỏi hoạt động cốt lõi của dự án.

Danh sách thư

Các danh sách thư được sử dụng cho việc xây dựng sự đồng thuận và thảo luận, chia sẻ thông tin và nhận thức chung. Chúng làm tài liệu cho con đường phát triển của dự án và đưa ra một bản ghi các chỉ lệnh được viết ra và hỗ trợ cho những người mới tới dự án. Các danh sách thư có thể là công cụ quan trọng nhất trong toàn bộ kho vũ khí phát triển của cộng đồng.

Các danh sách thư trở nên được nhúng vào trong các thực tiễn làm việc của hầu hết các lập trình viên phần mềm nguồn mở. Trình thư điện tử máy trạm là ứng dụng đầu tiên mà họ mở và là ứng dụng mà họ quay lại suốt ngày. Các tính năng mạnh cho phép thư sẽ được lọc và được quản lý có hiệu quả, và nó có thể được truy cập từ bất kỳ thiết bị nào, cả trực tuyến và phi trực tuyến. Ngắn gọn, thư điện tử là trung tâm của thế giới các lập trình viên nguồn mở.

Một số người viện lý rằng cơ chế 'kéo' của các diễn đàn dựa vào web - đó là, việc yêu cầu người sử dụng viếng thăm một diễn đàn trực tuyến để đọc những bài viết mới nhất - tạo nên những diễn đàn dựa vào web là siêu hạng hơn thư điện tử. Họ nói rằng không phải ai cũng có thể điều khiển được một lượng lớn các thư điện tử, và hầu hết mọi người không muốn các thư điện tử không quan trọng tới trong hộp thư đến của họ. Tất nhiên, lý lẽ này là hợp lệ tuyệt vời. Tuy nhiên, chìa khóa là trong từ 'hầu hết'. Khi thiết lập một dự án mới, chúng ta nên xem xét ai chúng ta đang cố gắng lôi cuốn vào. Một dự án mới cần những người đóng góp mới - nó không cần, và có lẽ không thể phục vụ, những người sử dụng mới. Vì chúng ta muốn các lập trình viên, có khả năng chúng ta sẽ xem xét nhữn người có kỹ thuật - những người mà họ có thể đã có trình thư điện tử máy trạm rồi ở trung tâm công việc hàng ngày của họ. Đối với những người đó, thư điện tử là công cụ có hiệu quả và hiệu lực nhất.

Điều này không phải để nói các diễn đàn trực tuyến không phải là không có chỗ trong một dự án nguồn mở. Trong phần tiếp sau, chúng ta sẽ thảo luận nơi mà chúng có thể rất hữu dụng. Tuy nhiên, điểm còn giữ lại là trong hầu hết mọi trường hợp, một danh sách thư là phù hợp hơn cho một cộng đồng các lập trình viên. Hơn nữa, như chúng ta sẽ thấy trong các phần sau, một danh sách thư là có khả năng tốt hơn để tích hợp với các công cụ cơ bản khác mà một dự án cần.

Chúng ta đã tranh luận rằng một danh sách thư là phù hợp hơn so với một diễn đàn; tuy nhiên, nhiều công cụ các danh sách thư mới hơn cung cấp cả các giao diện máy trạm thư điện tử và dựa vào web, nên những người sử dụng có thể làm việc với bất kể cơ chế nào phù hợp nhất cho các nhu cầu của họ. Nếu bạn nghi ngờ về tính ứng dụng của một danh sách thư so với một diễn đàn cho cộng đồng của bạn, thì chúng tôi khuyến cáo mạnh mẽ một trong những công cụ lai (hỗn hợp) đó.

Các kho lưu trữ thư

Miễn là các danh sách thư được sử dụng phù hợp, các lưu trữ thư của một dự án được phát triển mở là một trong những tài nguyên có giá trị nhất của nó. Chúng chứa một hồ sơ các thảo luận và các quyết định về thiết kế, thông tin làm thế nào, các trường hợp điển hình, các phân tích yêu cầu và hơn thế nữa.

Tất cả các dự án nên đưa ra các lưu trữ có khả năng tìm kiếm được của các danh sách thư và, ở những nơi có thể, tham chiếu ngược tới chúng hơn là nỗ lực đúp bản bằng cách trả lời một câu hỏi lần thứ 2 hoặc thăm lại không cần thiết một quyết định trước đó. Như với những món ăn tổng hợp, sự cung cáp các lưu trữ nên không bổ sung vào tải công việc của đội dự án. Hầu hết các nhà cung cấp danh sách thư cũng sẽ có một giải pháp lưu trữ. Nếu điều này là không phải thế, sẽ có một số cơ sở trực tuyến mà có thể được sử dụng miễn phí để lưu trữ các danh sách thư công cộng.

Các diễn đàn

Các diễn đàn có ưu thế dễ dàng sử dụng. Bạn không cần phải là người sử dụng thư điện tử có năng lực để có được hầu hết từ một diễn đàn. Tuy nhiên, các diễn đàn sẽ không có các tính năng cao cấp, như truy cập phi trực tuyến, lọc và tính tương hợp, mà thư điện tử lại cung cấp được.

Trong khi các danh sách thư là thiết bị giao tiếp tốt nhất cho những người có kỹ thuật, thì thường được tranh luận rằng những người sử dụng sẽ ít biết kỹ thuật hơn và vì thế cần một cơ chế giao tiếp khác. Điều này không phải lúc nào cũng đúng; nó sẽ phụ thuộc vào bản chất tự nhiên của dự án. Tuy nhiên, nếu những người sử dụng của bạn là ít biết kỹ thuật hơn, thì một diễn đàn để hỗ trợ người sử dụng có thể là phù hợp hơn.

Thậm chí dù một diễn đàn có thể là phù hợp hơn cho những người sử dụng, thì bạn cần nghĩ cẩn thận trước khi tạo nó (hoặc một danh sách thư riêng cho những người sử dụng). Liệu dự án của bạn có đủ chín để lôi cuốn những người sử dụng trong một số lượng đáng kể hay không? Liệu bạn có đủ các lập trình viên để giám sát và trả lời các câu hỏi của người sử dụng trên diễn đàn hay không?

Việc tạo một diễn đàn, hoặc một danh sách thư thứ 2 cho những người sử dụng, quá sớm sẽ gây ra cho việc ép những người sử dụng vào một 'phòng tối', tách bạch, nơi mà họ sẽ không chắc liệu có ai đó 'lắng nghe' hay không. Một kênh giao tiếp thứ 2 chỉ nên được tạo ra khi giao thông trên kênh thứ nhất của bạn là đủ cao để chứng minh cho sự chia tách.

Các blog

Các blog là tuyệt vời cho việc phổ biến các ý tưởng hoặc tin tức, nhưng không là lý tưởng cho thảo luận tích cực. Chúng thường có một cơ sở bình luận, nhưng không thường cung cấp các cơ sở hoàn chỉnh cho việc hỗ trợ các hội thoại. Giống như các diễn đàn, chúng đòi hỏi người sử dụng tới thăm site để tham gia vào. Hệ quả là, không phải bất kỳ ai cũng sẽ thấy được các bình luận đi theo. Các blog vì thế không nên được xem là phương tiện cho phản hồi trực tiếp. Chúng ta sẽ tới thăm lại các blog ở bên dưới, khi chúng ta xem xét các website của dự án.

Tổng hợp (Syndication)

Tổng hợp là một biện pháp chia sẻ thông tin ở dạng máy đọc được sao cho các bên thứ 3 có thể thuận tiện đưa vào các nội dung phù hợp từ dự án của bạn. Các định dạng của sự tổng hợp được sử dụng rộng rãi như các nguồn cấp dữ liệu RSS và ATOM là một cách thức thuận tiện cho mọi người để kéo thông tin từ dựa án của bạn và tổng hợp nó theo một cách thức có nghĩa cho cách mà họ làm việc, hoặc cho cộng đồng của họ. Đó là, một nguồn cấp dữ liệu tổng hợp có thể xuất hiện trong nhiều chỗ, như một trình thư điện tử máy trạm của một người sử dụng, một trình đọc các nguồn cấp dữ liệu, một bộ tổng hợp dựa trên web hoặc một website. Việc cung cấp sự truy cập được tổng hợp tới càng nhiều kênh giao tiếp có thể càng tốt sẽ làm gia tăng các cơ hội của bạn với tới được những người sử dụng mới.

Tuy nhiên, nội dung được tổng hợp, bản thân nó, không phải là một công cụ cho giao tiếp. Nó chỉ là một công cụ để cung cấp sự truy cập tới nội dung đã tồn tại trước đó rồi. Bằng việc chọn các công cụ phù hợp một cách thận trọng, bạn sẽ có khả năng đảm bảo rằng các nguồn cấp dữ liệu được tổng hợp được cung cấp một cách tự động. Đó là, bạn nên thử chọn một công cụ cho website, các giao tiếp, theo dõi vấn đề và kiểm soát phiên bản của bạn mà cũng cấp tự động nguồn cấp dữ liệu tổng hợp các dữ liệu phù hợp.

Các mạng xã hội và các blog vi mô (micro-blogging)

Kết nối mạng xã hội thường được xem như một phần sống còn của việc xây dựng cộng đồng. Tuy nhiên, giá trị của các công cụ đó trong các dự án nguồn mở là không rõ ràng. Vấn đề chính là hầu hết các mạng xã hội hành xử như một khu vườn có tường rào, nên việc chọn một mạng này hơn một mạng khác ép những người đóng góp tiềm năng của bạn phải sử dụng site cụ thể đó, mà nó có thể không phải là site ưu tiên của họ.

Có thể có sự cám dỗ để tổng hợp nội dung của bạn trong các site nối mạng xã hội. Điều này có thể là phù hợp đối với một số dự án, nhưng hãy cẩn trọng về việc chia tách cộng đồng của bạn giữa các kênh chính thức và các kênh kết nối mạng xã hội.

Website

Một website là một cơ chế cho việc xuất bản các dạng thông tin khác nhau. được sử dụng để cung cấp thông tin đầu vào trong một dự án và một cổng vào cho tất cả các phần khác của dự án. Một website cho một dự án nguồn mở sẽ chỉ giống như bất kỳ website nào khác. Hãy xem xét các công cụ có sẵn cho việc tạo ra một website.

Bất kỳ công cụ quản trị website nào cũng cần cân nhắc tới tính mềm dẻo, qui trình và sự dễ dàng truy cập. Trong hầu hết các trường hợp, một sự thỏa hiệp sẽ ần thiết thực hiện theo một hoặc nhiều hơn các yếu tố đó. Ví dụ, dễ dàng truy cập có thể đòi hỏi cân nhắc chọn theo tính mềm dẻo (một hệ thống càng mềm dẻo thì càng phức tạp).

Bảng bên dưới đưa ra một vài giải pháp chung cho quản lý website và chỉ ra những điểm mạnh và yếu của chúng. Tính điểm là từ 0 (thấp) cho tới 4 (cao).

Các giải pháp quản lý website: các điểm mạnh và yếu

Giải pháp	Tính mềm dẻo	Qui trình và cấu trúc	Người sử dụng truy cập	Lưu ý
HTML website	3	2	0	Việc soạn thảo các tệp html thô cho phép chúng ta làm mọi thứ, nhưng qui trình và cấu trúc phải bị cưỡng bức bằng tay và người sử dụng không có cách dễ dàng nào để đóng góp cho những thay đổi.
XML website	4	3	0	Việc soạn thảo XML là rất giống với soạn thảo HTML thô; tuy nhiên, XML cho phép kiểm soát được tự động hơn so với cả 2 dạng nội dung và cấu trúc site (nghĩa là các trang đánh chỉ số có thể được tạo ra tự đông.
Wiki	2	0	4	Wikis là tuyệt vời cho việc cho phép những người sử dụng dễ dàng truy cập tới nội dung, nhưng không có sự quản lý cẩn trọng thì chúng nhanh chóng trở nên hỗn độn. Nó cũng có thể là khó để tái mục đích các nội dung cho những sử dụng khác.
Blog	1	3	2	Blogs có thể được sử dụng để cung cấp các khối cơ bản của một site, cũng như sự tương tác có hạn chế của người sử dụng thông qua các bình luận.
Hệ thống quản trị nội dung (CMS)	2	4	3	Các hệ thống quản trị nội dung cho phép kiểm soát chặt chẽ đối với qui trình và cấu trúc nội dung và có thẻ cũng khá dễ dàng cho người sử dụng để truy cập; tuy nhiên, chúng có xu hướng sẽ bị hạn chế hơn (so với các tệp thô) về việc sử dụng lại nội dung và có thẻ là khó hơn để cài đặt và thiết lập cấu hình.

Screencasts

Screencasts là các video trình bày phần mềm đang sử dụng. Người sử dụng có thể xem chúng mà không cần cài đặt phần mềm đang được xem. Chúng có thể rất hữu dụng trong việc lôi cuốn những người sử dụng mới và cung cấp một phần tài liệu cho hệ thống. Tuy nhiên, chúng có thể nhanh chóng trở nên nhạt nhẽo, khi một giao diện của một sản phẩm chín muồi và các tính năng mới được bổ sung. Trên hết được yêu cầu phải duy trì chúng cũng có thể làm cho chúng không thực tế cho sử dụng tăng cường.

Đối với các ứng dụng được truy cập thông qua một trình duyệt web, một kỹ thuật có thể làm việc tốt là sử dụng sự kiểm thử bằng trình duyệt một cách tự động để đảm bảo không có lỗi đối với kinh nghiệm của người sử dụng. Những kiểm thử tự động đó có thể được chạy ở tốc độ thấp hơn và được ghi lại như một screencast để chuẩn bị cho từng phát hành. Vì từng phát hành cần phải được kiểm thử đầy đủ và các kiểm thử cần phải được cập nhật với sự lưu ý về giao diện và các cập nhật tính năng, điều này đưa ra được một biện pháp ghi screencast bán tự động.

Hệ thống kiểm soát phiên bản

Là rất quan trọng để cung cấp một hệ thống kiểm soát phiên bản (VCS; còn được biết như là hệ thống kiểm soát rà soát lại hoặc RCS) cho việc quản lý các tài nguyên dự án của bạn. Điều này cho phép bạn theo dõi ai đã làm những thay đổi gì và khi nào, vì sao chúng đã được làm và, nếu cần, quay ngược những thay đổi mà gây ra các vấn đề. Việc sử dụng một VCS là dễ dàng; việc sử dụng nó đúng là vất vả. Nếu bạn chưa bao giờ sử dụng một VCS trước đó, thì chúng tôi khuyến cáo mạnh mẽ rằng bạn tìm một người hướng dẫn và đọc tài liệu về kiểm soát phiên bản (bản dịch tiếng Việt) của chúng tôi.

Khi được sử dụng đúng, một VCS đảm bảo rằng các lập trình viên giữ được thông tin tốt, quản lý phát hành là dễ dàng, công việc với lỗi được ghi lại, thí nghiệm được tạo thuận lợi, những đóng góp được quản lý và việc ghi sự truy cập tới các tài nguyên được kiểm soát. VCS của bạn là một công cụ điều phối và quản lý, cũng như máy thời gian dự án của bạn. Nó sẽ đảm bảo rằng mọi người được thông tin đầy đủ về tất cả những thay đổi đối với các tài nguyên và cho phép bất kỳ ai tìm để sử dụng tất cả các tài nguyên từ bất kỳ thời điểm nào được đưa ra trong vòng đời của dự án.

Việc sử dụng một VCS có hiệu quả đòi hỏi rằng tất cả những người đóng góp tuân theo châm ngôn 'đề xuất sớm và thường xuyên'. Đối với các lập trình viên tuân theo sự phát triển hướng kiểm thử, thì điều này là dễ dàng để làm: đơn giản đề xuất khi từng kiểm thử mới được làm xong. Điều này gửi đi một thông báo rằng một bước triển khai đã hoàn tất và trình theo dõi vấn đề tự động ghi lại đề xuất đối với vấn đề đó. Các lập trình viên khác bây giờ có thể rà soát lại những thay đổi và cũng tránh được nỗ lực đúp bản.

Theo dõi vấn đề/quản lý dự án

Một trình theo dõi vấn đề cho phép những người sử dụng của bạn báo cáo các lỗi và yêu cầu các tính năng mới. Nó cũng cho phép đội quản lý dự án của bạn lên kế hoạch làm việc và đặt ưu tiên cho các yêu cầu từ cộng đồng.

Bằng việc sử dụng một trình theo dõi vấn đề, bạn có thể đưa ra một chỉ định rõ ràng cho những người sử dụng của bạn như điều gì sẽ mong đợi trong các phát hành trong tương lai đối với mã nguồn của bạn. Điều này có nghĩa là nếu một người sủ dụng có một nhu cầu đặc thù đối với một tính năng hoặc sửa lỗi mà bạn không định triển khai trong thời gian ngắn tới, thì họ có thể lựa chọn để đầu tư một số tài nguyên của riêng họ trong việc bổ sung thêm tính năng đó hoặc sửa lỗi đó. Việc giao tiếp với các kế hoạch của bạn rõ ràng và có hiệu quả đối với những người sử dụng là bước đầu tiên hướng tới việc nhờ họ đóng góp cho sự phát triển dự án của bạn.

Có là một trong những sử dụng tốt nhất một trình theo dõi vấn đề là để cung cấp một hồ sơ các lĩnh vực phù hợp cho những người mới tới dự án để xử trí để có được một cảm giá đối với dự án. Các vấn đề sẽ là đơn giản, hoặc có một người hướng dẫn sẵn sàng có thể được đánh dấu như vậy và các thành viên cộng đồng có thể lôi kéo sự chú ý tới họ khi những người mới tới đang tìm kiếm ở đâu đó để làm quen.

Quản lý các quyền sở hữu trí tuệ (IPR)

Là sống còn rằng bạn biết ai sở hữu các bản quyền trong dự án của bạn. Để làm điều này, bạn cần có khả năng để lần vết từng sự đóng góp ngược trở về tới tác giả gốc ban đầu. Trong trường hợp những đóng góp mà trực tiếp tác động tới đầu ra dự án của bạn, như mã nguồn hoặc tài liệu của chương trình, thì điều này hầu hết được quản lý có hiệu quả thông qua một hệ thống kiểm soát phiên bản (xem ở trên) đi cùng với một Thỏa thuận Giấy phép của Người đóng góp (bản dịch tiếng Việt) được xác định rõ ràng và một qui trình đề xuất có sử dụng một trình theo dõi vấn đề.

Ở những nơi mà những đóng góp là không trực tiếp ở dạng mã nguồn hoặc tài liệu, ví dụ như các ý tưởng thiết kế, thì điều quan trọng là chúng sẽ được nắm bắt ở dạng có thể truy cập được và có thể theo dõi được một cách công khai. Nếu bạn thực hiện những thảo luận về thiết kế của bạn trong một danh sách thư, thì những lưu trữ của danh sách thư đó là tuyệt vời cho điều này.

Ở những nơi mà sự đóng góp có dạng của mã nguồn phần mềm, thì hệ thống kiểm soát phiên bản và trình theo dõi vấn đề đưa ra một phương tiện ghi lại qui trình đóng góp đó. Một khi bản vá đó là sẵn sàng để được áp dụng cho kho mã nguồn, thì hệ thống kiểm soát phiên bản được sử dụng và 'đệ trình' được ghi lại tự động đối với trình theo dõi vấn đề.

Quản lý IPR trong một dự án nguồn mở, theo nhiều cách, là quan trọng nhất và là nhiệm vụ khó nhọc nhất. Nó không trực tiếp bổ sung thêm vào chức năng của phần mềm và dường như thoạt nhìn sẽ là công việc tốn thời gian và hướng qui trình. Tuy nhiên, nếu bạn đã thiết lập được các tài nguyên của dự án một cách cẩn trọng, thì qui trình đó sẽ hầu hết được tự động và minh bạch cho đa số các lập trình viên. Việc có qui trình như vậy tồn tại sẽ truyền dẫn lòng tin trong những người sử dụng tiềm năng phần mềm của bạn, và nhiều người sử dụng hơn nghĩa là nhiều người đóng góp hơn.

Kết luận

Có các công cụ đúng cho dự án của bạn sẽ làm cho dễ dàng hơn để quản lý bản thân dự án, bất kể liệu bạn có lôi cuối được một cộng đồng hay không. Tuy nhiên, việc có các công cụ chỉ là sự khởi đầu, bạn cũng cần sử dụng chúng theo một cách nhất quán và dự đoán trước được. Nếu bạn sử dụng các công cụ đúng từ đầu thì bạn sẽ tránh được nhiều đau đớn và tạo ra được những điều kiện có thể là tốt nhất cho việc xây dựng một cộng đồng (bản dịch tiếng Việt) xung quanh dự án của bạn khi thời gian là đúng.

There is no single correct way to build and manage an open community-led project, but there are common tools and practices that we can use to support our work. The key is to use tools that are appropriate to your community and to keep them to a bare minimum. In this document, we examine the tools that are common to most open source projects and suggest ways in which you might use them to build community.

Tools should facilitate, not dictate

Many people think that being open in a project is about spending an inordinate amount of time informing people of current activities. But this need not be the case. If you are careful about selecting your tools and the development process that uses them, the appropriate level of external communication will simply be a by-product of the development process.

To understand how this can be true, we first need to understand that the goal of being open is not to ensure that everyone understands what it going on at any given point in development. Instead, it is about enabling those with sufficient interest to find the information they need. By focusing only on those interested enough to do their homework, we reduce the need for existing members of the community to hand-hold newcomers. This allows them to focus more completely on getting the results they seek. This may appear to be counter to the goal of building community, so let’s pick it apart a little.

In a community-led project, people participate in order to satisfy their own needs - you might call it ‘scratching an itch’. So an individual’s main driver will not be to build a community, but to solve a specific problem they face in their job, studies or hobby. For this reason, projects should be run in such a way that process and community overhead do not get in the way of people pursuing their interests.

That being said, a well-run open source project will have a set of lightweight processes and tools that provide a sensible compromise between keeping people informed and allowing them to get on with ‘scratching their own itch’. We will look at these processes and tools in the next sections.

The basics

Many people new to open source make the mistake of thinking they need to provide the widest possible set of tools to allow interested parties to engage in a way that suits them. However, this is usually a mistake. A tool should be introduced only when there is a clear need for it. Introducing a tool too early will confuse users (‘Which tool do I use to do X?’) and potentially split activity across multiple tools, thus creating an impression of reduced activity.

For an open source project, there are four essential tools and a whole raft of non-essential ones. The core tools that all projects should start with (and limit themselves to) are:

• website: for communicating the intention and status of the project at any given point in time
• developer mailing list: for the ongoing exchange of ideas, design and information
• version control: for code management and communicating code changes for review
• issue tracker: for planning and communicating work schedule and current activities

The core process for development, using these tools, will typically look something like this:

• record an issue (bug, new feature, enhancement, etc.) to be addressed in the issue tracker
• assign the issue to a developer
• [OPTIONAL] if the work is complex or will introduce significant changes, post intentions to the developer mailing list (often this is an automated mail generated when the issue tracker is updated)
• get on with the work (engaging with the broader development community through mailing list as necessary)
• [IF COMMITTER] commit early and often to version control; this will send an automated message to the developer mailing list and allow the code to be reviewed and if necessary changes requested
• [IF NOT COMMITTER] submit patches to the issue tracker frequently; this will send an automated message to the developer mailing list, allowing the patch to be reviewed and, if necessary, changes requested
• repeat until either the job is complete and all review requirements have been satisfied
• mark the issue as complete (which sends a notification to the list)
• update the website when appropriate

An important thing to note about this process is that it takes very little effort on the part of the developer to keep the community informed. The developer is not doing anything that they would not normally be doing in a well-run software project. Most community updates are created automatically by the tools, not by a human. So achieving open communication does not require any additional effort beyond setting up the tools correctly in the first place.

Now that we understand the basic tools and their role in the core development process, we’ll look at each of the tools in more detail. We’ll also consider some of the advantages and disadvantages of other tools your project may adopt as it matures.

Tools for communication

Communication is the key to the success of an open source project. It takes two forms: dissemination and discussion. In the former, the goal is to tell people something; in the latter, it is to have people share ideas and experiences. In this section, we will consider both forms of communication.

When designing a communication strategy, we need to remember that users and contributors may not be in the same place at the same time very often, or even at all. It is therefore vital to have a communication infrastructure that allows people to work on the project when they want and how they want. This infrastructure is the keystone of the whole project. Get this wrong and the participants in your project will not be able to collaborate.

A mailing list is the only required mechanism for two way communication in an open source project, but there are many other mechanisms that projects are tempted to use. In this section, we’ll look at why a mailing list is essential and why everything else is a potential diversion from the core activity of the project.

Mailing lists

Mailing lists are used for discussion and consensus-building, information-sharing and public recognition. They document the project’s development path and provide a written record of instructions and support for those new to the project. Mailing lists are probably the most important tool in the entire community-development armoury.

Mailing lists become embedded in the working practices of most open source software developers. The email client is the first application they open and is the one they return to throughout the day. Powerful features allow mail to be efficiently filtered and managed, and it can be accessed from any device, both online and offline. In short, email is the centre of an open source developer’s world.

Some people argue that the ‘pull’ mechanism of web-based forums - that is, requiring the user to visit an online forum in order to read the latest posts - makes web-based forums superior to email. They claim that not everyone can handle a large volume of email, and most people don’t want unimportant emails arriving in their inbox. Of course, this argument is perfectly valid. However, the key is in the word ‘most’. When setting up a new project, we should consider who we are trying to appeal to. A new project needs new contributors - it does not need, and probably cannot service, new users. Since we want developers, we are likely to be looking at technical people - people who are probably already have their email client at the centre of their working day. For these people, email is the more efficient and effective tool.

This is not to say that online forums have no place in an open source project. In the next section, we will discuss where they can be very useful. However, the point remains that in most cases, a mailing list is more appropriate for a developer community. Furthermore, as we will see in later sections, a mailing list is better able to integrate with the other essential tools a project needs.

We have argued that a mailing list is more appropriate than a forum; however, many of the newer mailing list tools provide both web-based and email client interfaces, so that users can work with whichever mechanism is most appropriate to their needs. If you are in doubt about the utility of a mailing list over a forum for your community, we strongly recommend one of these hybrid tools.

Mail archives

Provided that mailing lists are used appropriately, the mail archives of an openly developed project are one of its most valuable resources. They contain a record of design discussions and decisions, how-to information, use cases, requirements analysis and much more.

All projects should provide searchable archives of their mailing lists and, wherever possible, refer back to them rather than duplicating effort by answering a question for the second time or unnecessarily revisiting a previous decision. As with syndication feeds, the provision of archives should not add to the workload of the project team. Most mailing list providers will also have an archive solution. If this is not the case, there are a number of online facilities that can be used free of charge to archive public mailing lists.

Forums

Forums have the advantage of being easy to use. You do not need to be a power user of email to get the most from a forum. However, forums do not have the advanced features, such as offline access, filtering and interoperability, that email provides.

While mailing lists are the best communication device for technical people, it is often argued that users will be less technical and therefore need a different communication mechanism. This is not always true; it will depend on the nature of the project. However, if your users are less technical, a forum for user support may be more appropriate.

Even though a forum may be more appropriate for users, you need to think carefully before creating one (or a separate mailing list for users). Is your project mature enough to attract users in significant numbers? Do you have enough developers to monitor and respond to user queries on the forum?

Creating a forum, or a second mailing list for users, too early will result in forcing users into a separate, ‘darkened room’, where they will be unsure if there is anyone ‘listening’. A second communication channel should only be created when the traffic on your first channel is sufficiently high to justify the split.

Blogs

Blogs are perfect for disseminating ideas or news, but are not ideal for active discussion. They typically have a comment facility, but do not usually provide complete facilities for supporting conversation. Like forums, they require the user to visit the site in order to participate. Consequently, not everyone will see follow-up comments. Blogs should not, therefore, be considered as a tool for facilitating discussion. Instead, they are a mechanism for dissemination that provide a means of direct feedback. We will revisit blogs below, when we consider project websites.

Syndication

Syndication is a means of sharing information in a machine-readable form so that third parties can conveniently include relevant content from your project. Widely used syndication formats such RSS and ATOM feeds are a convenient way for people to pull content from your project and aggregate it in a way that is meaningful to the way they work, or to their community. That is, a syndication feed can appear in many places, such as a user’s mail client, a feed reader, a web-based aggregator or a website. Providing syndicated access to as many of your communications channels as possible increases your chances of reaching new users.

However, syndicated content is not, in itself, a tool for communication. It is merely a tool for providing access to pre-existing content. By selecting the appropriate core tools carefully, you should be able to ensure that syndicated feeds are provided automatically. That is, you should try to choose a tool for your website, communications, issue tracking and version control that automatically provides syndication feeds of appropriate data.

Social networks and micro-blogging

Social networking is often seen as a critical part of community-building. However, the value of these tools in open source projects is not clear. The main problem is that most social networks act as a walled garden, so choosing one network over another forces your potential contributors to use that specific site, which may not be their preferred site.

It may be tempting to syndicate your content into social networking sites. This might be appropriate for some projects, but be careful about splitting your community between official channels and social networking channels.

Website

A website is a mechanism for publishing various forms of information. It is used to provide entry-level information on a project and a gateway to all other parts of the project. A website for an open source project will be just like any other website. Let’s look at the tools available for creating one.

Any website-management tool needs to balance flexibility, process and ease of access. In most cases, a compromise will need to be made on one or more of these factors. For example, ease of access may require a trade-off in flexibility (the more flexible a system is, the more complex it is). The following table presents some generic solutions for website management and indicates their strengths and weaknesses. The scoring is from 0 (low) to 4 (high).

Website management solutions: strengths and weaknesses

Solution	Flexibility	Process and structure	User access	Notes
HTML website	3	2	0	Editing raw html files allows us to do anything, but process and structure must be manually enforced and users have no easy way of contributing to changes.
XML website	4	3	0	Editing XML is very similar to editing raw HTML; however, XML allows more automated control over both the content types and the site structure (i.e. index pages can be auto-generated).
Wiki	2	0	4	Wikis are great for allowing users easy access to content, but without careful management they quickly become disorganised. It can also be difficult to re-purpose the content for other uses.
Blog	1	3	2	Blogs can be used to provide the basic building blocks of a site, as well as limited user interaction through comments.
CMS	2	4	3	Content management systems allow tight control over the process and structure of content and can also be fairly easy for users to access; however, they tend to be more limited (than raw files) with respect to reusing the content and can be more difficult to install and configure.

Screencasts

Screencasts are videos that demonstrate software in use. Users can view them without needing to install the software being viewed. They can be very useful in attracting new users and providing part of the documentation for the system. However, they can quickly become stale, as a product’s interface matures and new features are added. The overhead required to maintain them may also make them impractical for extensive use.

For applications that are accessed through a web browser, one technique that can work well is to use automated browser-testing to ensure a bug-free user experience. These automated tests can be run at a slower speed and recorded as a screencast in preparation for each release. Since each release needs to be fully tested and the tests need to be kept up to date with respect to interface and feature updates, this provides a means of semi-automating screencast recording.

Version control system

It is very important to provide a version control system (VCS; also known as revision control system or RCS) for the management of your project resources. This allows you to track who made what changes when, why they were made and, if necessary, to roll back changes that cause problems. Using a VCS is easy; using one correctly is harder. If you’ve never used a VCS before, we strongly recommend that you find a mentor and read our document on version control.

When used correctly, a VCS ensures that developers remain informed, release management is easier, bug-work is recorded, experimentation is facilitated, contributions are managed and write access to resources is controlled. Your VCS is a coordination and management tool, as well as your project’s time machine. It will ensure that everyone is fully informed about all changes to resources and allow anyone to retrieve all resources from any given moment in the life of the project.

Using a VCS effectively requires that all contributors follow the ‘commit early and often’ maxim. For developers following test-drive development, this is easy to do: simply commit when each new test is passed. This sends out a notification that an implementation step has been completed and the issue tracker automatically records the commit against the issue. Other developers can now review the changes and also avoid duplicating effort.

Issue tracking/project management

An issue tracker allows your users to report bugs and request new features. It also allows your project management team to plan work and prioritise community-driven requests.

By using an issue tracker, you can provide a clear indication to your users as what to expect in future releases of your code. This means that if a user has a specific need for a feature or bug-fix that you have no intention of implementing in the short term, they can opt to invest some of their own resources in adding the feature or fixing the bug. Communicating your plans clearly and efficiently to users is the first step towards having them contribute to the development of your project.

Perhaps one of the best uses of an issue tracker is to provide a record of areas that are suitable for newcomers to the project to tackle in order to get a feel for the project. Issues that are simple, or have a mentor available can be flagged as such and community members can draw attention to them when newcomers are looking for somewhere to get started.

Management of intellectual property rights (IPR)

It is vital that you know who owns the copyrights in your project. To do this, you need to be able to trace every contribution back to its original author. In the case of contributions that directly affect your project outputs, such as programme code or documentation, this is most efficiently managed through a version control system (see above) coupled with a clearly defined Contributor Licence Agreement and a submission process using an issue tracker.

Where contributions are not directly in the form of source code or documentation, for example design ideas, it is important that they are captured in a publicly accessible and traceable form. If you conduct your design discussions on a mailing list, the archives of that mailing list are perfect for this.

Where the contribution takes the form of software code, the version control system and issue tracker provide a means for recording the contribution process. A patch is submitted to the issue tracker, where a developer will pick it up and review it. Once the patch is ready to be applied to the code base, the version control system is used and the ‘commit’ is recorded automatically against the issue tracker.

The management of IPR in an open source project is, in many ways, the most important and most onerous task. It does not directly add to the functionality of the software and appears at first glance to be time-consuming and process-driven. However, if you have set up the project resources carefully, the process will be mostly automated and transparent for the majority of developers. Having such a process in place will instill confidence in potential users of your software, and more users means more contributors.

Conclusion

Having the right tools for your project will make it easier to manage the project itself, regardless of whether you attract a community or not. However, just having the tools is only the start, you also need to use them in a consistent and predictable way. If you use the right tools from the outset you will avoid a great deal of pain and create the best possible conditions for building a community around your project when the time is right.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com