16
FOSSisms all educators should know
Posted
10 Jun 2014 Bryan
Behrenshausen
Bài
được đưa lên Internet ngày: 10/06/2014
Khi
Heidi Ellis trình bày tại hội nghị Kinh nghiệm Mùa hè
Nguồn Mở của các Giáo sư vào năm nay (this
year's Professors' Open Source Summer Experience) - được tổ
chức vào các ngày 28-30/05/2014 tại Đại học Drexel ở
Philadelphia - bà đã muốn các đồng nghiệp của bà hiểu
được những lợi ích giáo dục vô cùng to lớn của việc
lôi kéo các sinh viên vào các dự án nguồn mở.
Và
điều gì giúp họ nhận thức được những lợi ích đó
tốt bằng sự thông thái được tôi luyện rồi của bản
thân các cộng đồng nguồn mở.
Ellis,
người đã cùng điều phối POSSE với giáo sư Greg Hislop
ở Đại học Drexel, đã nói với đám đông gần 20 thành
viên giáo viên từ các trường cao đẳng và đại
học
khắp đất nước rằng việc nhúng các sinh
viên môn khoa học máy tính của họ vào các cộng đồng
nguồn mở có thể tạo thuận lợi cho dạng cam kết tham
gia mà các kinh nghiệm trong các lớp học truyền thống
không thể đưa ra. Nhưng, bà nói, các sinh
viên và các giáo sư, giống như nhau, nên chuẩn
bị để bị sốc văn hóa một chút nếu họ không được
chuẩn bị để ôm lấy cách thức nguồn mở.
Vì
thế Ellis đã dẫn nguồn 16 nguyên tắc từ văn hóa phần
mềm tự do nguồn mở - những gì bà gọi là “FOSSisms”
(các nguyên tắc của FOSS, hoặc chủ nghĩa FOSS) - để
giải thích cách mà các giá trị nguồn mở có thể biến
đổi giáo dục của khoa học máy tính.
FOSSism
#1: Tất cả là về cộng đồng
Việc
để sinh
viên bắt đầu với nguồn mở ngụ ý yêu cầu
họ làm nhiều hơn so với đơn giản chỉ công việc trong
một dự án mới. Nó liên quan tới việc yêu cầu họ ra
nhập một cộng đồng, Ellis nói. Và “Khi bạn làm thế”,
bà nói “bạn đang ra nhập một văn hóa mới”.
Vì
thế các sinh
viên phải
nhanh chóng thích nghi với các chuẩn mực không được nói
thành lời của nhóm người với các phương pháp, các ưu
tiên, và cả các trò đùa của riêng nó. Khi ra nhập một
cộng đồng nguồn mở, các sinh
viên nên xác định rằng các kênh giao tiếp
ưu tiên của cộng đồng và sử dụng chúng như các cánh
cửa dẫn vào văn hóa của nó.
“Cộng
đồng dẫn dắt dự án”, Ellis nói, “chứ không phải
ngược lại”.
Bằng
việc ra nhập các cộng đồng nguồn mở, các sinh
viên có
được sự truy cập tới các chuyên gia có thể trợ giúp
cho họ khi họ bắt đầu vật lộn với những đóng góp
của họ. Theo cách này, các thành viên giáo viên có được
những người hướng dẫn có giá trị cho các sinh
viên của họ.
“Một
khi bạn ở trong cộng đồng, bạn là một phần của cộng
đồng đó”, Ellis nói. “Đó là một trong những lợi
ích. Họ sẽ quan tâm tới các sinh
viên của bạn”.
FOSSisms
#2: Hãy là sự mất mát có hiệu quả
Phạm
vi của bất kỳ dự án hoặc cộng đồng nguồn mở nào
cũng vượt quá bất kỳ khả năng của riêng bất kỳ một
con người nào để lĩnh hội thấu đáo nó hoàn toàn. Hệ
quả là, các sinh
viên có thể thấy sự mất mát hoặc lênh
đênh trong miền đất không quen thuộc. Nhưng các người
chỉ dẫn của họ nên khuyến khích họ sử dụng sự
lúng túng của họ một cách có hiệu quả - để nghiên
cứu cộng đồng đó và để học về dự án bằng việc
đào sâu qua các tư liệu của nó. Giai đoạn mất phương
hướng quay cuồng trong đầu là tự nhiên tuyệt vời -
thậm chí có lợi - Ellis đã khẳng định với khán thính
phòng của bà. Điều y hệt là đúng cho các giáo sư,
những người cũng là mới với các dự án nguồn mở
được chọn của họ.
“Đây
có thể là khái niệm rất xa lạ đối với những người
chỉ dẫn”, Ellis nói. “Chúng ta được dạy rằng chúng
ta được hỗ trợ để trở thành các chuyên gia của vấn
đề chủ đề đó”.
FOSSisms
#3: Trao ngược trở lại
Các
dự án phần mềm nguồn mở sống sót vì những đóng góp
từ những người
sử dụng và các lập trình viên, Ellis giải thích,
nên các sinh
viên phải học để bắt đầu trao ngược trở
lại ngay tức thì. Họ nên cập nhật tài liệu, mã kiểm
thử, khẳng định các lỗi, trả lời các câu hỏi từ
những người khác - lao vào bất kỳ nơi đâu họ có thể.
Họ sẽ sớm học được họ không cần phải là các
chuyên gia để tạo ra các ảnh hưởng tích cực cho các
cộng đồng của họ; họ chỉ cần có thiện chí làm
việc. Thậm chí những đóng góp nhỏ nhất là có giá
trị, Ellis nói.
FOSSisms
#4: Chủ nghĩa cơ hội ngự trị
Vì
ít lập trình viên nguồn mở làm việc trong dự án của
họ toàn thời gian, việc cạnh tranh các yêu cầu luôn hạn
chế khả năng của họ để đóng góp. Vì thế sự phát
triển nguồn mở có thể khá là cơ hội chủ nghĩa, Ellis
giải thích: sự phát triển diễn ra theo những cố gắng
khi các lập trình viên tận dụng các tài nguyên sẵn có.
Các sinh
viên phải nhận thức được rằng các quy
trình phát triển nguồn mở không luôn phản ánh những gì
của giới công nghiệp; công việc có thể xảy ra theo
từng đợt và bắt đầu phù hợp khả năng của các
thành viên cộng đồng.
FOSSisms
#5: Nếu điều đó không công khai, thì điều đó không
xảy ra
Công
việc nguồn mở xảy ra công khai. Các lập trình viên sử
dụng các danh sách thư, các kênh chat IRC, và các kênh giao
tiếp công khai khác nên mọi người trong cộng đồng - và
bất kỳ ai muốn ra nhập cộng đồng - có thể chọn
bất kỳ điều gì họ đang làm. Các sinh
viên phải trở nên thoải mái với cách làm
việc công khai và chia sẻ các tài nguyên của họ, Ellis
nói.
“Nếu
mọi người không thể thấy họ”, bà nói, thì “họ là
không tốt đối với mọi người”.
Sự
minh bạch cũng có thể gây hoảng hốt cho cả các giáo sư
nữa, Ellis bổ sung.
“Hầu
hết các nhà nghiên cứu hàn lâm là thâm căn cố đế và
về điều đó và bạn không xuất bản bất kỳ điều gì
cho tới khi nó trở nên hoàn hảo”, bà nói. “Trong thế
giới nguồn mở, điều đó là hoàn toàn ngược lại”.
FOSSisms
#6: Ôm lấy sự minh bạch tận gốc
Vì
các cộng đồng nguồn mở tham gia trong phát triển một
cách phân tán, họ ôm lấy sự minh bạch tận gốc và các
tư liệu họ tạo ra - tất cả tư liệu, mã, và các chế
tác khác mà các sinh
viên có thể giành lấy để cải thiện việc
học hỏi của họ - mặc định là mở, sẵn sàng để sử
dụng trong lớp học (và hơn thế).
“Tất
cả điều này là con đường giàu, giàu có cho việc học
tập”, Ellis nói.
FOSSisms
#7: Yêu cầu tha thứ, chứ không yêu cầu sự cho phép
Hầu
hết lúc nào cũng vậy, các cộng đồng nguồn mở sử
dụng vài dạng kiểm soát phiên bản, Ellis giải thích,
nên các sinh
viên nên nhận thức được rằng những đóng
góp của họ ít có cơ hội làm trệch hướng hoàn toàn
một dự án. Họ không cần yêu cầu sự cho phép để vọc
với thứ gì đó; họ nên đơn giản bắt đầu làm việc,
yêu cầu sự tha thứ của cộng đồng nếu họ làm sai.
Thường gặp nhiều hơn là không, các thành viên cộng
đồng hiểu và hỗ trợ, vì việc sửa các lỗi lầm mất
ít nỗ lực.
FOSSisms
#8: Các nhánh là tự do
Các
sinh
viên vẫn
ngần ngại làm việc trực tiếp với kho mã của cộng
đồng nên nhớ rằng họ có thể dễ dàng tạo nhánh một
dự án đang tồn tại và thay
vào đó
nghịch
với các bản sao cục bộ. Làm điều này có thể giải
phóng họ để thực hành. Điều đó có thể làm cho họ
sửa được lỗi - một kết quả họ có thể sau đó dễ
dàng chia sẻ với dự án, Ellis nói.
FOSSisms
#9: Duy trì lịch sử
Kiểm
soát phiên bản chỉ là một cách thức các cộng đồng
nguồn mở duy trì lịch sử. Nhưng gần như mọi thành
phần trong chuỗi công cụ phát triển nguồn mở đều
được lưu lại. Vì thế các sinh
viên có thể sử dụng các hồ sơ dự án để
tiêu hóa nhanh chóng hơn trong cộng đồng đó. Họ cũng có
thể sử dụng các công cụ duy trì hồ sơ y hệt, Ellis
nói, khi học kỳ tới gần và họ sẵn sàng để đưa ra
công việc họ đã làm xong.
FOSSisms
#10: Bắt đầu bằng những việc nhỏ
Các
sinh
viên nên luôn bắt đầu bằng các lỗi nhỏ
nhất, dường như phi logic nhất, Ellis nói - quả ở tầm
thấp cho phép họ tiến hành những đóng góp có hiệu quả
cho dự án sớm nhất theo thời gian. Họ có thể cập nhật
tài liệu hoặc thẩm định lỗi, những đóng góp quan
trọng đòi hỏi ít tri thức về dự án. Ellis đã cảnh
báo rằng các giáo sư yêu cầu các sinh
viên của họ bắt đầu bằng việc xác định
những đóng góp cho dự án có lẽ bản thân họ thấy quá
tải.
“Đừng
có ôm cả thế giới”, bà nói.
FOSSisms
#11: Đó không phải là những gì bạn biết; đó là những
gì bạn muốn học
Với
tư cách của họ là người đứng trong lớp học - một
môi trường thiên về tính tò mò - các sinh
viên nằm
ở vị trí tốt rồi để đóng góp cho các dự án nguồn
mở, Ellis nói, vì các cộng đồng đó đánh giá cao các
thành viên muốn học cách họ có thể trợ giúp. Mỗi
thành viên của cộng đồng nguồn mở từng một lần là
những người mới tới, Ellis nhắc nhở các đồng nghiệp
của bà; các dự án nguồn mở thường chào đón các
thành viên mới sẵn sàng và có thiện chí học các kỹ
năng cần thiết để tạo ra sự khác biệt cho dự án.
FOSSisms
#12: Phát hành sớm, phát hành thường xuyên
Các
ứng dụng nguồn mở hưởng lợi từ các vòng phản hồi
ngắn, chặt chẽ giữa các lập
trình viên và những người
sử dụng, Ellis nói. Các dự án thường lặp đi lặp
lại, và các sinh
viên nên quen với sự thay đổi liên tục.
Nhưng một trạng thái “phát hành sớm và thường xuyên”
cũng đảm bảo rằng các sinh
viên học được từ các sai lầm của họ
nhanh chóng - thường nhanh hơn so với họ có thể nếu họ
chờ đợi hàng tuần người chỉ dẫn duy nhất hoặc
người trợ giảng để đánh giá và xếp loại công việc
của họ.
FOSSisms
#13: Đẩy lên dòng trên
Các
sinh
viên nên luôn – luôn luôn, luôn luôn - đẩy
công việc của họ tới các lập trình viên và các cộng
đồng dòng trên, từ những nơi mà họ hưởng lợi. Đây
là cách thức đúng duy nhất trong các cộng đồng nguồn
mở. Bằng cách làm như vậy, các sinh
viên cũng nhận thức được về ý thức hoàn
thành khi các cộng đồng nhận thức được về chức
năng và sự tao nhã học đã cung cấp cho một dự án.
Ngắn gọn, các sinh
viên học về tầm quan trọng của việc có đi
có lại - về việc
đóng góp ngược trở lại.
FOSSisms
#14: Hãy cho tôi xem mã
Các
cộng đồng nguồn mở, Ellis nói, là thực dụng tuyệt
vời: các lập trình viên chỉ là tốt như kỹ năng họ
thể hiện. Như Linus Torvalds đã
nói: “Nói thì ít có giá trị. Hãy cho tôi xem mã”.
Các sinh
viên tham gia trong các dự án nguồn mở phải
sẵn sàng tiếp xúc với việc lập trình tận gốc nếu
họ muốn được chấp nhận như một phần của các cộng
đồng đáng kính của họ.
FOSSisms
#15: Hãy nhớ làm cạn các lỗi
Ellis
đã nhắc các đồng nghiệp của bà về những gì Eric
Raymond gọi là “Luật Linus” (Linus'
Law): "đưa ra đủ các cặp mắt, thì tất cả các
lỗi sẽ cạn". Các sinh
viên, bà nói, phảI học chấp nhận sự giúp
đỡ từ các cộng đồng mà họ là một phần của nó;
họ phải sẵn sàng yêu cầu trợ giúp khi họ cần nó,
hơn là kéo lê trong sự cô lập trong khi sự khó chịu
ngày càng gia tăng. Họ nên nói ra ngay lập tức khi họ có
khó khăn, sao cho cộng đồng có thể can thiệp và thảo
luận về vấn đề đó như một nhóm.
FOSSisms
#16: Tránh công việc không có giao tiếp
Ellis
nói rằng các sinh
viên phải học để biến đổi công việc của
họ một cách trang nhã khi họ kết thúc thời gian học
tập nghiên cứu hàn lâm; họ nên biết rằng các nỗ lực
của họ sẽ không hoàn chỉnh cho tới khi họ đã đảm
bảo rằng các cộng đồng của họ có thể an toàn quan
tâm chăm sóc (hiểu, duy trì, và xây dựng dựa vào nó)
tới những gì họ đã đóng góp. Họ luôn nên nhận diện
ra những người duy trì dự án và trao đổi về những ý
định của họ một cách đúng đắn - thậm chí nếu họ
không đạt được các mục tiêu của họ.
“Là
tốt hơn để trao đổi công việc chưa làm được”,
Ellis nói, “hơn là tiến hành công việc không có giao
tiếp”.
When
Heidi Ellis took the floor at this
year's Professors' Open Source Summer Experience—held May 28-30
at Drexel University in Philadelphia—she wanted her colleagues to
understand the extraordinary educational benefits of involving
students in open source projects.
And
what better to help them realize these benefits than the distilled
wisdom of open source communities themselves.
Ellis,
who co-coordinated POSSE with Drexel professor Greg Hislop, told a
crowd of nearly 20 faculty members from colleges and universities
across the country that embedding their computer science students in
open source communities could facilitate a kind of engagement
traditional classroom experiences just can't offer. But, she said,
students and professors alike should be prepared for a bit of culture
shock if they aren't prepared to embrace the open source way.
So
Ellis derived 16 maxims from free and open source culture—what she
calls "FOSSisms"—to explain how open source values might
transform computer science education.
FOSSism #1: It's all about community
Getting
students started with open source means asking them to do more than
simply work on a new project. It involves asking them to join a
community, Ellis said. And "when you do that," she said
"you're joining a new culture."
So
students must quickly acclimate to the unspoken norms of a group with
its own methods, preferences, and in-jokes. When joining an open
source community, students should identify that community's preferred
channels of communication and use those as windows into its culture.
"The
community drives the project," Ellis said, "not vice
versa."
By
joining open source communities, students gain access to experts that
can assist them when they begin struggling with their contributions.
In this way, faculty members acquire valuable mentors for their
students.
"Once
you're in the community, you're a part of the community," Ellis
said. "That's one of the benefits. They'll care for your
students."
FOSSism #2: Be productively lost
The
scope of any open source project or community exceeds any single
person's ability to completely comprehend it. Consequently, students
might feel lost or adrift in unfamiliar territory. But their
instructors should encourage them to use their confusion
productively—to investigate the community and to learn about a
project by digging through its materials. A period of head-spinning
disorientation is perfectly natural—even beneficial—Ellis assured
her audience. The same is true for professors who are also new to
their chosen open source projects.
"This
can be a very foreign concept to instructors," Ellis said. "We
are taught that we are supposed to be the subject matter experts."
FOSSism #3: Give back
Open
source software projects survive on contributions from users and
developers, Eillis explained, so students must learn to start giving
back immediately. They should update documentation, test code,
confirm bugs, answer questions from others—pitch in wherever they
can. They'll soon learn they don't need to be experts to make
positive impacts to their communities; they just need to be willing
to do the work. Even the smallest contributions are valuable, Ellis
said.
FOSSism #4: Opportunism reigns
Because
few open source developers work on their projects full-time,
competing demands always limit their ability to contribute. So open
source development can be rather opportunistic, Ellis explained:
development occurs in spurts as coders take advantage of resources as
they appear. Students must realize that open source development
processes don't always mirror those of industry; work might occur in
fits and starts according to community members' availability.
FOSSism #5: If it isn't public, it didn't happen
Open
source work occurs in the open. Coders make use of mailing lists, IRC
channels, and other public communication channels so everyone in the
community—and anyone wanting to join
the
community—can peek at what they're doing. Students must become
comfortable with working in public and sharing their resources, Ellis
said.
"If people can't see them,"
she said, "they're no good to people."
Transparency can be startling to
faculty, too, Ellis added.
"Most academics have it
ingrained in them that you don't publish anything until it's
perfected," she said. "In the open source world, it's the
complete opposite."
FOSSism #6: Embrace radical transparency
Because
open source communities engage in distributed development, they
embrace radical transparency and the materials they produce—all the
documentation, code, and other artifacts that students can seize to
enhance their learning—are open by default, ready for use in the
classroom (and beyond).
"All
this is a rich, rich avenue for learning," Ellis said.
FOSSism #7: Ask forgiveness, not permission
Almost
invariably, open source communities utilize some form of version
control, Eillis explained, so students should realize that their
contributions have little chance of completely derailing a project.
They needn't ask permission to tinker with something; they should
simply begin working, asking for the community's forgiveness if they
make a mistake. More often than not, community members are
understanding and supportive, because undoing errors involves little
effort.
FOSSism #8: Branches are free
Students
still reluctant to work directly with a community's codebase should
remember that they can easily branch an existing project and fiddle
with local copies instead. Doing this might liberate them to
experiment. It might even result in their fixing a bug—a result
they can then easily share with the project, Ellis said.
FOSSism #9: Keep a history
Version
control is merely one way that open source communities keep
histories. But nearly every component in open source development
toolchains keeps records. So students can use a project's records to
more quickly assimilate into the community. They can also use these
same record-keeping tools, Ellis added, when the semester comes to a
close and they're ready to hand off the work they've done.
FOSSism #10: Begin with the finishing touches
Students
should always begin with the smallest, most seemingly inconsequential
bugs, Ellis said—the low-hanging fruit that allows them to make
productive contributions to a project early in the term. They might
update documentation or verify a bug, important contributions that
require little knowledge of a project. Ellis cautioned that
professors asking their students to begin with project-defining
contributions might find themselves overwhelmed.
"Don't
take on the world," she said.
FOSSism #11: It's not what you know; it's what you want to learn
By
virtue of their being in a classroom—an environment predisposed to
inquisitiveness—students are already well-positioned to contribute
to open source projects, Ellis said, because these communities value
members who want to learn how they can assist. Every member of an
open source community was once a newbie, Ellis reminded her
colleagues; open source projects typically welcome new members ready
and willing to learn the skills necessary to make a difference to the
project.
FOSSism #12: Release early, release often
Open
source applications benefit from short, tight feedback loops between
developers and users, Ellis said. Projects iterate often, and
students should become accustomed to constant change. But a "release
early and often" mentality also ensures that students learn from
their mistakes quickly—often quicker than they would if they waited
weeks for a single instructor or teaching assistant to assess and
grade their work.
FOSSism #13: Push to upstream
Students
should always—always, always—push their work to the upstream
developers and communities from whom they benefit. This is only
proper decorum in open source communities. But by doing so, students
also realize a sense of accomplishment as communities recognize the
functionality and polish they've provided to a project. In short,
students learn the importance of reciprocity—of giving
back.
FOSSism #14: Show me the code
Open
source communities, Ellis said, are consummately pragmatic:
programmers are only as good as the skills they demonstrate. As Linus
Torvalds has
said: "Talk is cheap. Show me the code." Students
participating in open source projects must be ready to hit the ground
coding if they want to be accepted as part of their respective
communities.
FOSSism #15: Remember shallow bugs
Ellis
reminded her colleagues of what Eric Raymond calls "Linus'
Law": "given enough eyeballs, all bugs are shallow."
Students, she said, must learn to accept help from the communities of
which they're a part; they must be ready to ask for help when they
need it, rather than toil away in isolation while growing
increasingly frustrated. They should speak up immediately when
they're having trouble, so the community can step in and discuss the
problem as a group.
FOSSism #16: Avoid uncommunicated work
Ellis
said that students must learn to transfer their work gracefully when
they finish the academic term; they should know that their efforts
aren't complete until they've ensured that their communities can
safely care for (understand, maintain, and build upon) what they've
contributed. They should always identify project maintainers and
communicate their intentions appropriately—even if they've fallen
short of their goals.
"It's
better to communicate undone work," Ellis said, "than to do
uncommunicated work."
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.