How this account uses GitHub

This account (bryanunitek) belongs to a single individual, Bryan Fred, operating as Unitek Systems Limited. This note explains, in plain terms, how the account is used — so that GitHub, collaborators, and anyone reviewing the work can see exactly what is going on and advise if anything should change.

One human, one account

• I am one person and I maintain one personal GitHub account.
• I work on several projects at the same time under that one account. Working on many projects is a normal, everyday use of a single account — the number of projects is unrelated to the number of accounts.
• The account hosts my own open-source work: the UniCORE foundation, a set of public repositories released under the Creative Commons CC BY 4.0 licence, alongside my private working repositories for the same projects.

If a second person were ever involved in the work, they would use their own separate GitHub account under their own identity. Accounts are per-person and are never shared.

Public and private repositories

• The public repositories are the gift-layer: freely licensed (CC BY 4.0), openly readable, intended to be shared and built upon.
• The private repositories are the working and commercial code for the same projects.
• I keep these two clearly separated and do not mix private material into public repositories.

Automation

I run scheduled maintenance automation against repositories I own and control. It performs routine housekeeping — chiefly keeping my own public repositories in sync with their upstream sources (fork-sync / upstream-merge). This automation:

• runs on a schedule, against my own repositories;
• does not scrape other users' data, target third-party accounts, or interact with anything outside my own projects;
• authenticates as me — the various per-project tools I use all push to this one account; they are tooling, not separate GitHub users.

If GitHub would prefer scheduled automation to run under a dedicated machine account rather than my personal account, I am happy to set that up, and/or to space the jobs out so they do not run in bursts.

Credentials and safety

• I never commit secrets (keys, tokens, passwords) to any repository.
• I use scoped, least-privilege access tokens and rotate them.
• I keep GitHub's secret-scanning and push-protection enabled, and treat any alert as something to verify rather than dismiss.

Feedback welcome

If any of the above suggests a change I should make — whether to the practice itself or simply how I describe it — please let me know. I would rather adjust proactively than trip an automated threshold.

— Bryan Fred, Unitek Systems Limited