What this task actually controls
On GitHub, an organization membership can be visible on your profile or hidden from it. The choice belongs to you as a member, not to the organization’s owner. Two reviewed facts frame the task: an organization member can set individual organization membership visibility to Public or Private, and the control sits in the organization People list next to the member username.
GitHub allows an organization member to set individual organization membership visibility to Public or Private. Source
The organization People list provides the visibility control next to the member username. Source
That is the whole mechanical surface. Everything else is judgment: which logos you want a stranger to see, what those logos imply, and how often you recheck the result. Hiding a membership is not the same as deleting your contributions, and the absence of a public membership does not prove someone is not employed by or affiliated with an organization. Treat public membership as an exposure decision, not a résumé line.
A public organization logo is a matching identifier. It sits next to your handle, your avatar and your bio, and anyone can screenshot it. It does not by itself establish employment, seniority or current status. If you want to make an employment claim, that belongs in prose you control, not in an inferred logo.
Step 1 — Build the membership inventory
Before changing anything, list every organization you belong to and what you currently show. Do this from your own account while signed in, using the organization People list as the reference point named in the reviewed facts. Do not rely on memory; memberships accumulate quietly through contributions, forks and invitations.
For each membership, record four things: the organization name, whether the logo currently appears on your profile, whether you intend it to appear, and the date you last checked. Keep this in a private note — not a public gist.
| Organization | Currently public? | Intended audience | Decision | Recheck date |
|---|---|---|---|---|
| Example: current employer | Yes | Recruiters, peers | Keep public | Quarterly |
| Example: client project | Yes | Client only | Make private | At project end |
| Example: open-source community | No | General public | Keep private | Quarterly |
| Example: former employer | Yes | Nobody | Make private | Now |
| Example: side project | No | Collaborators | Keep private | On change |
Fill the table with your real memberships. The point is to convert a vague feeling of “my profile looks fine” into explicit intent per organization.
Step 2 — Decide public intent per membership
Not every membership deserves the same treatment. A useful split:
- Identity-bearing memberships — organizations you would name in a professional introduction. These are the candidates for public visibility.
- Transactional memberships — client work, temporary collaborations, package maintenance. Public visibility here often leaks more than it signals.
- Incidental memberships — organizations you joined to file an issue or attend one event. These rarely need a public logo.
- Stale memberships — organizations you no longer work with. A public logo here can misrepresent current status even if you never intended it to.
Write one sentence of intent per organization before touching settings. “I want this logo public because I contribute to this project and want collaborators to find me” is intent. “It was already on” is not.
Step 3 — Apply visibility with the reviewed control
The reviewed facts establish that the visibility control is in the organization People list, next to the member username, and that the member sets it. Use that control per organization. Do not assume a single global switch exists, and do not assume the organization owner can see or override your choice — the reviewed facts do not say either way.
After each change, reload your public profile in a logged-out browser or private window. The signed-in view can differ from what strangers see. Record the observed result in your table, not the result you expected.
Step 4 — Separate membership from employment
This is where most confusion happens. A public membership is a matching identifier: it links a handle to an organization. It is not a statement of employment, and its absence is not a statement of non-employment. People work with organizations without joining them on GitHub, and people remain members long after a role ends.
If your goal is to be found by recruiters, the membership logo is a weak signal on its own. Prose you write — in your bio or a pinned repository — carries the claim you actually mean. If your goal is privacy, remember that hiding a membership does not remove your commits, issues or pull requests from the organizations where you contributed. The reviewed facts cover visibility of membership, not deletion of activity.
A public membership can also be misread. A reader who sees an organization logo may assume a current role, a seniority level or an endorsement that the logo does not carry. That is a reader error, but it is your exposure. Decide whether you want to carry that ambiguity.
Common mistakes
- Treating the logo as a CV line. A public membership is not an employment claim. If you want the claim, write it.
- Assuming private means invisible everywhere. Hiding membership visibility does not erase contributions, and it does not stop people who already saw the logo from remembering it.
- Assuming absence proves distance. A person with no public organization membership may still be employed by that organization; the setting is a choice, not a fact.
- Changing settings without a logged-out check. The signed-in profile is not the public profile. Verify from outside.
- Skipping stale memberships. Former employers and finished client projects are the most common source of misleading logos.
- Confusing matching identifiers with identity. A handle, avatar or organization logo that matches across platforms is a lead, not proof that two accounts belong to the same person. The same applies to your own profile when someone else reads it.
- Forgetting that a membership can be inferred from activity. Even with private visibility, public contributions can reveal an affiliation. Decide with that in mind.
Rechecking and protecting your own footprint
Set a recurring recheck — quarterly is a reasonable default for most people, and immediately after any role change. At each recheck, open your public profile logged out, compare it with your table, and update the recheck date. If an organization you left still appears, revisit its entry in the People list.
Public identifiers are leads, not proof. That applies to how others read your profile and to how you read anyone else’s. If you are reviewing your own footprint beyond GitHub, a username search can surface where your known handles appear publicly. TraceSeek covers 3,000+ platforms, and the first scan is free without registration or login; the product describes a scan time of 20-30 seconds. TraceSeek does not change platform settings, guarantee a match or verify identity — it shows public matches you then interpret yourself. For how those matches should and should not be read, see the methodology page and the existing guide on what public profile search can and cannot reveal about a person.
Key facts
- GitHub allows an organization member to set individual organization membership visibility to Public or Private.
- The organization People list provides the visibility control next to the member username.
- A public organization membership is a deliberate exposure choice, not an employment claim.
- Hiding membership visibility does not delete contributions, and absent membership does not prove non-employment.
- Matching public identifiers across platforms are leads, not proof that accounts belong to the same person.