How
to get a class involved with an open source project
Posted 27 Jun 2013 by
Ruth Suehle
Bài được đưa lên
Internet ngày: 27/06/2013
Lời
người dịch: Một vài bài học nhỏ để dẫn dắt các
học sinh - sinh viên làm quen và tham gia vào các cộng đồng
phần mềm tự do nguồn mở (PMTDNM), cả những điều bạn
sẽ thấy bỡ ngỡ lúc đầu cho tới nhận thức về văn
hóa của cộng đồng PMTDNM mà bạn sẽ tham gia. Trong những
bài học nhỏ đó, bài học về trao ngược trở lại cho
cộng đồng theo một chu kỳ: đóng góp - rà soát lại
- kiểm thử không nhất thiết chỉ áp dụng cho mã nguồn,
mà cho cả nhiều điều khác nữa. Vì thế, bạn hãy tham
gia vào các cộng đồng PMTDNM, bất kể bạn là ai, không
nhất thiết bạn phải là lập trình viên phần mềm.
Chúng tôi nói về
“cộng đồng” nhiều khi đề tài là về nguồn mở,
nhưng điều quan trọng phải nhớ rằng chỉ như các cộng
đồng địa phương trong một thành phố, thị trấn, bang
và quốc gia, mỗi cộng đồng có văn hóa riêng của nó.
Cộng đồng này không giống cộng đồng kia. Mỗi cộng
đồng có các cách thức giao tiếp vầ theo dõi việc ra
quyết định của riêng nó. Các qui trình đệ trình mã
nguồn khác nhau - có lẽ 2 cộng đồng đều sử dụng
Bugzilla,
nhưng với các cờ khác nhau. Các cộng đồng khác đòi
hỏi bạn cũng phải cảnh báo một danh sách thư. Một dự
án phần mềm lớn thậm chí có thể có những cộng đồng
con nhỏ hơn bên trong nó với các cách thức và tùy chọn
của riêng chúng.
Việc học các khác
biệt là quan trọng cho sự thành công đối với sự tham
gia của bạn trong một dự án nguồn mở, và các học
sinh cần phải hiểu các sắc thái đó khi họ tham gia vào.
Đối với lớp POSSE năm nay, Heidi Ellis và Joanie Diggs đã
đưa ra những gợi ý áp dụng rộng rãi để bản thân
bạn sẽ trở thành một người chỉ dẫn và một lớp
học tham gia vào một cộng đồng.
Mất năng suất.
Có thể bạn tham gia vào trong một cộng đồng lớn, và
bạn đơn giản cảm thấy bị thua thiệt. Mục tiêu quá
rộng. Điều tốt nhất bạn có thể làm là học hỏi ai
đó khi bạn có các câu hỏi.
Trao ngược trở
lại. Phần mềm tự do nguồn mở (PMTDNM) sống sót
được trong những đóng góp. Đó là điều cốt lõi đối
với qui trình. Bạn có thể đóng góp ngược trở lại
tài liệu, các rà soát lại, và kiểm thử - tất cả các
dạng thức không nhất thiết phải có mã. Các đóng góp
nhỏ là có giá trị! Và cuối cùng bạn có thể là tài
nguyên cho người mới tới tiếp sau, người có các câu
hỏi như bạn từng có.
Uy quyền của cơ
hội. Phát triển PMTDNM có xu hướng sẽ là cơ hội
cao, có nghĩa là kế hoạch của bạn cho một khoảng thời
gian 10-15 tuần rơi vào khoảng 2 tuần trong học kỳ. Hãy
nhận thức được điều đó và chuẩn bị sẵn sàng.
Nếu điều đó
không công khai, thì điều đó đã không xảy ra. Các
quyết định trong PMTDNM được tiến hành chỉ trong các
chế tác công khai, bao gồm các danh sách thư, diễn đàn
và IRC. Nếu điều đó không công khai, thì điều đó
không đáng tin, và điều đó không phải là một đóng
góp. Các ý tưởng được chia sẻ trước khi chúng sẽ là
tuyệt vời, và điều đó là OK. Hãy quen với các giao
tiếp công khai, và để các học sinh của bạn cũng quen
với nó.
Hãy yêu cầu sự tha
thứ, không yêu cầu sự cho phép. Rất ít điều trong
PMTDNM không thể trở lại nguyên trạng. Hãy thử những
điều mới. Đôi khi có thể hóa ra là không phù hợp với
những ý định của cộng đồng, nhưng điều đó có thể
hóa ra là thú vị và hữu ích cho họ. Các nhánh là tự
do, và đôi khi các thí điểm kỳ dị lại có được các
kết quả thú vị.
Giữ lại lịch sử.
Kiểm soát phiên bản giúp được nhiều - giữ lại lịch
sử nên là tự động bất kỳ khi naof có thể. Lịch sử
giúp các học sinh hiểu được dự án vầ trao cho bạn
ngữ cảnh vì sao dự án được tiến triển theo một
hướng đặc biệt. Nó cũng giúp ai đó khác tìm ra được
người đóng góp trước đó ở đâu - giống như một học
sinh ra khỏi trường vào cuối học kỳ - ra đi.
Cuối cùng, hãy nhớ
rằng vào cuối tiến trình, là tốt hơn để giao tiếp
với công việc còn chưa được hoàn thành hơn là thực
hiện công việc không được giao tiếp. Các học sinh cần
bỏ tay khỏi công việc của họ một cách trang nhã. Hãy
để họ viết lại thành tài liệu những gì còn phải
làm và cố tìm ra ai đó tiếp tục nó (và làm cho nó tốt
hơn) hoặc rời bỏ nó ở nơi mà điều đó là dễ tìm
ra với một lưu ý rõ ràng cần thiết cho một người duy
trì. Sự đóng góp sẽ không hoàn chỉnh cho tới khi một
sự bàn giao được thực hiện.
POSSE (Mùa hè nguồn
mở/kinh nghiệm phần mềm của giáo sư) là sự phát triển
cho những người chỉ dẫn có quan tâm trong sự tham gia
của học sinh trong PMTDNM. Bài viết này dựa vào một
trình bày tại POSSE nă 2013 của Joanie Diggs và
Heidi Ellis.
We
talk about "community" a lot when it comes to open source,
but it's important to remember that just like local communities
within a city, town, state, and country, each community has its own
culture. One community is not
just like another. Each
has its own ways of communication and tracking and decision-making.
Processes for code submission differ—perhaps two communities both
use Bugzilla,
but with different flags. Others require you to also alert a mailing
list. A large software project may even have smaller sub-communities
within it with their own customs and quirks.
Learning
these differences is important to the success of your involvement in
an open source project, and students need to understand these nuances
when they're getting involved. For this year's POSSE class, Heidi
Ellis and Joanie Diggs offered suggestions that apply broadly to
getting yourself as an instructor and a class involved in a
community.
Be
productively lost.
Maybe you've gotten involved in a large community, and you simply
feel lost. The scope is just too broad. The best thing you can do is
learn whom to ask when you have questions.
Give
back. FOSS survives
on contributions. It's core to the process. You can pay back in
documentation, reviews, and testing—all sorts of ways that don't
necessarily involve code. Small contributions are valuable! And
eventually you can be the resource for the next newcomer who has
questions like you once did.
Opportunism
reigns. FOSS
development tends to be highly opportunistic, which means your plan
for a 10-15 week term may fall apart two weeks into the semester.
Recognize that and be prepared.
If
it isn't public, it didn't happen.
Decisions in FOSS are made only on public artifacts, including
mailing lists, forums, and IRC. If it's not public, it's not
accountable, and it's not a contribution. Ideas are shared before
they're perfect, and that's OK. Get used to public communication, and
get your students used to it as well.
Ask
forgiveness, not permission.
Very little in FOSS can't be reverted. Try new things. Something may
turn out to not be in line with the community's intentions, but it
may turn out to be interesting and useful to them after all. Branches
are free, and sometimes odd experiments have interesting results.
Keep
a history. Version
control helps a lot—history-keeping should be automatic whenever
possible. History helps students understand the project and gives you
context for why the project is headed in a particular direction. It
also helps someone else pick up where the previous contributor—like
a student leaving at the end of a term—left off.
Finally,
remember that at the end of the course, it's better to communicate
undone work than to do uncommunicated work. Students need to
gracefully hand off their work. Have them document what's remaining
to do and try to find someone to continue it (and make it better) or
leave it in a place that's easy to find with a clear note that it
needs a maintainer. The contribution isn't complete until a handoff
has been achieved.
POSSE
(Professor's Open Source Summer/Software Experience) is
professional development for instructors interested in student
participation in free and open source software. This post is based on
a presentation at POSSE 2013 by Joanie Diggs and Heidi Ellis.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.