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

.github/labels.yml

@@ -31,6 +31,10 @@ labels:
     color: 1d76db
     description: New SIG, or a lifecycle change to one. Applied by the issue form.
 
+  - name: register-update
+    color: c2e0c6
+    description: Corrects an existing entry in members/. A changed handle is urgent; see members/README.md#changing-your-own-entry.
+
   - name: event
     color: fbca04
     description: Meetup planning issue or retro. Retros are the evidence source for contribution units.

CONTRIBUTING.md

@@ -14,6 +14,7 @@ Most things start as an issue, because evidence and sponsorships get reviewed be
 | Speaking at a meetup | A [talk proposal](https://github.com/cloud-native-karachi/community/issues/new?template=talk-proposal.yml) |
 | Starting a SIG | A [SIG proposal](https://github.com/cloud-native-karachi/community/issues/new?template=sig-proposal.yml) |
 | Becoming an organizer | Talk to an organizer. See [governance/organizers.md](governance/organizers.md) |
+| Your handle, LinkedIn or employer changed | Straight to a pull request. See [members/README.md](members/README.md#changing-your-own-entry) |
 | Typo, dead link, unclear sentence | Straight to a pull request |
 | Changing a rule | A pull request against `governance/`, with the rationale |
 
@@ -68,7 +69,7 @@ Counts and dates stay in the register. Write "the organizers listed in [organize
 
 ## Labels
 
-Nine, each with what it means in [.github/labels.yml](.github/labels.yml). The issue forms apply four of them for you; organizers add the rest.
+Ten, each with what it means in [.github/labels.yml](.github/labels.yml). The issue forms apply four of them for you; organizers add the rest.
 
 The one that concerns you is `needs-info`. It means the request is waiting on you rather than on a reviewer, and the comment says what would close it. It is not a rejection.
 

members/README.md

@@ -79,3 +79,11 @@ Warnings are decisions for a human, so they print rather than block. Ignoring th
 ## Adding yourself
 
 Not by pull request as a first step. Open a [membership request](https://github.com/cloud-native-karachi/community/issues/new?template=membership-request.yml) so evidence and sponsorships are reviewed first. Full sequence: [../governance/membership.md](../governance/membership.md#how-to-apply).
+
+## Changing your own entry
+
+Once you are listed, a stale `github`, `linkedin`, `org` or `sigs` value is a pull request against your own line, not a new request issue. There is no evidence and no sponsorship to review, so an issue would add a round trip and decide nothing. Say in the description which field changed and why. An organizer adds `register-update` and merges on one approval, the same threshold as a typo. The same path covers an entry in [emeritus.yaml](emeritus.yaml), where nobody is watching the handle at all.
+
+A changed GitHub handle is the urgent one. GitHub releases your old handle the moment you rename it, and anyone may then claim it. Until the register catches up it points at an account you no longer control, and once someone else takes that name the register lists a stranger as a Member or an organizer. Open the pull request the day you rename, and expect a reviewer to treat it ahead of the queue.
+
+Reviewing a handle change, do not merge on the pull request author alone; anyone can open a pull request claiming a rename happened. GitHub attributes past activity by account rather than by name, so the issue in the entry's `request` field, and any other issue or pull request that person has opened here, already shows the new handle. That match is the check. Where there is no such issue, which is the case for the founding organizers whose nomination sits in [cncf/communitygroups#761](https://github.com/cncf/communitygroups/issues/761), confirm over CNCF Slack or against the `openprofile` URL already in the entry.