From c30666fb7c4a712a8179a40cac22482214d639c8 Mon Sep 17 00:00:00 2001 From: hkohko Date: Tue, 16 Apr 2024 21:21:35 +0700 Subject: [PATCH 1/5] 1.1.0 en to id translation draft --- source/id/1.1.0/index.html.haml | 302 ++++++++++++++++++++++++++++++++ 1 file changed, 302 insertions(+) create mode 100644 source/id/1.1.0/index.html.haml diff --git a/source/id/1.1.0/index.html.haml b/source/id/1.1.0/index.html.haml new file mode 100644 index 00000000..f3df7f57 --- /dev/null +++ b/source/id/1.1.0/index.html.haml @@ -0,0 +1,302 @@ +--- +title: Pencatatan Changelog +description: Standarisasi pencatatan Changelog untuk kolaborasi yang lebih baik +language: id +version: 1.1.0 +--- +.header + .title + %h1= current_page.data.title + %h2= current_page.data.description + + = link_to data.links.changelog do + Version + %strong= current_page.metadata[:page][:version] + + %pre.changelog{ lang: "en" }= File.read("CHANGELOG.md") + +.answers + %h3#what + %a.anchor{ href: "#what", aria_hidden: "true" } + Apa itu changelog? + + %p + Changelog adalah sebuah file berisi perubahan penting setiap versi sebuah proyek yang kronologis dan terkurasi. + + %h3#why + %a.anchor{ href: "#why", aria_hidden: "true" } + Kenapa mencatat changelog? + + %p + Agar perubahan penting antar versi sebuah proyek lebih mudah diamati bagi pengguna maupun kontributor. + + %h3#who + %a.anchor{ href: "#who", aria_hidden: "true" } + Siapa yang membutuhkan changelog? + + %p + Kita semua. Baik itu pengguna atau pengembang, konsumen perangkat lunak adalah manusia yang peduli akan isi perangkat lunak tersebut. Kita semua ingin mengetahui bagaimana perangkat lunak tersebut berubah dan alasan dibalik perubahan tersebut. + +.good-practices + %h3#how + %a.anchor{ href: "#how", aria_hidden: "true" } + Bagaimana cara mencatat changelog yang baik? + + %h4#principles + %a.anchor{ href: "#principles", aria_hidden: "true" } + Panduan Dasar + + %ul + %li + Changelog dicatat untuk manusia, bukan mesin. + %li + Ada catatan untuk setiap versi. + %li + Perubahan dengan jenis yang sama dikelompokkan. + %li + Tercantum rujukan untuk versi dan seksi. + %li + Versi terbaru tercatat di bagian teratas. + %li + Tanggal rilis setiap versi tercatat. + %li + Sebutkan apakah anda mengikuti #{link_to "Semantic Versioning", data.links.semver}. + + %a.anchor{ href: "#types", aria_hidden: "true" } + %h4#types Types of changes + + %ul + %li + %code Added/Ditambahkan + untuk fitur baru. + %li + %code Changed/Diubah + untuk perubahan pada fitur yang sudah ada. + %li + %code Deprecated/Akan Dihilangkan + untuk fitur yang akan dihilangkan dalam waktu dekat. + %li + %code Removed/Dihilangkan + untuk fitur yang telah dihilangkan. + %li + %code Fixed/Diperbaiki + untuk perbaikan bugs. + %li + %code Security/Keamanan + jika ada kerentanan. + +.effort + + %h3#effort + %a.anchor{ href: "#effort", aria_hidden: "true" } + Bagaimana cara mempermudah pemeliharaan changelog? + + %p + Sediakan bagian Unreleased/Belum Dirilis di atas file changelog untuk mencatat perubahan yang akan datang. + + %p Manfaat bagian ini: + + %ul + %li + Kita dapat melihat perubahan yang akan datang. + %li + Bagian Unreleased/Belum Dirilis dapat dipindahkan ke catatan versi terbaru saat sudah rilis. +.bad-practices + %h3#bad-practices + %a.anchor{ href: "#bad-practices", aria_hidden: "true" } + Apakah changelog bisa menjadi tidak bermanfaat? + + %p Bisa. Berikut sedikit contoh bagaimana keberadaan changelog menjadi tidak membantu: + + %h4#log-diffs + %a.anchor{ href: "#log-diffs", aria_hidden: "true" } + Menggunakan pesan commit log diff seadanya + + %p + Pesan commit log diff (perbedaan sebuah file antar versi) merupakan catatan yang buruk untuk dijadikan changelog karena seringkali mereka tidak bermakna. Contohnya seperti merge commit, commit berjudul samar, perubahan dokumentasi, dan lainnya. + + %p + Tujuan pesan commit adalah mendokumentasikan sebuah tindakan dalam source code. Pesan ini bisa jadi tidak dirapikan. + %p + Tujuan sebuah catatan dalam changelog adalah mendokumentasikan perubahan-perubahan yang patut diperhatikan, dimana catatan ini seringkali merangkum perubahan serangkaian commit agar mudah dimengerti. + + %h4#ignoring-deprecations + %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } + Ignoring Deprecations + + %p + When people upgrade from one version to another, it should be + painfully clear when something will break. It should be possible to + upgrade to a version that lists deprecations, remove what's + deprecated, then upgrade to the version where the deprecations + become removals. + + %p + If you do nothing else, list deprecations, removals, and any + breaking changes in your changelog. + + + %h4#confusing-dates + %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } + Confusing Dates + + %p + Regional date formats vary throughout the world and it's often + difficult to find a human-friendly date format that feels intuitive + to everyone. The advantage of dates formatted like + 2017-07-17 is that they follow the order of largest to + smallest units: year, month, and day. This format also doesn't + overlap in ambiguous ways with other date formats, unlike some + regional formats that switch the position of month and day numbers. + These reasons, and the fact this date format is an + #{link_to "ISO standard", data.links.isodate}, are why it is the recommended date + format for changelog entries. + + %h4#inconsistent-changes + %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" } + Inconsistent Changes + + %p + A changelog which only mentions some of the changes can be as dangerous + as not having a changelog. While many of the changes may not be + relevant - for instance, removing a single whitespace may not need + to be recorded in all instances - any important changes should be + mentioned in the changelog. By inconsistently applying changes, + your users may mistakenly think that the changelog is the single source + of truth. It ought to be. With great power comes great responsibility - + having a good changelog means having a consistently updated changelog. + + %aside + There’s more. Help me collect these antipatterns by + = link_to "opening an issue", data.links.issue + or a pull request. + +.frequently-asked-questions + %h3#frequently-asked-questions + %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } + Frequently Asked Questions + + %h4#standard + %a.anchor{ href: "#standard", aria_hidden: "true" } + Is there a standard changelog format? + + %p + Not really. There's the #{link_to "GNU changelog style guide", data.links.gnustyle}, + or the #{link_to "two-paragraph-long GNU NEWS file", data.links.gnunews} + "guideline". Both are inadequate or insufficient. + + %p + This project aims to be + = link_to "a better changelog convention.", data.links.changelog + It comes from observing good practices in the open source + community and gathering them. + + %p + Healthy criticism, discussion and suggestions for improvements + = link_to "are welcome.", data.links.issue + + + %h4#filename + %a.anchor{ href: "#filename", aria_hidden: "true" } + What should the changelog file be named? + + %p + Call it CHANGELOG.md. Some projects use + HISTORY, NEWS or RELEASES. + + %p + While it's easy to think that the name of your changelog file + doesn't matter that much, why make it harder for your end users to + consistently find notable changes? + + %h4#github-releases + %a.anchor{ href: "#github-releases", aria_hidden: "true" } + What about GitHub Releases? + + %p + It's a great initiative. #{link_to "Releases", data.links.github_releases} can be used to + turn simple git tags (for example a tag named v1.0.0) + into rich release notes by manually adding release notes or it can + pull annotated git tag messages and turn them into notes. + + %p + GitHub Releases create a non-portable changelog that can only be + displayed to users within the context of GitHub. It's possible to + make them look very much like the Keep a Changelog format, but it + tends to be a bit more involved. + + %p + The current version of GitHub releases is also arguably not very + discoverable by end-users, unlike the typical uppercase files + (README, CONTRIBUTING, etc.). Another + minor issue is that the interface doesn't currently offer links to + commit logs between each release. + + %h4#automatic + %a.anchor{ href: "#automatic", aria_hidden: "true" } + Can changelogs be automatically parsed? + + %p + It’s difficult, because people follow wildly different formats and + file names. + + %p + #{link_to "Vandamme", data.links.vandamme} is a Ruby gem created by the + Gemnasium team and which parses many (but + not all) open source project changelogs. + + + %h4#yanked + %a.anchor{ href: "#yanked", aria_hidden: "true" } + What about yanked releases? + + %p + Yanked releases are versions that had to be pulled because of a + serious bug or security issue. Often these versions don't even + appear in change logs. They should. This is how you should display + them: + + %p ## [0.0.5] - 2014-12-13 [YANKED] + + %p + The [YANKED] tag is loud for a reason. It's important + for people to notice it. Since it's surrounded by brackets it's also + easier to parse programmatically. + + + %h4#rewrite + %a.anchor{ href: "#rewrite", aria_hidden: "true" } + Should you ever rewrite a changelog? + + %p + Sure. There are always good reasons to improve a changelog. I + regularly open pull requests to add missing releases to open source + projects with unmaintained changelogs. + + %p + It's also possible you may discover that you forgot to address a + breaking change in the notes for a version. It's obviously important + for you to update your changelog in this case. + + + %h4#contribute + %a.anchor{ href: "#contribute", aria_hidden: "true" } + How can I contribute? + + %p + This document is not the truth; it’s my carefully + considered opinion, along with information and examples I gathered. + + %p + This is because I want our community to reach a consensus. I believe + the discussion is as important as the end result. + + %p + So please #{link_to "pitch in", data.links.repo}. + +.press + %h3 Conversations + %p + I went on #{link_to "The Changelog podcast", data.links.thechangelog} + to talk about why maintainers and contributors should care about changelogs, + and also about the motivations behind this project. From 64e4a989af6022ee55c5de3497a61a367d2462c9 Mon Sep 17 00:00:00 2001 From: hkohko Date: Tue, 16 Apr 2024 22:51:16 +0700 Subject: [PATCH 2/5] translated up to right before FAQ --- source/id/1.1.0/index.html.haml | 39 +++++++++------------------------ 1 file changed, 10 insertions(+), 29 deletions(-) diff --git a/source/id/1.1.0/index.html.haml b/source/id/1.1.0/index.html.haml index f3df7f57..6d7cc045 100644 --- a/source/id/1.1.0/index.html.haml +++ b/source/id/1.1.0/index.html.haml @@ -122,14 +122,10 @@ version: 1.1.0 %h4#ignoring-deprecations %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } - Ignoring Deprecations + Mengabaikan Deprecations (fitur yang akan dihilangkan) %p - When people upgrade from one version to another, it should be - painfully clear when something will break. It should be possible to - upgrade to a version that lists deprecations, remove what's - deprecated, then upgrade to the version where the deprecations - become removals. + Jika ada perubahan yang tidak kompatibel dari satu versi ke versi lainnya, perubahan ini seharusnya teramat jelas bagi orang-orang. Saat kita menggunakan sebuah versi perangkat lunak yang di dalamnya terdapat fitur yang akan dihilangkan (Deprecated), seharusnya kita dapat menghilangkan fitur tersebut lalu melakukan upgrade ke versi dimana fitur tersebut sudah dihilangkan (Removed). %p If you do nothing else, list deprecations, removals, and any @@ -138,38 +134,23 @@ version: 1.1.0 %h4#confusing-dates %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } - Confusing Dates + Perbedaan Format Tanggal %p - Regional date formats vary throughout the world and it's often - difficult to find a human-friendly date format that feels intuitive - to everyone. The advantage of dates formatted like - 2017-07-17 is that they follow the order of largest to - smallest units: year, month, and day. This format also doesn't - overlap in ambiguous ways with other date formats, unlike some - regional formats that switch the position of month and day numbers. - These reasons, and the fact this date format is an - #{link_to "ISO standard", data.links.isodate}, are why it is the recommended date - format for changelog entries. + Mencari pola tanggal yang intuitif dan mudah dipahami oleh semua orang adalah masalah yang sulit. Hal ini karena pola tanggal di satu belahan bumi akan berbeda dengan belahan bumi lainnya. Tanggal yang disusun dalam pola 2017-07-17 memiliki keuntungan dimana pola tersebut dimulai dari unit terbesar: tahun, bulan, lalu hari. Format ini juga tidak tumpang tindih dengan format tanggal lainnya. Berbeda dengan format tanggal regional yang terkadang menukar posisi angka bulan dan tanggal. + Format tanggal ini direkomendasikan dalam catatan changelog bukan hanya karena alasan yang telah disebut, tetapi juga karena pola ini mengikuti #{link_to "ISO standard", data.links.isodate} untuk penulisan tanggal. %h4#inconsistent-changes %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" } - Inconsistent Changes + Pencatatan yang tidak konsisten %p - A changelog which only mentions some of the changes can be as dangerous - as not having a changelog. While many of the changes may not be - relevant - for instance, removing a single whitespace may not need - to be recorded in all instances - any important changes should be - mentioned in the changelog. By inconsistently applying changes, - your users may mistakenly think that the changelog is the single source - of truth. It ought to be. With great power comes great responsibility - - having a good changelog means having a consistently updated changelog. + Mencatat sebuah changelog yang tidak lengkap dengan tidak mencatatnya sama sekali adalah sama-sama berbahaya. Walau perubahan kecil - menghapus sebuah spasi misalnya - mungkin tidak perlu dicatat, semua perubahan penting yang patut diperhatikan harus disebut dan tercatat di changelog. Jika dilakukan setengah-setengah konsumen perangkat lunak anda akan berpikir mereka sedang membaca changelog yang benar, padahal kenyataannya adalah sebaliknya. Changelog seharusnya selalu benar. Changelog yang baik adalah changelog yang selalu diperbarui. Jika anda ingin memiliki changelog yang baik, inilah tanggung jawab anda. %aside - There’s more. Help me collect these antipatterns by - = link_to "opening an issue", data.links.issue - or a pull request. + Masih banyak contoh lainnya. Bantu saya mengumpulkannya dengan + = link_to "membuka sebuah issue", data.links.issue + atau pull request. .frequently-asked-questions %h3#frequently-asked-questions From 2ddff0b95113e732c29f976d3c13376b15d5d640 Mon Sep 17 00:00:00 2001 From: hkohko Date: Tue, 16 Apr 2024 23:33:15 +0700 Subject: [PATCH 3/5] translated part of FAQ. --- source/id/1.1.0/index.html.haml | 43 +++++++++++++-------------------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/source/id/1.1.0/index.html.haml b/source/id/1.1.0/index.html.haml index 6d7cc045..095f67c9 100644 --- a/source/id/1.1.0/index.html.haml +++ b/source/id/1.1.0/index.html.haml @@ -155,56 +155,47 @@ version: 1.1.0 .frequently-asked-questions %h3#frequently-asked-questions %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } - Frequently Asked Questions + Pertanyaan yang Sering Diajukan %h4#standard %a.anchor{ href: "#standard", aria_hidden: "true" } - Is there a standard changelog format? + Apakah ada format standar untuk sebuah changelog? %p - Not really. There's the #{link_to "GNU changelog style guide", data.links.gnustyle}, - or the #{link_to "two-paragraph-long GNU NEWS file", data.links.gnunews} - "guideline". Both are inadequate or insufficient. + Tidak, sih. Ada #{link_to "Panduan Ragam Penulisan Changelog GNU", data.links.gnustyle}, + atau "panduan" #{link_to "dua paragraf untuk GNU NEWS file", data.links.gnunews}. Tapi keduanya antara tidak mumpuni atau tidak lengkap. %p - This project aims to be - = link_to "a better changelog convention.", data.links.changelog - It comes from observing good practices in the open source - community and gathering them. - + Proyek ini ingin menghasilkan + = link_to "konvensi changelog yang lebih baik.", data.links.changelog + Hal-hal yang diutarakan merupakan sekumpulan pengamatan berbagai disiplin baik yang telah diadopsi oleh komunitas open source lain. + %p - Healthy criticism, discussion and suggestions for improvements - = link_to "are welcome.", data.links.issue + Kritik sehat, saran, dan diskusi untuk meningkatkan proyek ini + = link_to "dipersilakan.", data.links.issue %h4#filename %a.anchor{ href: "#filename", aria_hidden: "true" } - What should the changelog file be named? + Sebaiknya file changelog diberi nama apa? %p - Call it CHANGELOG.md. Some projects use + Sebut saja CHANGELOG.md. Beberapa proyek menyebutnya HISTORY, NEWS or RELEASES. %p - While it's easy to think that the name of your changelog file - doesn't matter that much, why make it harder for your end users to - consistently find notable changes? + Walau perihal nama ini sepertinya sepele, kenapa pengguna perangkat lunak anda yang mencari perubahan penting harus dibuat sulit? %h4#github-releases %a.anchor{ href: "#github-releases", aria_hidden: "true" } - What about GitHub Releases? + Bagaimana dengan GitHub Releases? %p - It's a great initiative. #{link_to "Releases", data.links.github_releases} can be used to - turn simple git tags (for example a tag named v1.0.0) - into rich release notes by manually adding release notes or it can - pull annotated git tag messages and turn them into notes. + Github Releases merupakan upaya yang baik. #{link_to "Releases", data.links.github_releases} dapat merubah git tag (contohnya sebuah tag dengan judul v1.0.0) + menjadi catatan rilis yang informatif dengan menambahkan catatan secara manual atau dengan memanfaatkan pesan-pesan git tag dan merubahnya menjadi catatan. %p - GitHub Releases create a non-portable changelog that can only be - displayed to users within the context of GitHub. It's possible to - make them look very much like the Keep a Changelog format, but it - tends to be a bit more involved. + Changelog yang dihasilkan oleh GitHub Releases bermanfaat hanya dalam konteks pengguna GitHub. Hasil catatannya dapat dibuat menyerupai format Pencatatan Changelog namun akan rumit. %p The current version of GitHub releases is also arguably not very From 9dbaf29f76e9beaed5135f3a2697991da5531287 Mon Sep 17 00:00:00 2001 From: hkohko Date: Wed, 17 Apr 2024 13:35:50 +0700 Subject: [PATCH 4/5] first pass translation complete --- source/id/1.1.0/index.html.haml | 53 ++++++++++----------------------- 1 file changed, 16 insertions(+), 37 deletions(-) diff --git a/source/id/1.1.0/index.html.haml b/source/id/1.1.0/index.html.haml index 095f67c9..94871b51 100644 --- a/source/id/1.1.0/index.html.haml +++ b/source/id/1.1.0/index.html.haml @@ -198,77 +198,56 @@ version: 1.1.0 Changelog yang dihasilkan oleh GitHub Releases bermanfaat hanya dalam konteks pengguna GitHub. Hasil catatannya dapat dibuat menyerupai format Pencatatan Changelog namun akan rumit. %p - The current version of GitHub releases is also arguably not very - discoverable by end-users, unlike the typical uppercase files - (README, CONTRIBUTING, etc.). Another - minor issue is that the interface doesn't currently offer links to - commit logs between each release. + GitHub releases yang sekarang tidak begitu mudah ditemukan oleh pengguna, berbeda dengan file-file (README, CONTRIBUTING, dll.). Tautan menuju commit log antar versi rilis juga tidak ditampilkan di antarmuka pengguna. %h4#automatic %a.anchor{ href: "#automatic", aria_hidden: "true" } - Can changelogs be automatically parsed? + Apakah changelog dapat diuraikan secara otomatis? %p - It’s difficult, because people follow wildly different formats and - file names. + Sulit, karena orang-orang mengikuti panduan format dan nama file yang berbeda-beda. %p - #{link_to "Vandamme", data.links.vandamme} is a Ruby gem created by the - Gemnasium team and which parses many (but - not all) open source project changelogs. + #{link_to "Vandamme", data.links.vandamme} adalah sebuah Ruby gem yang diciptakan oleh tim Gemnasium dan mampu menguraikan changelog proyek-proyek open source (tapi tidak semua). %h4#yanked %a.anchor{ href: "#yanked", aria_hidden: "true" } - What about yanked releases? + Bagaimana dengan rilis yang dibatalkan (YANKED)? %p - Yanked releases are versions that had to be pulled because of a - serious bug or security issue. Often these versions don't even - appear in change logs. They should. This is how you should display - them: + Rilis bertanda Yanked artinya versi tersebut ditarik karena adanya bug atau masalah kerentanan yang serius. Versi-versi ini harusnya dicatat. Tetapi seringkali tidak. Berikut cara mencatatnya: %p ## [0.0.5] - 2014-12-13 [YANKED] %p - The [YANKED] tag is loud for a reason. It's important - for people to notice it. Since it's surrounded by brackets it's also - easier to parse programmatically. + Tag [YANKED] ditulis sedemikian rupa. Hal ini karena orang-orang harus melihatnya. Selain huruf kapital, dengan menulisnya di dalam kurung siku akan mempermudah penguraian catatan ini secara programatis. %h4#rewrite %a.anchor{ href: "#rewrite", aria_hidden: "true" } - Should you ever rewrite a changelog? - + Bolehkah anda menulis ulang sebuah changelog? %p - Sure. There are always good reasons to improve a changelog. I - regularly open pull requests to add missing releases to open source - projects with unmaintained changelogs. + Boleh saja. sebuah changelog merupakan ide yang baik. Saya rutin membuat pull request to menambahkan versi-versi yang tidak tercatat dalam changelog proyek open source yang tidak dirapikan. %p - It's also possible you may discover that you forgot to address a - breaking change in the notes for a version. It's obviously important - for you to update your changelog in this case. + Memperbarui dan mencermati changelog itu penting. Apalagi jika anda lupa untuk mencatat perubahan yang tidak kompatibel pada versi tertentu. %h4#contribute %a.anchor{ href: "#contribute", aria_hidden: "true" } - How can I contribute? + Bagaimana saya dapat berkontribusi? %p - This document is not the truth; it’s my carefully - considered opinion, along with information and examples I gathered. + Dokumen ini bukanlah sesuatu yang mutlak; melainkan sebuah opini yang terbentuk setelah saya mempertimbangkan banyak hal, meliputi informasi dan contoh-contoh yang saya kumpulkan. %p - This is because I want our community to reach a consensus. I believe - the discussion is as important as the end result. + Saya ingin komunitas ini mencapai sebuah mufakat. Saya yakin diskusi ini penting untuk alasan tersebut. %p - So please #{link_to "pitch in", data.links.repo}. + Jadi, silahkan kirim #{link_to "saran", data.links.repo}. .press - %h3 Conversations + %h3 Percakapan %p - I went on #{link_to "The Changelog podcast", data.links.thechangelog} - to talk about why maintainers and contributors should care about changelogs, - and also about the motivations behind this project. + Saya berbicara tentang mengapa kontributor dan maintainer seharusnya mencermati changelog di #{link_to "The Changelog podcast", data.links.thechangelog}, disana saya juga berbicara tentang motivasi di belakang proyek ini. From bdc008f60210e9272c73a53fc4ae5b042836ad67 Mon Sep 17 00:00:00 2001 From: hkohko Date: Fri, 19 Apr 2024 19:23:16 +0700 Subject: [PATCH 5/5] minor fixes and tweak wordings --- source/id/1.1.0/index.html.haml | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/source/id/1.1.0/index.html.haml b/source/id/1.1.0/index.html.haml index 94871b51..85313f0e 100644 --- a/source/id/1.1.0/index.html.haml +++ b/source/id/1.1.0/index.html.haml @@ -63,7 +63,7 @@ version: 1.1.0 Sebutkan apakah anda mengikuti #{link_to "Semantic Versioning", data.links.semver}. %a.anchor{ href: "#types", aria_hidden: "true" } - %h4#types Types of changes + %h4#types Jenis Perubahan %ul %li @@ -104,7 +104,7 @@ version: 1.1.0 .bad-practices %h3#bad-practices %a.anchor{ href: "#bad-practices", aria_hidden: "true" } - Apakah changelog bisa menjadi tidak bermanfaat? + Apakah bisa changelog menjadi tidak bermanfaat? %p Bisa. Berikut sedikit contoh bagaimana keberadaan changelog menjadi tidak membantu: @@ -125,11 +125,10 @@ version: 1.1.0 Mengabaikan Deprecations (fitur yang akan dihilangkan) %p - Jika ada perubahan yang tidak kompatibel dari satu versi ke versi lainnya, perubahan ini seharusnya teramat jelas bagi orang-orang. Saat kita menggunakan sebuah versi perangkat lunak yang di dalamnya terdapat fitur yang akan dihilangkan (Deprecated), seharusnya kita dapat menghilangkan fitur tersebut lalu melakukan upgrade ke versi dimana fitur tersebut sudah dihilangkan (Removed). + Jika ada perubahan yang tidak kompatibel dari satu versi ke versi lainnya, perubahan ini seharusnya teramat jelas bagi orang-orang. Saat kita menggunakan sebuah versi perangkat lunak yang di dalamnya terdapat fitur yang akan dihilangkan (Deprecated), seharusnya kita dapat menghapus fitur tersebut lalu melakukan upgrade ke versi dimana fitur tersebut sudah dihilangkan (Removed). %p - If you do nothing else, list deprecations, removals, and any - breaking changes in your changelog. + Catat fitur yang akan dihapus, telah dihapus, dan perubahan tidak kompatibel pada changelog anda jika anda tidak mencoba hal tersebut. %h4#confusing-dates @@ -145,7 +144,7 @@ version: 1.1.0 Pencatatan yang tidak konsisten %p - Mencatat sebuah changelog yang tidak lengkap dengan tidak mencatatnya sama sekali adalah sama-sama berbahaya. Walau perubahan kecil - menghapus sebuah spasi misalnya - mungkin tidak perlu dicatat, semua perubahan penting yang patut diperhatikan harus disebut dan tercatat di changelog. Jika dilakukan setengah-setengah konsumen perangkat lunak anda akan berpikir mereka sedang membaca changelog yang benar, padahal kenyataannya adalah sebaliknya. Changelog seharusnya selalu benar. Changelog yang baik adalah changelog yang selalu diperbarui. Jika anda ingin memiliki changelog yang baik, inilah tanggung jawab anda. + Catatan changelog yang tidak lengkap sama bahayanya dengan tidak mencatatnya sama sekali. Walau perubahan kecil - menghapus sebuah spasi misalnya - mungkin tidak perlu dicatat, semua perubahan penting yang patut diperhatikan harus disebut dan tercatat di changelog. Jika dilakukan setengah-setengah konsumen perangkat lunak anda akan berpikir mereka sedang membaca changelog yang benar, padahal kenyataannya salah. Changelog seharusnya selalu benar. Changelog yang baik adalah changelog yang selalu diperbarui. Jika anda ingin memiliki changelog yang baik, inilah tanggung jawab anda. %aside Masih banyak contoh lainnya. Bantu saya mengumpulkannya dengan @@ -228,7 +227,7 @@ version: 1.1.0 %a.anchor{ href: "#rewrite", aria_hidden: "true" } Bolehkah anda menulis ulang sebuah changelog? %p - Boleh saja. sebuah changelog merupakan ide yang baik. Saya rutin membuat pull request to menambahkan versi-versi yang tidak tercatat dalam changelog proyek open source yang tidak dirapikan. + Boleh saja. Memperbarui sebuah changelog merupakan ide yang baik. Saya rutin membuat pull request untuk menambahkan versi-versi yang tidak tercatat dalam changelog proyek open source yang tidak dirapikan. %p Memperbarui dan mencermati changelog itu penting. Apalagi jika anda lupa untuk mencatat perubahan yang tidak kompatibel pada versi tertentu. @@ -242,7 +241,7 @@ version: 1.1.0 Dokumen ini bukanlah sesuatu yang mutlak; melainkan sebuah opini yang terbentuk setelah saya mempertimbangkan banyak hal, meliputi informasi dan contoh-contoh yang saya kumpulkan. %p - Saya ingin komunitas ini mencapai sebuah mufakat. Saya yakin diskusi ini penting untuk alasan tersebut. + Saya ingin komunitas ini mencapai sebuah mufakat. Saya yakin diskusi yang muncul untuk menghasilkan sebuah keputusan adalah sama pentingnya dengan keputusan tersebut. %p Jadi, silahkan kirim #{link_to "saran", data.links.repo}.