Cơ quan tổ chức: Hội Tin học Việt nam
Đơn vị thường trực: Câu lạc bộ VFOSSA
Đối tượng tham dự:
Hình thức cuộc thi:
Lập trình hackathon theo đội tuyển với đề thi do BTC đưa ra.
Yêu cầu tham gia:
Các trường đăng kí các đội tuyển tham gia nội dung PMNM.
Mỗi đội thi phải bao gồm không quá 3 thí sinh và được dẫn dắt bởi một giảng viên của trường tham dự.
Mỗi trường chỉ được đăng kí tối đa 2 đội tuyển tham gia nội dung PMNM.
Giải thưởng:
Theo quy chế của cuộc thi OLP 2024.
Phương thức ra đề và làm bài thi:
Đề thi lập trình do các chuyên gia của VFOSSA xây dựng dựa trên việc thu thập bài toán yêu cầu cần giải quyết từ các cá nhân, tổ chức trong thực tế. Các bài toán yêu cầu được đặt ra phải theo cùng một chủ đề chung do BTC đưa ra.
Đề thi được giữ kín và sẽ được công bố trước 2 tuần của ngày chấm thi chung kết.
Sau khi đề thi được công bố, các đội tiến hành lập trình theo các yêu cầu của đề bài. Toàn bộ kết quả sản phẩm của các đội thi phải được công bố trên một kho mã nguồn mở.
Các đội thi chuẩn bị bài trình bày và nội dung trình diễn sản phẩm kết quả tại buổi chấm thi của BTC OLP.
BTC chấm điểm bài thi và sắp xếp phân hạng dựa trên sản phẩm đã được công bố trên kho nguồn mở và kết quả trình diễn tại buổi chung kết.
Chủ đề cuộc thi năm 2024:
Lịch trình tổ chức:
Tháng 8/2024: Công bố chủ đề và phát động cuộc thi PMNM - OLP 2024
Tháng 9-10/2024: Thu thập ý tưởng, bài toán yêu cầu thực tiễn theo chủ đề cuộc thi
Tháng 11/2024: BTC ra đề và tiếp nhận thông tin danh sách đăng kì thi
Ngày 20/11-8/12/2024: Công bố đề thi và các đội tham gia lập trình hackathon
Ngày 9-11/12/2024: Chấm thi kho mã nguồn của sản phẩm dự thi
Ngày 12/12/2024: Trình diễn sản phẩm và chấm thi chung kết
Ngày 13/12/2024: Công bố trao giải
Các tiêu chí chấm điểm
Yêu cầu bắt buộc đối với các dự án tham gia dự thi phải là phần mềm nguồn mở được phát hành theo giấy phép OSI-approved (http://opensource.org/licenses) và có thể truy cập tự do mã nguồn trên Internet. Chỉ các dự án đáp ứng được yêu cầu là phần mềm nguồn mở mới được BTC chấm điểm xếp hạng theo các tiêu chí chi tiết như bảng dưới đây| STT | Tiêu chí | Điểm tối đa | Điểm trừ | Ghi chú |
| I | Tiêu chí dựa trên PoF | 50 | Chấm trước buổi chung kết | |
| 1 | Sử dụng hệ thống quản lý mã nguồn trên Internet | 5 | Có thể truy cập kho mã nguồn của sản phẩm từ Internet | |
| Có hệ thống quản lý mã nguồn công khai, nhưng không có web viewer | -3 | |||
| Có hệ thống quản lý mã nguồn nhưng không được truy cập mở | -3 | |||
| Có hệ thống quản lý mã nguồn nhưng trên thực tế không được sử dụng | -5 | |||
| 2 | Cấp phép PMMN theo giấy phép OSI-approved | 10 | Sản phẩm có giấy phép mở và giải quyết đúng đầu bài của đề thi | |
| Giấy phép không được ghi trong từng tệp mã | -5 | |||
| Mã nguồn tự thân chứa sự không tương thích của các giấy phép | -5 | |||
| Mã nguồn không có thông báo về mục đích của giấy phép | -5 | |||
| Mã nguồn không bao gồm một bản sao toàn văn giấy phép | -5 | |||
| 3 | Có ít nhất một bản phát hành (release) để làm sản phẩm dự thi | 5 | Bản release đầu tiên phải được tạo trước thời điểm nộp bài thi | |
| Dự án không có phát hành | -5 | |||
| Dự án không thực hiện phát hành theo phiên bản | -3 | |||
| Sử dụng các định dạng không phải là mở cho bản phát hành (vd., zip, .rar, .arj, …) | -3 | |||
| 4 | Cài đặt, dịch từ mã nguồn (Building From Source) | 10 | Sản phẩm phải cho phép cài đặt, biên dịch được từ mã nguồn | |
| Không có hướng dẫn dịch từ mà nguồn | -5 | |||
| Mã nguồn được cấu hình bằng cách sửa thủ công vào các tệp header | -5 | |||
| Mã nguồn không cấu hình được trước khi dịch | -5 | |||
| Mã nguồn được dịch bằng công cụ nguồn đóng hoặc tự tạo | -5 | |||
| Chương trình không thể hoạt động nếu nằm ngoài thư mục mã nguồn | -5 | |||
| 5 | Sử dụng thư viện và gói đính kèm (bundling) | 10 | Có thông tin làm rõ các thư viện, gói đính kèm được sử dụng | |
| Không cố gắng sử dụng các thư viện sẵn có trong hệ thống | -5 | |||
| Phát hành cùng với gói đính kèm của các dự án khác mà nó phụ thuộc vào | -5 | |||
| Mã nguồn của gói đính kèm đã bị chỉnh sửa | -5 | |||
| 6 | Tài liệu và giao tiếp | 10 | Tài liệu rõ ràng, thực hiện được | |
| Không có ghi nhận quản lý lỗi phần mềm (bug tracker) | -5 | |||
| Không có lịch sử thay đổi mã nguồn (changelog) | -5 | |||
| Không có tài liệu readme và hướng dẫn | -5 | |||
| II | Tiêu chí dựa trên sản phẩm | 50 | Chấm trong buổi chung kết | |
| 7 | Tính nguyên gốc của giải pháp kĩ thuật | 10 | Dựa trên kết quả trình bày về sự sáng tạo của đội thi | |
| 8 | Mức độ hoàn thiện của sản phẩm | 10 | Dựa trên kết quả chạy trình diễn sản phẩm | |
| 9 | Mức độ sử dụng thân thiện của sản phẩm | 10 | Dựa trên các tiện ích của sản phẩm đối với người dùng | |
| 10 | Mức độ phát triển bền vững của sản phẩm | 10 | Dựa trên các tài liệu kĩ thuật, công cụ hỗ trợ công bố kèm theo | |
| 11 | Phong cách trình diễn và khả năng thu hút cộng đồng nguồn mở | 10 | Dựa trên showcase trình diễn sản phẩm tại cuộc thi |
Nguồn tham khảo về tiêu chí chấm điểm PoF
How you know your Free or Open Source Software Project is doomed to FAIL (or at least, held back from success) xuất bản bởi Tom Callaway trên Livejournal ngày 2009-05-29 (http://spot.livejournal.com/308370.html)
Bản dịch: Đánh giá khả năng phát triển của một dự án PMTDNM - Trương Anh Tuấn. (http://blog.iwayvietnam.com/tuanta/2013/04/danh-gia-kha-nang-phat-trien-cua-mot-du-an-foss/)
Tác giả: Tiến Phạm Đức
Ý kiến bạn đọc
