On Wed, 20 Mar 2024 at 15:59, Paulo Motta <pa...@apache.org> wrote: > > 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.
And what if someone else later joins as an ASF committer with the id 'doejohn'? What would their badge page be? > 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? It does not solve the fundamental issue. The only way to solve it is to ensure that the bare ids inhabit a different namespace from the ASF ids. For example, badge ids could use Greek letters. This is not a serious solution, but is a way to illustrate what I mean about disjoint namespaces. > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
