This is fair Sebb. I concede a separate namespace makes sense. This would also likely simplify the solution so we don't need to worry about clashes.
Instead of overloading people.apache.org namespace which is associated with an ASF ID, I think it makes more sense to create a separate namespace instead, like contributors.apache.org/doejohn or badges.apache.org/doejohn . If the "doejohn" ASF ID handle is taken when the contributor "doejohn" becomes a committer, then it can just use something else as an ASF ID like "doejohn99" and call it a day. In order to avoid contributors taking up existing ASF ID handles in the badging system which could create confusion, I think we would need to check if an ASF ID does not exist when creating the badging handle. Does this make sense? On Wed, Mar 20, 2024 at 11:14 AM sebb <seb...@gmail.com> wrote: > On Wed, 20 Mar 2024 at 14:02, Paulo Motta <pa...@apache.org> wrote: > > > > The ID reservation for 1 year is an optimistic "vote of confidence" that > > the contributor will remain active in the community and eventually > become a > > committer. > > There are already issues with 3rd party Wiki and Jira ids. > Let's not add another source of id clashes. > > I suggest using an id syntax that is not valid for ASF ids, then there > is no need to worry about clashes. > Yes, if a badge holder becomes an ASF committer they will have to > select a new id, but there could easily be a redirect from the old > badge page to the new one. > > Otherwise, not only will the badge ids have to be checked against ASF > ids, and Jira and Wiki, but those will also need to be checked against > badge ids. > > > Existing committers can enter a "waiting list" for reserved handles. If > the > > reserved handle owner is no longer active after 1 year, the handle is > > assigned to the first committer in the waiting list for that particular > > handle. > > > > On Wed, Mar 20, 2024 at 9:51 AM Paulo Motta <pa...@apache.org> wrote: > > > > > Also we would need to have a way to detect malicious agents doing bogus > > > contributions to reserve handles. This is a separate issue that I would > > > prefer to keep out of this discussion for now. > > > > > > On Wed, 20 Mar 2024 at 10:47 Paulo Motta <pa...@apache.org> wrote: > > > > > >> One question that could come up is: > > >> > > >> * what if someone does a single commit, and the ID is reserved and > > >> blocked for posterity > > >> > > >> We could add a 1 year TTL where the contributor would need to do > another > > >> commit within the next year to continue reserving the ID. This would > > >> incentivize people with reserved IDs to keep doing contributions to > keep > > >> their reserved handles. > > >> > > >> On Wed, 20 Mar 2024 at 10:36 Paulo Motta <pa...@apache.org> wrote: > > >> > > >>> > Imagine you've been granted committer privileges but you can't pick > > >>> the ID you want because it has been "reserved" by a non-committer, > > >>> > > >>> This can not possibly happen, because the committer that was granted > > >>> committer privileges has already reserved its own ID when it became a > > >>> contributor in its first commit to any apache project. :) > > >>> > > >>> On Wed, Mar 20, 2024 at 9:25 AM Gary Gregory <garydgreg...@gmail.com > > > > >>> wrote: > > >>> > > >>>> I don't think we should allow IDs to be "reserved": Imagine you've > > >>>> been granted committer privileges but you can't pick the ID you want > > >>>> because it has been "reserved" by a non-committer, it seems > backward. > > >>>> > > >>>> Gary > > >>>> > > >>>> On Wed, Mar 20, 2024 at 8:37 AM Paulo Motta <pa...@apache.org> > wrote: > > >>>> > > > >>>> > This is right Claude. Essentially, the people.apache.org handle > can > > >>>> be seen > > >>>> > as a “handle reservation” to a future ASF ID handle, that will be > > >>>> granted > > >>>> > when the contributor becomes a committee. > > >>>> > > > >>>> > So it’s basically a pre-ASF ID handle granted to contributors > without > > >>>> any > > >>>> > privileges or login (except the people.apache.org auto-generated > > >>>> > contributor page). > > >>>> > > > >>>> > On Wed, 20 Mar 2024 at 09:19 Claude Warren <cla...@xenei.com> > wrote: > > >>>> > > > >>>> > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta <pa...@apache.org> > > >>>> wrote: > > >>>> > > > > >>>> > > > > > >>>> > > > 3. John Doe fills a simple form and selects the username > > >>>> "doejohn", which > > >>>> > > > is not an ASF id, but just a handle to a people.apache.org > page. > > >>>> If an > > >>>> > > ASF > > >>>> > > > id exists with the same name, then the request is rejected. > > >>>> > > > 6. After some years of contributions, John Doe is invited to > be a > > >>>> > > committer > > >>>> > > > of Apache Foo. > > >>>> > > > a. John can "convert" its username "doejohn" into an ASF > ID, or > > >>>> can > > >>>> > > > choose another ASF ID handle when becoming a committer. > > >>>> > > > b. This kicks-off an update to people.apache.org/~doejohn > to > > >>>> change > > >>>> > > the > > >>>> > > > role from "ASF Contributor" to "Committer at Apache Foo" > > >>>> > > > > > >>>> > > > > > >>>> > > The above 2 points indicate that our new committer registration > > >>>> would > > >>>> > > require that no handles used on people.apache.org be granted > as an > > >>>> ASF id. > > >>>> > > Seems like we need a way to track the union of ASF Id and > > >>>> > > people.apache.org > > >>>> > > handles. > > >>>> > > > > >>>> > > > > >>>> > > -- > > >>>> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > >>>> > > > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > >>>> For additional commands, e-mail: dev-h...@community.apache.org > > >>>> > > >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
