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
> 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
>
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 d
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
> 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 s
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
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
ins
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
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 ha
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 someo
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 reserv
> 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 fir
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. Essentia
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
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
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 con
> 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 fri
Apologies Paulo if that was. I have indeed missed that this is a public
list.
But - for my excuse - I should have taken Airflow as an example because we
discussed it in public lists (and I had not realized it should have been
secret)
So let me re-cast my considerations here:
* Astronomer runs htt
As a member of the Cassandra community I did not appreciate internal
project matters being brought to a public mailing list without prior
consent. This does not help re-establishing trust of the project with ASF
leadership to work on common projects. Please start a new thread with
priv...@cassandra
Hi Jarek,
You raised interesting discussion points but I would prefer not to discuss
specific examples in a public mailing list, since they may spark
unnecessary controversy and derail from the focus of the working group.
Do you mind summarizing your key considerations without mentioning specific
I like the idea of having "A" badging system that is seen as "ASF
accepted" that any PMC (at PMC level) or any person (at ASF level)
might opt-in to use
I think such badging system - providing that it's "ASF generally
accepted" concept that is defined well - possibly adopted from others
like Fedor
Can I have the 'not badging' badge?
On Sat, Mar 9, 2024 at 9:16 AM Gary Gregory wrote:
> Here is a hopefully entertaining story about gaming a system:
>
> A long time ago (not in a galaxy far away), I worked for a company that
> created an internal $ bug bounty as a major release of our flagship
Here is a hopefully entertaining story about gaming a system:
A long time ago (not in a galaxy far away), I worked for a company that
created an internal $ bug bounty as a major release of our flagship product
neared. Someone in QA found a bug that caused the language runtime to
incorrectly print
> Badges may well cause some people to feel valued, but I think they can be
divisive. What about people who don't 'earn' enough points to merit a
badge? Might that not cause them to feel undervalued?
I think merit frameworks are inherently divisive, but the benefit of badges
is that it gives flexi
> If number of PRs is to be used as a credit towards getting a badge,
maybe there should be a way to flag some PRs as undeserving.
Agreed and perhaps the same for commits and Jira tickets but that's the
last thing I want to spend time adjucating :-(
Gary
On Sat, Mar 9, 2024, 7:34 AM sebb wrote:
Badges may well cause some people to feel valued, but I think they can
be divisive.
What about people who don't 'earn' enough points to merit a badge?
Might that not cause them to feel undervalued?
The value of a person to an ASF project cannot be purely measured in
terms of the number of contribu
Apologies if the previous message sounded snarky - it was late and I
impulsively cherry-picked some excerpts to comment without much second
thought. :-)
A more constructive attempt:
1. I like the principles of the Fedora badging program presented by Rich,
and I think we should adopt them verbatim
Nice discussion! A few comments:
> I do not think that we need projects to opt in to this. Badges are not
aimed at projects. They are aimed at *people*.
Disagree. Projects should have the autonomy to decide if they want to adopt
the ASF badging system for their contributions. I do not see why a p
Hi Rich,
I don't have specific realistic concerns, I am trying to look ahead and
avoid a "how didn't yiu guys think of THIS!" moment 😀
Gary
On Fri, Mar 8, 2024, 12:19 PM Rich Bowen wrote:
> > On Mar 8, 2024, at 12:09 PM, Gary D. Gregory
> wrote:
> >
> > Sure, badging can be fun and it sure se
> On Mar 8, 2024, at 12:09 PM, Gary D. Gregory wrote:
>
> Sure, badging can be fun and it sure seems popular on GitHub: I do like my
> Mars 2020 Helicopter Mission badge (https://github.com/garydgregory/) !
>
> I wonder if there are there any privacy issue we should be able to foresee?
>
> I w
Sure, badging can be fun and it sure seems popular on GitHub: I do like my Mars
2020 Helicopter Mission badge (https://github.com/garydgregory/) !
I wonder if there are there any privacy issue we should be able to foresee?
I would guess that badges would be derived from data that a member from t
On Mar 8, 2024, at 9:19 AM, Rich Bowen wrote:
>
> I attended a talk last week at FOSS Backstage by Spot Callaway, who started
> the Fedora badges program. He said that the guiding principles are:
>
> * It should be fun, not legalistic.
> * It should celebrate non-code accomplishments at least
On Fri, 8 Mar 2024 at 15:44, Rich Bowen wrote:
>
> Let me state this more clearly:
>
> >
> > If someone never logged in, they would never see their badges. That is
> > common to all of the badge platforms that I have looked at.
>
> For every badge system I’ve looked at, nobody receives any badges
Let me state this more clearly:
>
> If someone never logged in, they would never see their badges. That is common
> to all of the badge platforms that I have looked at.
For every badge system I’ve looked at, nobody receives any badges until they
log into the system, creating their account. Tha
> On Mar 8, 2024, at 10:24 AM, sebb wrote:
>
> Some people may not want badges; they should not be forced to have
> them if they happen to meet the criteria.
> I agree that opt-in is necessary.
>
If someone never logged in, they would never see their badges. That is common
to all of the badge
On Fri, 8 Mar 2024 at 15:15, Gary D. Gregory wrote:
>
> > I do not think that we need projects to opt in to this. Badges are not
> > aimed at projects. They are aimed at *people*.
>
> I'm not sure about this. Opt-in would be fine with me. I am worried about
> gamification and a flood of PRs just
> I do not think that we need projects to opt in to this. Badges are not aimed
> at projects. They are aimed at *people*.
I'm not sure about this. Opt-in would be fine with me. I am worried about
gamification and a flood of PRs just to get badges. I think experimenting with
a handful of project
> On Mar 3, 2024, at 11:47 AM, Paulo Motta wrote:
>
> I've thought a bit more and rather than starting with multiple badges, it
> probably makes more sense to start with a single badge to validate the
> idea. More can be proposed later if the first one is shown to be effective.
>
> I'd propose
> I note that it’s AGPL.
I think this is the same as fedora's tahrir <
https://github.com/fedora-infra/tahrir/blob/develop/LICENSE>.
I think we just need to publicly fork this repo on ASF, in case the current
fork dies or badgr changes model.
> Are you suggesting that we use this service? I’m a
> On Feb 29, 2024, at 9:44 AM, Paulo Motta wrote:
>
>> The most promising of these was Badgr (https://badgr.com/) which seems to
> have become a paid service, and not open any more.
>
> An active fork of badgr is available on
> https://github.com/edubadges/edubadges-server.
I note that it’s A
> The most promising of these was Badgr (https://badgr.com/) which seems to
have become a paid service, and not open any more.
An active fork of badgr is available on
https://github.com/edubadges/edubadges-server.
> can someone step up to do the research to find one?
I've played around with badg
41 matches
Mail list logo
