Skip to content

fix(members): restore Ameer Hamza's handle pending verification - #2

Merged
amaanx86 merged 1 commit into
mainfrom
feature/register-update-label
Aug 11, 2026
Merged

fix(members): restore Ameer Hamza's handle pending verification#2
amaanx86 merged 1 commit into
mainfrom
feature/register-update-label

Conversation

@amaanx86

Copy link
Copy Markdown
Member

What this changes

Restores github: ameerhamza3463 in members/organizers.yaml, reverting the one-line register edit that rode along in 17886ac.

Why

The rename to ameerhamza-io reached main without anyone running the verification step, inside a commit whose subject is about adding a label. A correction to the register should not land as a side effect of a docs change, and it should not land unverified.

This is a hold, not a judgement about which handle is correct. The check is now written down in members/README.md: GitHub attributes past activity by account rather than by name, so the founding nomination at cncf/communitygroups#761 should already display the new handle. Confirming that takes one page load. Once it is done, the rename comes back as its own pull request carrying the register-update label, and moves github together with the openprofile slug on line 28, which still reads ameerhamza3463 and needs opening to check whether the Linux Foundation slug followed the rename.

Worth stating plainly that neither state is risk-free while this is open. GitHub releases a username the moment its owner renames, and anyone may claim it, so a register entry pointing at a freed handle can end up naming a stranger as an organizer. Reverting restores a handle that may now be claimable; leaving it kept a handle nobody had verified. The revert wins only because it returns the file to a value an organizer once checked, and because the verification that settles it is cheap.

uv run scripts/validate_members.py passes. The pre-existing shared-employer warning is unrelated and unchanged.

…ster

Nothing in the label set covered a change to an entry that already
exists, so a renamed GitHub handle, a new LinkedIn URL or a changed
employer had neither a label nor a documented path. Add the label, a
row in the contributing entry-point table, and a section in
members/README.md.

No issue template: the change is a one-line pull request with no
evidence and no sponsorship to review, so a form in front of it would
add a round trip and decide nothing.

A renamed GitHub handle is the urgent case. GitHub releases the old
name on rename and anyone may claim it, so a stale entry can end up
naming a stranger as an organizer. The reviewer check is that the
issue in the entry's `request` field now shows the new handle, since
GitHub attributes past activity by account rather than by name.
@amaanx86
amaanx86 requested a review from a team as a code owner August 11, 2026 06:17
@amaanx86 amaanx86 self-assigned this Aug 11, 2026
@amaanx86 amaanx86 added the governance Changes a rule under governance/. Two thirds of organizers, 7-day comment period. label Aug 11, 2026
@amaanx86
amaanx86 merged commit 4f42432 into main Aug 11, 2026
2 checks passed
@amaanx86
amaanx86 deleted the feature/register-update-label branch August 11, 2026 06:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

governance Changes a rule under governance/. Two thirds of organizers, 7-day comment period.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants