Một đóng góp cho dự án bạn không sở hữu sẽ đọc như công việc đáng tin cậy trên CV khi mục đó nêu chính xác bạn đã làm gì với dự án: một pull request cụ thể đã được merge, một lỗi bạn đã tìm ra và sửa, một bản review bạn đưa ra đã định hình thay đổi của người khác, hoặc vai trò maintainer bạn nắm giữ trong dự án, thay vì chỉ đặt tên repository cạnh một đường link. Đóng góp mã nguồn mở khác với một dự án bạn tự xây dựng ở một điểm quan trọng: tên bạn nằm trong lịch sử commit cùng với tên những người khác, trên một dự án đã tồn tại và có maintainer riêng trước khi bạn xuất hiện và vẫn tiếp tục chạy sau khi thay đổi của bạn được đưa vào, vì vậy mục này cần nêu rõ phần việc cụ thể của bạn thay vì để người đọc mặc định bạn sở hữu toàn bộ dự án.
Vì sao một dòng mã nguồn mở cần cách diễn đạt khác với một dự án bạn sở hữu
Với một dự án bạn tự xây dựng và kiểm soát hoàn toàn, cách trình bày dự án cá nhân trên CV kỹ sư phần mềm đã nói về việc mô tả dự án làm gì, bạn xây dựng nó bằng công cụ gì, và điều gì thay đổi vì bạn đã xây dựng nó. Một đóng góp mã nguồn mở lại đặt ra câu hỏi khác trước tiên, không phải dự án làm gì, vì người đọc thường có thể tra cứu điều đó trong vài giây nếu dự án đã nổi tiếng, mà là bạn cụ thể đã làm gì bên trong một dự án đã tồn tại sẵn và đã có hướng đi riêng. Một dòng mơ hồ đặt cạnh tên một dự án nổi tiếng, không mô tả gì về sự tham gia thực sự của bạn, có thể đọc như một nỗ lực mượn danh tiếng của dự án đó thay vì mô tả công việc thật, điều ngược lại với mục đích của mục này.
Các loại đóng góp đáng nêu cụ thể
Một pull request đã được merge là đơn vị đóng góp rõ ràng nhất để nêu tên, và việc nêu nó đã thay đổi gì quan trọng hơn việc chỉ nói nó tồn tại: một bản sửa lỗi cụ thể, một tính năng mới, một cải thiện hiệu năng, hoặc một phần tài liệu còn thiếu. Việc review code là công việc thật, có giá trị trên một dự án đang hoạt động, và đáng được liệt kê riêng khỏi các thay đổi bạn tự merge khi bạn đã làm đủ nhiều để nó có ý nghĩa, đặc biệt trên một dự án mà chất lượng review là một phần cách các maintainer đánh giá vị thế của một người đóng góp. Vai trò maintainer hoặc triage, nơi bạn có quyền commit, review pull request của người khác, hoặc quản lý issue cho một dự án, đáng có dòng riêng thay vì gộp vào một câu chung chung "người đóng góp", vì nó nói lên điều mà một bản sửa lỗi đơn lẻ không nói được: rằng các maintainer khác tin tưởng đánh giá của bạn một cách liên tục. Những đóng góp lặp lại cho cùng một dự án qua nhiều tháng cũng đáng được mô tả như một mẫu hình thay vì chỉ liệt kê thay đổi ấn tượng nhất, vì một mẫu hình hoạt động đọc như sự tham gia bền vững hơn là một lần đóng góp đơn lẻ.
Ví dụ minh họa: một dòng đóng góp mã nguồn mở
Ví dụ minh họa, từ mơ hồ đến cụ thể. Mơ hồ: "Người đóng góp, dự án mã nguồn mở (github.com/example/project)." Cụ thể: "Người đóng góp, một công cụ dòng lệnh mã nguồn mở dùng cho môi trường phát triển cục bộ. Đã sửa một lỗi khiến công cụ bị treo với các tệp cấu hình lớn, và review nhiều pull request của những người đóng góp khác cho cùng repository trong sáu tháng." Phiên bản cụ thể nêu mục đích của dự án trong một câu, nói rõ thay đổi đã merge thực sự sửa gì, và tách công việc review khỏi bản sửa lỗi thay vì ngụ ý cả dòng chỉ mô tả một đóng góp duy nhất.
Ghi nhận công sức chung mà không nhận vơ
Hầu hết mọi thay đổi được merge trên một dự án mã nguồn mở đang hoạt động thường trải qua review của người khác trước khi được đưa vào, và một mục CV ngụ ý bạn là tác giả duy nhất của một tính năng mà thực ra nhiều maintainer đã cùng định hình sẽ đọc như nhận vơ ngay khi ai đó kiểm tra lịch sử commit, điều mà với một repository công khai chỉ mất vài giây. Nêu rõ phần đóng góp cụ thể của bạn, một bản sửa lỗi, một tính năng, một mảng bạn thường xuyên review, thay vì mô tả toàn bộ chức năng dự án như thể bạn tự tay xây dựng, giữ cho mục này vừa trung thực vừa, trong hầu hết trường hợp, cụ thể và đáng tin hơn một tuyên bố rộng lớn. Khi nhiều đóng góp của bạn tập trung quanh một mảng của dự án, chẳng hạn công cụ build hoặc bộ test, nêu tên mảng đó thường cung cấp nhiều thông tin cho người đọc hơn là liệt kê từng pull request nhỏ riêng lẻ.
Khác với dự án bạn tự sở hữu ra sao
Một dự án cá nhân bạn tự xây dựng từ đầu xứng đáng có một dòng mô tả mục đích và kết quả của nó vì bạn đã quyết định mọi thứ về việc nó làm gì và làm như thế nào. Một đóng góp mã nguồn mở xứng đáng có một dòng mô tả phần cụ thể của bạn bên trong các quyết định của người khác, vì hướng đi tổng thể, kiến trúc và phạm vi của dự án thường đã được định hình từ trước khi bạn tham gia. Cả hai đều là công việc kỹ thuật hợp lệ đáng có chỗ trên CV, nhưng nhầm lẫn hai loại này, mô tả một đóng góp mã nguồn mở theo cách bạn mô tả dự án của riêng mình, có xu hướng hoặc phóng đại vai trò của bạn trong dự án chung hoặc hạ thấp công việc cụ thể mà bạn thực sự đã làm.
Nên đặt ở đâu trên CV
Một đóng góp mã nguồn mở đáng kể, hoặc một vai trò maintainer được giữ theo thời gian, thường xứng đáng có dòng riêng trong một mục dự án cùng với các dự án cá nhân, vì cả hai đều mô tả công việc kỹ thuật ngoài một công việc được trả lương. Một vài đóng góp nhỏ hơn trên các dự án khác nhau thường tốt hơn khi được gộp dưới một tiêu đề, chẳng hạn "Đóng góp mã nguồn mở", nêu ngắn gọn từng dự án thay vì cho bốn dòng mỏng, gần giống nhau cùng một mức độ chú ý thị giác như một mục được mô tả kỹ. Mẫu Developer được xây dựng với một khu vực dự án cạnh lịch sử làm việc, phù hợp với loại mục này dù nó xuất phát từ một công việc hay hoàn toàn đứng độc lập.
Thêm vào CV của bạn
Một đóng góp mã nguồn mở, được mô tả cụ thể và ghi nhận trung thực, là bằng chứng thật về năng lực kỹ thuật mà người đọc thường có thể kiểm chứng trực tiếp. Bắt đầu từ một mẫu được xây dựng cho công việc kỹ thuật và thêm các đóng góp của bạn trong trình tạo CV, nơi bạn có thể tiếp tục tinh chỉnh câu chữ khi có đóng góp mới.