Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

Thanks for the additional context Rich. I might have derailed a bit since I
was looking to improve the onboarding of new contributors (without ASF ID)
into the apache ecosystem, which IMO has some intersection with the badging
system, but it's definitely not the same thing.

I'll sleep on this, do some homework and get back to this later. Stay
tuned! :)

In the meantime anyone else feel free to take up the original questions
posed by Rich in the beginning of the thread so we get back on topic.

On Wed, Mar 20, 2024 at 3:25 PM Rich Bowen  wrote:

>
> > On Mar 20, 2024, at 11:59 AM, Paulo Motta  wrote:
> >
> > Rich:
> >
> > I need some time to better elaborate this. I will prepare sometime in the
> > next week or so a short doc explaining what am I proposing, what problem
> it
> > solves and how it intersects with the badging tool object of this working
> > group.
> >
> > I suspect we might be thinking about similar things but in different
> terms,
> > right now I’m just doing unstructured brainstorming.
> >
> > On the meantime, can you briefly describe what problem are you trying to
> > solve with this badging system, and what do you expect from it to ensure
> > we’re talking about the same things? If this is already described
> somewhere
> > please let me know and I will use it to check if this intersects with the
> > proposal I have in mind.
>
> The purpose of badging is discussed here:
> https://github.com/apache/comdev-working-groups/tree/main/wg-badging
>
> In brief, it’s to celebrate and gamify moments in individuals’ community
> journey. It’s a way for people to brag/celebrate/display their
> accomplishments, since this is something that has been shown to motivate
> not only participation, but for people to expand outside of their usual
> habitual sphere of participation and try other things.
>
> Tying it to Apache IDs is reasonable because this is for us. It’s for our
> community. It’s to make others want to be part of our community, sure, but
> primarily it’s for our community. Having a (very very small, I might note)
> barrier to entry is totally reasonable. And creating a new, separate ID
> system actively defeats the link with the community, not to mention
> introducing new complications.
>
> Celebrating achievements in community is a building block for tighter
> community relationships. I encourage everyone on the ComDev project to read
> The Art of Community by Charles Vogl, because there’s a TON of science
> around how to build community that we, in open source, tend to be largely
> unaware of, going back decades, and we miss out on a LOT of simple
> low-hanging opportunities to draw people in, and strengthen what we have.
> This is one of them.
>
>
>

Re: [WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

> On Mar 20, 2024, at 11:59 AM, Paulo Motta  wrote:
> 
> Rich:
> 
> I need some time to better elaborate this. I will prepare sometime in the
> next week or so a short doc explaining what am I proposing, what problem it
> solves and how it intersects with the badging tool object of this working
> group.
> 
> I suspect we might be thinking about similar things but in different terms,
> right now I’m just doing unstructured brainstorming.
> 
> On the meantime, can you briefly describe what problem are you trying to
> solve with this badging system, and what do you expect from it to ensure
> we’re talking about the same things? If this is already described somewhere
> please let me know and I will use it to check if this intersects with the
> proposal I have in mind.

The purpose of badging is discussed here: 
https://github.com/apache/comdev-working-groups/tree/main/wg-badging

In brief, it’s to celebrate and gamify moments in individuals’ community 
journey. It’s a way for people to brag/celebrate/display their accomplishments, 
since this is something that has been shown to motivate not only participation, 
but for people to expand outside of their usual habitual sphere of 
participation and try other things.

Tying it to Apache IDs is reasonable because this is for us. It’s for our 
community. It’s to make others want to be part of our community, sure, but 
primarily it’s for our community. Having a (very very small, I might note) 
barrier to entry is totally reasonable. And creating a new, separate ID system 
actively defeats the link with the community, not to mention introducing new 
complications.

Celebrating achievements in community is a building block for tighter community 
relationships. I encourage everyone on the ComDev project to read The Art of 
Community by Charles Vogl, because there’s a TON of science around how to build 
community that we, in open source, tend to be largely unaware of, going back 
decades, and we miss out on a LOT of simple low-hanging opportunities to draw 
people in, and strengthen what we have. This is one of them.

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

Rich:

I need some time to better elaborate this. I will prepare sometime in the
next week or so a short doc explaining what am I proposing, what problem it
solves and how it intersects with the badging tool object of this working
group.

I suspect we might be thinking about similar things but in different terms,
right now I’m just doing unstructured brainstorming.

On the meantime, can you briefly describe what problem are you trying to
solve with this badging system, and what do you expect from it to ensure
we’re talking about the same things? If this is already described somewhere
please let me know and I will use it to check if this intersects with the
proposal I have in mind.

On Wed, 20 Mar 2024 at 15:04 Rich Bowen  wrote:

> On Tue, Mar 19, 2024, 16:55 Paulo Motta  wrote:
>
> > > it looks like there’s no way to run this on the hosted service and have
> > it integrated with ASF LDAP, as each individual badge recipient would
> have
> > to create an account through their tooling.
> >
> > Backing off a bit, do we really need logins for a badging page? In my
> view
> > this would add unnecessary friction/overhead for contributors without ASF
> > IDs, which to me would be the initial beneficiaries of this system.
> >
>
> This is a community building tool. Encouraging people to join the community
> to use the tool seems entirely reasonable to me.
>
> I must admit that I didn't understand your proposed solution at all and
> don't really understand what problem it solves.
>

Re: [WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

On Tue, Mar 19, 2024, 16:55 Paulo Motta  wrote:

> > it looks like there’s no way to run this on the hosted service and have
> it integrated with ASF LDAP, as each individual badge recipient would have
> to create an account through their tooling.
>
> Backing off a bit, do we really need logins for a badging page? In my view
> this would add unnecessary friction/overhead for contributors without ASF
> IDs, which to me would be the initial beneficiaries of this system.
>

This is a community building tool. Encouraging people to join the community
to use the tool seems entirely reasonable to me.

I must admit that I didn't understand your proposed solution at all and
don't really understand what problem it solves.

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

> 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  wrote:

> On Wed, 20 Mar 2024 at 15:59, Paulo Motta  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  wrote:
> >
> > > On Wed, 20 Mar 2024 at 14:02, Paulo Motta  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 
> 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  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 
> 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,
> > > > 

Re: [WG: Badging] Tooling, reclaiming thread

[sebb]

On Wed, 20 Mar 2024 at 15:59, Paulo Motta  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  wrote:
>
> > On Wed, 20 Mar 2024 at 14:02, Paulo Motta  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  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  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  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  > >
> > > >>> 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 
> > 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 
> > wrote:
> > >  >
> > >  > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
> > >  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 

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

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  wrote:

> On Wed, 20 Mar 2024 at 14:02, Paulo Motta  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  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  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  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  >
> > >>> 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 
> 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 
> wrote:
> >  >
> >  > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
> >  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 

Re: [WG: Badging] Tooling, reclaiming thread

[sebb]

On Wed, 20 Mar 2024 at 14:02, Paulo Motta  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  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  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  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 
> >>> 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  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  wrote:
>  >
>  > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
>  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

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

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.

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  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  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  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 
>>> 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  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  wrote:
 >
 > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
 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

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

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  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  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 
>> 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  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  wrote:
>>> >
>>> > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
>>> 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
>>>
>>>

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

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  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 
> 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  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  wrote:
>> >
>> > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
>> 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
>>
>>

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

> 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  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  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  wrote:
> >
> > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  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
>
>

Re: [WG: Badging] Tooling, reclaiming thread

[Gary Gregory]

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  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  wrote:
>
> > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  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

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

Elaborating a bit more on this phase of the contributor onboarding pipeline:

> 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.

This form is essentially an electronic CLA. On the first commit, the
contributor receives a link to this form in the welcome message from
peo...@apache.org congratulating on the first commit. When the contributor
becomes a committer later on, it no longer needs to fill a CLA since this
was already done via this initial form. If the contributor ignored the
welcome message and did not fill the CLA, then it will need to fill it when
becoming a committer.

After filling the electronic CLA the first-time contributor receives a
guest account on ASF slack, and is invited to the USER and DEV channels of
the project it contributed to. When the user contributes to other projects,
it's added to the USER and DEV accounts of the projects it contributed to,
but still as a "guest" member - it cannot join ASF slack channels of
projects it did not contribute to.

When the contributor becomes a committer, its slack guest account is
converted into a slack "member" account (which is not an ASF member
account). From this point on, the contributor can join the slack channel of
any project - even the ones it did not contribute to.

This would solve the issue of project contributors not even knowing about
ASF slack existence.

On Wed, Mar 20, 2024 at 8:23 AM Paulo Motta  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  wrote:
>
>> On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  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
>>
>

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

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  wrote:

> On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  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
>

Re: [WG: Badging] Tooling, reclaiming thread

[Claude Warren]

On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  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

Re: [WG: Badging] Tooling, reclaiming thread

[Paulo Motta]

> it looks like there’s no way to run this on the hosted service and have
it integrated with ASF LDAP, as each individual badge recipient would have
to create an account through their tooling.

Backing off a bit, do we really need logins for a badging page? In my view
this would add unnecessary friction/overhead for contributors without ASF
IDs, which to me would be the initial beneficiaries of this system.

The way I see it, the "baging" widget would be the initial sub-feature of
an auto-generated people.apache.org page, which would contain a verifiable
trace of users' contributions and achievements to ASF projects. This page
could be referenced in Linkedin or resumes to "prove" contributions made by
an individual to ASF projects, serving as an user ASF profile (whether the
user has ASF id or not). Users with custom people.apache.org pages would
not be affected by this, since they would be optint-out of the system by
having a custom page.

This is the rough workflow I have in mind:

1. User John Doe  makes first contribution to Apache Foo.
2. John Doe receives an email from peo...@apache.org on john...@acme.org
with the following content:
  "Congratulations on your first ASF contribution John, we would love for
you to have a page on people.apache.org to showcase your achievements on
ASF projects. Click here to generate your "First Contribution" badge if you
want that. If you don't want this, please ignore this email and we promise
to never contact you again."
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.
4. After form submission and reviewed by a human, a new page is created:
people.apache.org/~doejohn
5. people.apache.org/~doejohn will have a simple static HTML page with the
following information:
1. Title: John Doe's ASF Achievements Page
2. Name: John Doe
3. Optional Avatar photo from gravatar.com
4. Role: ASF Contributor
5. Badge widget containing the first badge: "My First Contribution"
6. List of contributions done by John Doe to all ASF projects.
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"
7. After 1000 commits to ASF projects, this kicks off a new hypothetical
badge to John Doe "1000 commits to ASF projects"
8. A Human verifies this badge to check it's not bogus.
9. If this is the case, people.apache.org/~doejohn badge widget is updated
to include the "1000 commits to ASF projects" badge.
   - please note "1000 commits to ASF projects" is not a real badge, it's
just a hypothetical example to illustrate this system. Badges to non-code
contributions would also exist but it's out of the scope of this discussion.

What do you think?

If this makes sense I would be happy to develop this idea into a design doc
for review.

On Mon, Mar 11, 2024 at 8:36 AM Rich Bowen  wrote:

> Ok, since the existing “Tooling” thread has been hopelessly derailed into
> … whatever that is, I’m going to try to reboot this thread.
>
> So far, we have a proposed solution from Paulo:
>
>
> > I've played around with badgr.com  a bit and was
> able to create the
> > following organization and badge very quickly (the site usability is
> pretty
> > good):
> > - ORG: https://badgr.com/public/issuers/bumbzeisQSuoN3Q_G4753Q/badges
> > - BADGE:
> >
> https://badgr.com/public/assertions/ROzmBXUXQ9Cs86uMYdrGvA?identity__email=pauloricardomg%40gmail.com
>
> After poking through this a bit, it looks like there’s no way to run this
> on the hosted service and have it integrated with ASF LDAP, as each
> individual badge recipient would have to create an account through their
> tooling. This rather violates the “easy” requirement.
>
> Anyone have any insight into if, or how, we might do that, or another
> badging tool that may make this easier?
>
> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>
>
>

[WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

Ok, since the existing “Tooling” thread has been hopelessly derailed into … 
whatever that is, I’m going to try to reboot this thread.

So far, we have a proposed solution from Paulo:


> I've played around with badgr.com  a bit and was able to 
> create the
> following organization and badge very quickly (the site usability is pretty
> good):
> - ORG: https://badgr.com/public/issuers/bumbzeisQSuoN3Q_G4753Q/badges
> - BADGE:
> https://badgr.com/public/assertions/ROzmBXUXQ9Cs86uMYdrGvA?identity__email=pauloricardomg%40gmail.com

After poking through this a bit, it looks like there’s no way to run this on 
the hosted service and have it integrated with ASF LDAP, as each individual 
badge recipient would have to create an account through their tooling. This 
rather violates the “easy” requirement.

Anyone have any insight into if, or how, we might do that, or another badging 
tool that may make this easier?

— 
Rich Bowen
rbo...@rcbowen.com