> And what if someone else later joins as an ASF committer with the id 'doejohn'? What would their badge page be?
That particular badging username would be unavailable and they would have to select another handle for their badging page when registering as committer (if they opt-in to the badging system), since they inhabit different namespaces. Is this a problem? I am hoping that a contributor would already have selected its badging ID before it became a committer, so it would use that as an “external identifier” to authenticate its contributions with external parties, while the ASF ID is more of an “internal” identifier so they serve different purposes. It would be ideal if badging ID and ASF ids are congruent, but is it really a problem if they’re not? I admit this is not ideal, but it’s not the end of the world either. What would matter for the badging system is only the badging system id, and it would be technically orthogonal to the ASF id. The page badges.apache.org would have a field to indicate the ASF id of that badge holder, which can be in some situations a different handle since they represent different things. Current ASF IDs user would have the right for their username in the badging system since new users would not be allowed to use existing ASF IDs as badge handle. On Wed, 20 Mar 2024 at 14:23 sebb <seb...@gmail.com> wrote: > 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 > >
