Re: [WG: Badging] Tooling, reclaiming thread
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
> 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: 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
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
> 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
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
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
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
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
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
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
> 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
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
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
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
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: [C/C Europe 25][DISCUSSION]
OK, Let's keep the conversation here and prefix any CoC Europe 2025 messages with [C/C Europe 25]. Are either of you planning on attending C/C Europe 24 in Bratislava? Have either of you worked on a conference before? Do either of you have a particular thing you want to do for the conference? Claude
Re: FYI, ASF volunteers page is live, mentors & speakers are welcome to sign up
On Wed, Mar 20, 2024 at 9:31 AM Roman Shaposhnik wrote: > ...does it get rebuilt automatically... Yes [1], although there might be some latency in kicking the build process, a few minutes IIRC. -Bertrand [1] https://ci-builds.apache.org/job/Community%20Development/job/site/job/main/ - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: FYI, ASF volunteers page is live, mentors & speakers are welcome to sign up
This is awesome! Quick question: does it get rebuilt automatically or is there a human kick needed to update the page based on .md and .json data? Thanks, Roman. On Tue, Mar 19, 2024 at 4:45 AM Bertrand Delacretaz wrote: > > Hi, > > The new "ASF volunteer mentors & speakers" page [0] is live, meant to > replace the unmaintained community.zones.apache.org utilities, which > will soon be redirected to it. > > ASF committers are welcome to add their names to that page if you are > willing to be a mentor and/or speaker on ASF topics. > > To do so, add your ASF ID to [1] and if desired you can add some > additional information (region, languages spoken, website) to [2]. > > -Bertrand > > [0] https://community.apache.org/contributors/asf-volunteers.html > [1] > https://github.com/apache/comdev-site/blob/main/source/contributors/asf-volunteers.md > [2] https://github.com/apache/comdev-site/blob/main/static/data/people.json > > - > 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