Merawat Open Source dari Indonesia: Pajak Zona Waktu UTC+7

Sebuah bug report untuk npm package saya masuk pukul 14:00 waktu New York. Di Jakarta itu pukul satu dini hari. Saya membacanya pada malam berikutnya, menanyakan versi yang mereka pakai, dan jawabannya datang saat saya sudah tidur lagi. Pekerjaan sebenarnya mungkin dua jam; wall clock-nya empat puluh empat jam.

Saya merawat hierarchical-approval, sebuah package TypeScript kecil untuk approval chain di ERP, dari UTC+7 sambil bekerja penuh waktu. Tulisan ini adalah prosedur kerja yang akhirnya saya pakai: berapa sebenarnya biaya jarak zona waktu, satu jam dalam sehari yang layak dipakai untuk triage, intake yang menahan laporan tak bisa ditindak sejak pintu masuk, pernyataan scope yang membuat penolakan cepat, dan pertanyaan soal funding yang ditanyakan setiap maintainer Indonesia tetapi hampir tidak pernah dijawab dengan sumber.

Bolak-balik dua jam berubah menjadi dua hari

Waktu Indonesia Barat adalah UTC+07:00 dan tidak ada wilayah Indonesia yang menerapkan daylight saving, dan itu punya konsekuensi yang jarang disebut: jarak antara Anda dan contributor berubah dua kali setahun karena jam mereka yang bergeser, bukan jam Anda. Terhadap pantai timur Amerika Serikat jaraknya sebelas atau dua belas jam tergantung bulan. Efek praktisnya, yang membuat maintenance terasa berat adalah latency, bukan besarnya usaha. Menjawab satu issue butuh sepuluh menit. Menutupnya butuh dua hari.

Baca kolom terakhir dari atas ke bawah dan temuannya langsung terlihat: satu malam menutupi Eropa dan pantai timur Amerika, dan sama sekali tidak pernah menutupi pantai barat. Jadi saya berhenti berusaha bisa dihubungi semua orang. Contributor di California mendapat jawaban pada malam berikutnya, dan README menyatakannya, bukan membiarkan mereka menyimpulkan sendiri dari timestamp.

Triage dalam satu jendela, dan pilih jamnya dengan benar

Jam yang menentukan adalah 21:00 WIB. Itu 14:00 UTC, yang jatuh pada 09:00 atau 10:00 di New York dan 15:00 atau 16:00 di Berlin, tergantung sisi mana dari pergantian daylight saving mereka. Balasan yang ditulis pada jam itu tiba di tengah jam kerja seseorang, bukan di dasar inbox esok pagi, sehingga langkah berikutnya terjadi pada hari yang sama. Triage sebelum berangkat kerja pukul 07:00 WIB terasa lebih disiplin dan justru lebih buruk: 07:00 WIB adalah tengah malam UTC, bukan jam kerja siapa pun.

# One pass, 21:00 WIB. That is 14:00 UTC, which is 09:00 or 10:00 in
# New York and 15:00 or 16:00 in Berlin, whichever side of their DST
# switch the year is on. My clock never moves, so theirs is the one
# that changes the gap twice a year.

# Oldest first: the oldest report has waited across the gap longest.
# gh issue list has no --sort flag; sorting is a search qualifier.
gh issue list --repo matthews-wong/hierarchical-approval \
  --state open --label needs-triage \
  --search "sort:created-asc" \
  --limit 20 \
  --json number,title,author,createdAt,comments

# The pile that is genuinely mine: I asked a question and nobody came back.
# Anything here is a candidate to close, not a debt I still owe.
gh issue list --repo matthews-wong/hierarchical-approval \
  --state open \
  --search "label:needs-info sort:updated-asc updated:<2026-09-08" \
  --json number,title,updatedAt

# Thirty minutes, then the laptop closes. The queue is not the job.

Satu pass terdiri dari dua query dan tiga puluh menit. Query pertama mengambil semua yang belum tersentuh, paling lama dulu, karena laporan paling lama itulah yang menunggu paling panjang melewati jarak waktu. Query kedua mengambil tumpukan yang sudah saya jawab tetapi tidak ada yang kembali, dan tumpukan itu adalah daftar untuk ditutup, bukan utang yang masih saya tanggung. Perhatikan bahwa gh issue list tidak punya flag sort sendiri; urutannya dititipkan di search query sebagai qualifier.

Tulis balasan yang mengakhiri thread

Kebiasaan dengan leverage terbesar yang saya punya adalah menolak bertanya satu per satu. Di dalam satu zona waktu, satu pertanyaan susulan berbiaya beberapa menit. Melewati sebelas jam, biayanya satu hari, dan tiga pertanyaan berurutan berbiaya tiga hari. Jadi setiap balasan saya tulis seolah-olah itu satu-satunya balasan yang boleh saya kirim.

• Tanyakan semuanya sekaligus — versi, runtime, snippet terkecil yang gagal, dan apa yang mereka harapkan terjadi — meskipun pertanyaan ketiga kemungkinan besar tidak akan terpakai.
• Jawab cabang-cabang yang mungkin di pesan yang sama: kalau ternyata penyebabnya yang satu, lakukan ini; kalau ternyata yang lain, itu limitasi yang sudah didokumentasikan dan ini bagian README yang menjelaskannya.
• Tutup dengan apa yang terjadi berikutnya dan kira-kira kapan, supaya contributor tidak perlu membuka thread kedua hanya untuk bertanya apakah masih ada orang di sana.

Saved replies menyimpan pertanyaan yang hampir setiap minggu saya ajukan. Yang paling layak ada di sana adalah permintaan reproduksi, karena teksnya cukup panjang sehingga kalau tidak disimpan saya akan menulis versi yang lebih pendek dan lebih buruk pada pukul setengah sebelas malam.

Buat laporan yang tidak bisa ditindak menjadi mustahil dikirim

Bolak-balik paling murah adalah yang tidak pernah terjadi, dan tempat mencegahnya ada di intake. Issue forms milik GitHub mengganti kotak teks bebas dengan sebuah schema: elemen markdown, input, textarea, dropdown, checkboxes, dan upload, masing-masing bisa diberi validasi required. Satu field versi yang wajib diisi saja sudah menghapus balasan pertama yang paling sering dulu saya tulis.

# .github/ISSUE_TEMPLATE/bug.yml
name: Bug report
description: The package does something the README says it should not
labels: ["needs-triage"]
body:
  - type: input
    id: version
    attributes:
      label: Package version
      description: The exact version from your lockfile, not "latest"
      placeholder: 3.3.0
    validations:
      required: true          # this one field kills half of all round trips

  - type: textarea
    id: repro
    attributes:
      label: Minimal reproduction
      description: The smallest snippet that fails, or a link to a repo
      render: typescript      # render is textarea-only in the form schema
    validations:
      required: true

  - type: dropdown
    id: runtime
    attributes:
      label: Runtime
      options: [Node 20, Node 22, Bun, Browser]
    validations:
      required: true

  - type: checkboxes
    id: prechecks
    attributes:
      label: Before filing
      options:
        - label: I searched the closed issues
          required: true
        - label: I read the Scope section of the README
          required: true

# .github/ISSUE_TEMPLATE/config.yml
# Blank issues are where unactionable reports come from. Turn them off and
# route the "how do I" traffic to Discussions, which nobody expects a
# same-day answer from.
blank_issues_enabled: false
contact_links:
  - name: Question about usage
    url: https://github.com/matthews-wong/hierarchical-approval/discussions
    about: Ask here. Issues are for reproducible defects only.

Dua detail lebih penting dari sisanya. Key render hanya berlaku untuk textarea di dalam form schema, dan mengisinya dengan typescript memberi Anda code block yang rapi alih-alih tembok teks tanpa indentasi. Lalu mematikan blank issue di config.yml adalah saklar yang benar-benar mengubah isi antrean, karena contact link di sebelahnya mengarahkan pertanyaan pemakaian ke Discussions, tempat yang tidak dianggap orang harus menjawab di hari yang sama.

Response window yang diumumkan lebih baik daripada yang cepat

Diam dibaca sebagai proyek yang ditinggalkan, dan dari UTC+7 Anda memproduksi banyak diam tanpa sengaja. Open Source Guides menyarankan mengatakan terus terang apa yang bisa diharapkan, dengan kalimat semacam balasan dari maintainer dalam tujuh hari dan silakan ping thread-nya setelah itu. Menulis versi saya sendiri dari kalimat itu di README mengubah nada issue tracker lebih besar daripada peningkatan kecepatan apa pun.

Window yang saya umumkan adalah tiga hari kerja, angka yang bisa saya penuhi pada minggu buruk, bukan minggu bagus. Itu seluruh triknya. Janji yang Anda tepati saat kondisi terburuk lebih bernilai daripada janji yang Anda tepati saat tidak ada hal lain terjadi, karena minggu yang merusak response time Anda justru minggu ketika seorang asing sedang membentuk penilaiannya terhadap proyek itu.

Funding, diperiksa dan bukan diasumsikan

GitHub Sponsors menerbitkan daftar region yang didukung dan Indonesia ada di dalamnya. Saya membuka halaman dokumentasinya pada 4 September 2026 dan membaca daftarnya, bukan mengulang isi thread forum tahun 2021, karena hanya dengan cara itu pertanyaan ini layak dijawab. Siapa pun dari region mana pun boleh menjadi sponsor, tetapi Anda harus berdomisili di region yang didukung untuk bisa menerima dana. GitHub tidak memungut biaya untuk sponsorship dari akun personal, dan sampai 6 persen untuk sponsorship dari akun organisasi.

Hanya bagian itu yang akan saya nyatakan sebagai fakta, karena itu bagian yang saya verifikasi. Open Collective adalah platform lain yang sering disebut, dan saya sengaja tidak menyatakan posisinya saat ini untuk individu Indonesia, karena saya tidak memeriksanya dengan standar yang sama. Periksa sendiri kelayakan Anda pada hari Anda mendaftar, termasuk mata uang apa saja yang benar-benar bisa diterima akun Anda. Daftar region yang ditulis di sebuah blog post, termasuk tulisan ini, hanyalah potret sesaat; platform menambah dan mencabut region tanpa memberi tahu siapa pun yang pernah menulisnya.

Tiga jawaban yang bisa diterima sebuah issue, dan scope yang menentukannya

Setiap issue di pass pertama mendapat salah satu dari tiga jawaban: tutup sekarang, ajukan satu putaran pertanyaan, atau terima. Mana yang didapat ditentukan oleh satu bagian README yang ditulis sebelum rilis pertama, bukan oleh perasaan saya pukul setengah sepuluh malam di hari Selasa. Open Source Guides merumuskannya lebih baik daripada saya — scope yang terdokumentasi memungkinkan Anda mengatakan kontribusi ini tidak sesuai kriteria proyek, bukan mengatakan Anda tidak menyukainya, dan perbedaan itulah alasan penolakan hanya butuh satu menit dan thread-nya tetap beradab.

## Scope

This package resolves an approval-chain definition into an ordered list of
approvers. That is the whole job.

### Non-goals

These are decisions, not gaps. A pull request implementing one of them will
be closed with a link to this section, politely and quickly:

- Notification delivery. No email, no WhatsApp, no push. Bring a transport.
- A UI. There is no React component here and there will not be one.
- Persistence. The library never opens a database connection.
- Framework adapters beyond the two that exist. The wrapper is 40 lines.

### Response time

I read issues once a day, in the evening, UTC+7. Expect a first reply within
three working days. If a week goes by in silence, ping the thread. You are
not being ignored and the project is not abandoned. It has one maintainer
and he has a day job.

Daftar non-goals adalah bagian yang paling sering dilewati dan justru bagian yang bekerja. Menerima fitur yang tidak pernah Anda pakai sendiri adalah persis cara sebuah package kecil menjadi tidak terawat: Anda kini memiliki kode yang tidak bisa diuji terhadap workload nyata, di zona waktu yang membuat setiap pertanyaan tentangnya berbiaya satu hari. Saya lebih memilih merilis package yang melakukan satu hal dan di-fork oleh siapa pun yang butuh hal kedua.

Apa yang sebenarnya kembali

Bukan uang, dalam kasus saya, dan saya lebih memilih mengatakannya terang-terangan daripada memberi kesan sebaliknya. Yang kembali adalah portofolio yang bisa diverifikasi orang asing tanpa perlu mempercayai apa pun yang saya katakan tentang diri saya: sebuah repository dengan riwayat commit yang terbaca, issue yang dijawab di depan umum, dan penolakan yang ditulis cukup sopan sehingga thread-nya masih layak dibaca bertahun-tahun kemudian. Itu jauh lebih sulit dipalsukan daripada satu baris di CV, dan jangkauannya lebih jauh.

Hasil kedua adalah disiplin review. Membaca kode orang lain pukul sembilan malam, tanpa konteks yang mereka punya dan tanpa bisa menepuk bahunya, mengajarkan Anda persis apa yang harus dimuat sebuah pull request agar bisa direview — dan saya menulis pull request di day job dengan cara berbeda karena itu. Itu transfer skill yang nyata dan itulah argumen jujur untuk mengerjakan semua ini. Pekerjaan tanpa bayaran tidak menjadi baik hanya karena ia open source; ia layak dikerjakan ketika mengajarkan sesuatu yang tidak diajarkan pekerjaan berbayar.

Aturan yang akan saya berikan kepada diri saya yang dulu itu pendek. Tentukan apa yang tidak akan pernah dilakukan package ini sebelum menentukan apa yang akan dilakukannya. Umumkan response time yang bisa Anda penuhi pada minggu terburuk, bukan terbaik. Letakkan satu jendela triage Anda pada jam yang jatuh di dalam jam kerja orang lain. Semua hal lain tentang merawat proyek dari UTC+7 adalah turunan dari tiga keputusan itu, dan tidak satu pun berbiaya apa pun selain disiplin untuk mengambilnya lebih awal.