Skip to content

Improved repository label terminology (private -> personal)#156

Open
gwku wants to merge 1 commit intoRayLabsHQ:mainfrom
gwku:ui/improve-repository-label-terminology
Open

Improved repository label terminology (private -> personal)#156
gwku wants to merge 1 commit intoRayLabsHQ:mainfrom
gwku:ui/improve-repository-label-terminology

Conversation

@gwku
Copy link

@gwku gwku commented Nov 26, 2025

The current label "Include private repositories" is confusing because it can be misinterpreted as referring to repository visibility (public vs private repositories), when it actually refers to repository ownership (personal repositories owned by the user vs organization repositories).

Changed 'private repositories' to 'personal repositories' for better clarity in GitHub mirror settings.

Change 'private repositories' to 'personal repositories' for better clarity in GitHub mirror settings
@arunavo4
Copy link
Collaborator

@gwku Thanks for opening this and for thinking about the wording.

Quick background from my side: in this project “private repositories” is meant in the GitHub visibility sense (private vs public), not in the ownership sense (personal vs organization).

A few concrete points from the current implementation:

  • The env vars and docs use it as a visibility flag. PRIVATE_REPOSITORIES is documented as “Include private repositories”, next to PUBLIC_REPOSITORIES
    (docs/ENVIRONMENT_VARIABLES.md and src/pages/docs/configuration.astro).
  • In code, I map GitHub’s repo.private field to isPrivate (src/lib/github.ts), and the config schema has includePrivate and includePublic plus an
    isPrivate flag on each repo (src/lib/db/schema.ts).
  • The mirror logic checks repository.isPrivate when building the clone URL and when creating the repo in Gitea, so it really is about private vs public
    visibility (src/lib/mirror-sync-fix.test.ts, src/lib/gitea.ts).

Ownership (personal vs organization) is handled separately:

  • GITHUB_TYPE (personal or organization) and mirrorStrategy (preserve, single-org, flat-user, mixed) control whether a repo is treated as personal or org-
    owned and where it ends up in Gitea (src/lib/env-config-loader.ts, src/lib/gitea.ts, src/components/config/OrganizationConfiguration.tsx).

Because of that, changing the label to “personal repositories” would not match what the flag actually does. It would suggest “personal vs org” while the
code is filtering on “private vs public”.

I am definitely open to making the label clearer though. Something like this might be a better direction:

  • Label: “Include private repositories”
  • Helper text: “Include private (non public) repositories in mirroring”

That keeps it aligned with the existing config and GitHub terminology, but hopefully reduces the chance that people read it as “personal vs organization”.

@arunavo4 arunavo4 self-assigned this Nov 27, 2025
@gwku
Copy link
Author

gwku commented Dec 2, 2025

@arunavo4 Thanks for the detailed explanation. That context helps.

The reason I suggested the wording change is that in my testing, the behavior did not line up with the visibility-based interpretation.

  • When I enabled "private repositories", all of my personal repositories (owned by my user account) were mirrored, regardless of their visibility.
  • When I disabled it, my personal repositories were not mirrored at all.
  • During the same tests, private-visibility repositories from organizations were mirrored correctly even with the option disabled.

Because of this, the current label feels misleading from a user experience perspective. The toggle effectively controlled personal versus organization repositories for me, not private versus public repositories.

So while I understand the intended meaning in the code, the behavior I observed matches ownership semantics rather than visibility semantics, which is what prompted the wording suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants