Skip to content
View YongDo-Hyun's full-sized avatar
  • 16:19 (UTC +03:00)

Organizations

@Project-Tick

Block or report YongDo-Hyun

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Maximum 250 characters. Please don't include any personal information such as legal names or email addresses. Markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
YongDo-Hyun/README.md

YongDo-Hyun

I’m an independent open-source developer building large-scale, long-lived software with a strong bias toward correctness, clear architecture, and reproducible delivery. I optimize for maintainability and operational clarity, not short-term velocity.

Focus Areas

  • C++ application and library development
  • Qt 6 / QML UI architecture and tooling
  • Build systems and reproducible builds (including Nix)
  • Packaging and distribution (Flatpak, Debian)
  • CI/CD, release automation, and infrastructure (GitHub Actions)
  • Git workflows, code review, and repository hygiene

Development Philosophy

  • Correctness is a feature: I prefer explicit invariants, strong types, and defensive interfaces.
  • Architecture over accumulation: I design for change, testability, and clear boundaries.
  • Reproducibility matters: builds and releases must be deterministic and auditable.
  • Small, reviewable steps: incremental changes with clear intent beat large refactors without proof.
  • Compatibility is deliberate: deprecations and breaking changes need a plan and documentation.

Expectations From Contributors and Users

  • Report issues with concrete data: versions, logs, minimal reproduction steps, and expected vs actual behavior.
  • Keep changes scoped: one problem per pull request, with a clear rationale and tests where it matters.
  • Follow existing conventions: style, structure, and project constraints are not optional.
  • Avoid speculative changes: “might be useful” patches are usually noise unless there is a real use case.
  • Be prepared to iterate: review feedback is part of engineering, not negotiation.

Communication and Issues

I communicate directly and expect the same in return. Use issues for actionable, technical discussion. If you’re unsure whether something is a bug or a question, provide the facts you have and a minimal example; I will tell you what I need next. I will close threads that are vague, off-topic, or require unpaid consulting to define.

Pinned Loading

  1. Project-Tick/ProjT-Launcher Project-Tick/ProjT-Launcher Public

    A custom launcher for Minecraft that allows you to easily manage multiple installations of Minecraft at once (Fork of PrismLauncher)

    C++ 7 2

  2. install-scripts install-scripts Public

    Shell

  3. Signup Signup Public

    Forked from EpicGames/Signup

    Information about signing up for a free Epic Games account, and getting access to UnrealEngine source code.

  4. NixOS-Config NixOS-Config Public

    My NixOS Configuration

    Shell