Làm thế nào để một lớp học tham gia vào với một dự án nguồn mở

How to get a class involved with an open source project

Posted 27 Jun 2013 by Ruth Suehle

Theo: http://opensource.com/education/13/6/how-to-open-source-projects-classroom

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 whe-re 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

letrungnghia.foss@gmail.com