Re: ASF on Redbubble

[Paulo Motta]

Sorry to hear about the bad experience at Redbubble.

I like the quality of customink shirts, and I think they support custom
stores [1]. I don’t know prices or policies though, just throwing this
suggestion/alternative out there.

[1] -
https://www.customink.com/onlinestores

On Thu, 18 Apr 2024 at 03:12 Mark Thomas  wrote:

> On 18/04/2024 06:54, Richard Zowalla wrote:
> > Hi all,
> >
> > did we receive any updates/explanation?
>
> No.
>
> > If the service is gone, we might want to update it's references in ASF
> sites.
>
> Yes, it is gone. Any existing references need to be removed until we
> have replacement.
>
> So far the only posdible alternative suggested is
> https://www.printful.com/
>
> We could really do with a handful of alternatives to look at.
>
> Mark
>
>
> >
> > Gruß
> > Richard
> >
> > Am 23. Februar 2024 09:11:39 MEZ schrieb Mark Thomas :
> >> All,
> >>
> >> It isn't looking good. Redbubble have denied the suspension appeal and
> still haven't explained why the account has been suspended. I've asked but
> I am not sure I am going to get a response.
> >>
> >> I think we need to start looking for alternative services.
> >>
> >> Suggestions welcome.
> >>
> >> I haven't informed the PMCs using Redbubble yet. I'll do that if my
> request for an explanation of why the account was suspended gets nowhere.
> >>
> >> Mark
> >>
> >>
> >> On 21/02/2024 15:31, Mark Thomas wrote:
> >>> On 21/02/2024 14:44, Richard Zowalla wrote:
>  Hey Mark,
>  I am unable to find the ComDev store  on Redbubble at all.
>  My previous orders from ComDev are gone (or I ordered from the wrong
>  people in the recent years).
> 
>  So if you have a link for me, would be great :)
> >>>
> >>> Sigh. Redbubble have suspended our account. I'll see what I can do to
> fix that.
> >>>
> >>> Mark
> >>>
> 
>  Best
>  Richard
> 
> 
> 
>  Am Mittwoch, dem 21.02.2024 um 08:46 + schrieb Mark Thomas:
> > On 20/02/2024 21:55, Jeff Zemerick wrote:
> >> Hi all,
> >>
> >> Hopefully this list is the best place for this.
> >>
> >> I have ordered several OpenNLP shirts in the past from Redbubble. I
> >> did a
> >> recent order for OpenNLP, Airflow, Solr, and NiFi shirts (can never
> >> have
> >> enough, right?) and RedBubble canceled the OpenNLP and Airflow ones
> >> due to
> >> Redbubble’s IP/Publicity Rights Policy [1].
> >
> > I only see Solr in the ComDev store. It may be the case that
> > RedBubble
> > is (finally) taking steps against sellers that sell items using logos
> > they don't have the rights to. Last time I went looking there were a
> > LOT
> > of items with logos for commercial software. You might have got
> > caught
> > up in that.
> >
> >> I just wanted to bring it to the ASF's attention. Is Redbubble
> >> still the
> >> place to get ASF swag?
> >
> > It is the place ComDev maintains although some projects may have set
> > up
> > alternatives.
> >
> > The simplest solution may be to get those PMCs to request that the
> > relevant logos are added to the ComDev store. It just needs an email
> > from someone on the PMC to this list confirming that the PMC would
> > like
> > the logo added.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>  For additional commands, e-mail: dev-h...@community.apache.org
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >> -
> >> 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] Workgroups update

[Paulo Motta]

I would like to help in the badging working group but I’m currently on
vacation. I will follow-up in 4 weeks or less. I will join efforts if
someone else takes on some initial work before then.

On Fri, 29 Mar 2024 at 11:07 Rich Bowen  wrote:

> A month or so ago I started pitching workgroups as a way to organize and
> make progress on the many pain points around the Foundation.
>
> We’ve made a little progress since then, but not a lot of follow-up.
>
> The only way that we’re going to have success here is if we build this
> thing together, and focus on progress, rather than perfection. So I want to
> encourage each of you to think about what single task you can accomplish in
> one of these working groups (or, even better, what’s your idea for another
> group?) in the coming months.
>
> So far, here’s what we have:
>
> A top-level web page talking about the WGs:
> https://community.apache.org/workinggroups/
> 7 proposed WGs:
>
> wg-wg - Defining how working groups work, in general.
> wg-advisors - Advising PMCs on best practice
> wg-badging - Creation and maintenance of an accomplishment badging system
> wg-social - Orchestrating local gathering of Apache enthusiasts
> wg-social-media - Social media
> wg-website - Maintenance and improvement of the website
> wg-welcome - Helping projects, and the ASF in general, be more welcoming
>
> There was a great deal of discussion on the Advisors WG, but the majority
> of that was around naming, rather than actually advising projects. I think
> that this is the WG where we can have the highest impact on the Foundation
> as a whole, and I’d really like to see some folks stepping up to do this
> work, in whatever small ways you can.
>
> I also want to encourage each of you to take ownership of this. This isn’t
> *my* effort. It’s ours, collectively, and we must share the ownership of it
> if we’re going to make any progress. If any of you wants to take a more
> proactive position in any of these WGs, please step forward and do it. You
> don’t need anyone’s permission.
>
> As for myself, I am kind of in stealth mode as an Advisor on a couple of
> projects, and am working on the website as I have time. But this is going
> to take all of us.
>
> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>
>
>

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

[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

[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:
> > > > >>
> > &g

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 

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

[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

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

Re: [WG: Badging] Tooling

[Paulo Motta]

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.apache.org if you would like to continue this discussion.

Going back to the main topic of the working group, I do not think badges
should exist for ASF members, committers or PMCs for two reasons:
1) This will create confusion with ASF roles.
2) Badges should celebrate achievements and not roles.

I'm OK with an Advisor badge if they are associated with a concrete
achievement, and not to indicate a role.

On Sat, Mar 9, 2024 at 6:27 PM Paulo Motta  wrote:

> 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 projects or vendors ?
>
> Thanks!
>
> Paulo
> On Sat, 9 Mar 2024 at 10:35 Jarek Potiuk  wrote:
>
>> 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 Fedora has this nice property that it will potentially disarm
>> attempts by the vendors to define their own "badging system" that
>> might have some properties that are unwanted by the ASF.
>>
>> Without judging the intentions - we had this drama about Cassandra MVP
>>  - which was no more, no less - Cassandra driven badging system that
>> they defined and PMC wanted to adopt it. IMHO this is what it really
>> was about. Putting a "label" on people following some process and
>> conditions, so that those people (and the community) can attach some
>> value to. That's what the badging system is, and that's what the MVP
>> program of Cassandra essentially was.
>>
>> Again - absolutely without judging the intentions that happened in
>> Cassandra's case. If we had our own "ASF recognised" badging system,
>> we could very easily funnel any kind of attempts to do similar badging
>> program into "Here is the badging system we use in ASF - take this one
>> and use it, maybe adapt it a bit - within the limits it provides and
>> you are done". If any stakeholder wants to run their own program -
>> (say Datastax MVP program for Cassandra) -they can still do it, no
>> problem.
>>
>> But if the PMC wants to do something like that, using something that
>> is not only recognised in ASF but also potentially can bring some.
>> synergies (ASF level badges on top of PMC-level ones for example).
>>
>> There are really interesting synergies possible. For example - one
>> could come up with an "ASF Advisor" badge as a way to recognise people
>> who take part in the other comdev working group initiative - Advisors.
>> Or even plain and simple "ASF member" badge. Having a few badges on
>> the ASF level mixed with those on PMC level in a single place
>> (providing that PMC will start using their own labels) might also be a
>> way how to bring the PMCs closer to the ASF on more-or-less daily
>> interactions.
>>
>> I imagine for example a new contributor asking such a question: "Hey I
>> see on top of being the ' mentor' label, you have the 'ASF
>> Advisor' and 'ASF member' - can you explain what it means?"  - If such
>> labels would be visible, and promoted by the PMC in their
>> communication, newsletters, it would be a great opportunity to "bind"
>> the ASF community together.
>>
>> Of course it won't happen overnight, but starting with "choosing" the
>> right badging system and making it easy for PMCs and persons to opt in
>> is absolutely necessary to try it out.
>>
>> J.
>>
>> On Sat, Mar 9, 2024 at 2:35 PM Andrew Wetmore 
>> wrote:
>> >
>> > 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
>

Re: [WG: Badging] Tooling

[Paulo Motta]

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
projects or vendors ?

Thanks!

Paulo
On Sat, 9 Mar 2024 at 10:35 Jarek Potiuk  wrote:

> 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 Fedora has this nice property that it will potentially disarm
> attempts by the vendors to define their own "badging system" that
> might have some properties that are unwanted by the ASF.
>
> Without judging the intentions - we had this drama about Cassandra MVP
>  - which was no more, no less - Cassandra driven badging system that
> they defined and PMC wanted to adopt it. IMHO this is what it really
> was about. Putting a "label" on people following some process and
> conditions, so that those people (and the community) can attach some
> value to. That's what the badging system is, and that's what the MVP
> program of Cassandra essentially was.
>
> Again - absolutely without judging the intentions that happened in
> Cassandra's case. If we had our own "ASF recognised" badging system,
> we could very easily funnel any kind of attempts to do similar badging
> program into "Here is the badging system we use in ASF - take this one
> and use it, maybe adapt it a bit - within the limits it provides and
> you are done". If any stakeholder wants to run their own program -
> (say Datastax MVP program for Cassandra) -they can still do it, no
> problem.
>
> But if the PMC wants to do something like that, using something that
> is not only recognised in ASF but also potentially can bring some.
> synergies (ASF level badges on top of PMC-level ones for example).
>
> There are really interesting synergies possible. For example - one
> could come up with an "ASF Advisor" badge as a way to recognise people
> who take part in the other comdev working group initiative - Advisors.
> Or even plain and simple "ASF member" badge. Having a few badges on
> the ASF level mixed with those on PMC level in a single place
> (providing that PMC will start using their own labels) might also be a
> way how to bring the PMCs closer to the ASF on more-or-less daily
> interactions.
>
> I imagine for example a new contributor asking such a question: "Hey I
> see on top of being the ' mentor' label, you have the 'ASF
> Advisor' and 'ASF member' - can you explain what it means?"  - If such
> labels would be visible, and promoted by the PMC in their
> communication, newsletters, it would be a great opportunity to "bind"
> the ASF community together.
>
> Of course it won't happen overnight, but starting with "choosing" the
> right badging system and making it easy for PMCs and persons to opt in
> is absolutely necessary to try it out.
>
> J.
>
> On Sat, Mar 9, 2024 at 2:35 PM Andrew Wetmore  wrote:
> >
> > 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
> product
> > > neared. Someone in QA found a bug that caused the language runtime to
> > > incorrectly print to the console integers. That person created one
> ticket
> > > for each of the numbers affected, 1, 2 and so forth until it obviously
> all
> > > went very sideways for that person. Fun!
> > >
> > > Gary
> > >
> > > On Sat, Mar 9, 2024, 7:17 AM Paulo Motta  wrote:
> > >
> > > > 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 if they are openly
> licensed.
> > > > 2. I think the "gamification" concern of Gary is actually a feature
> and
> > > not
> 

Re: [WG: Badging] Tooling

[Paulo Motta]

> 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 flexibility to create new types of recognitions that were
not previously considered, making the merit framework more inclusive as
more badge types are created.

The standard ASF merit framework is too coarse-grained what might cause
people to feel undervalued: a contributor may feel undervalued because it's
not a committer, a committer may feel undervalued because it's not a PMC.
This program will address that limitation by providing finer-grained
recognition which is easier to quantify, making contributors happier even
if they don't make the next merit level of the standard ladder (which
should not be affected by this program).

If someone doesn't earn enough points to merit a badge, they should not
deserve that particular badge, and this is OK.  They will at least have the
"fist contribution" badge :-)

> Regarding encouraging PRs: it's not the number of PRs that matter, it's
the usefulness. 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.

I agree. I don't think number of commits alone should be the sole criteria
to award a badge, but it should also not be disconsidered either.

On Sat, Mar 9, 2024 at 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 contributions; the quality of those
> contributions is important.
>
> Regarding encouraging PRs: it's not the number of PRs that matter,
> it's the usefulness.
> 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.
>
> On Sat, 9 Mar 2024 at 12:17, Paulo Motta  wrote:
> >
> > 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 if they are openly licensed.
> > 2. I think the "gamification" concern of Gary is actually a feature and
> not
> > a bug - I think the goal of a badging program is to motivate people to
> > contribute more to get more badges. If someone abuses the system to get
> > badges without deserving them, then this is a problem that should be
> > addressed if/when it arises.
> > 3. Sebb does not see a point in badges and I also am not interested in
> > earning them, but there are many people that do and this could be a good
> > way to encourage contributions. To me, the target audiences of this
> program
> > are primarily new contributors who are not yet committers, and
> secondarily
> > seasoned contributors who like to earn or display badges. People who care
> > less about badges don't need to receive them by just not signing up to
> the
> > badging system as Rich said.
> > 4. It looks like Rich has addressed Gary's privacy consideration but we
> can
> > submit the proposal to ASF Privacy before being implemented for
> additional
> > review.
> > 5. I still think projects should opt-in for project-specific badges (ie.
> > code contributions at project X). If the program is successful, projects
> > will want to adopt it.
> >
> > > We should also have a simple way for people to propose new badges. Spot
> > noted that the bottleneck with Fedora Badges has always been the design
> of
> > the badge, not the lack of ideas.
> >
> > I agree but I think this may distract the initial implementation of the
> > program. I think we should focus on one or a handful of carefully thought
> > badges to start, and if they're proven effective then we could create a
> > process to onboard new badges in the next iteration of the program.
> >
> > On Fri, Mar 8, 2024 at 11:21 PM Paulo Motta  wrote:
> >
> > > 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 syst

Re: [WG: Badging] Tooling

[Paulo Motta]

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 if they are openly licensed.
2. I think the "gamification" concern of Gary is actually a feature and not
a bug - I think the goal of a badging program is to motivate people to
contribute more to get more badges. If someone abuses the system to get
badges without deserving them, then this is a problem that should be
addressed if/when it arises.
3. Sebb does not see a point in badges and I also am not interested in
earning them, but there are many people that do and this could be a good
way to encourage contributions. To me, the target audiences of this program
are primarily new contributors who are not yet committers, and secondarily
seasoned contributors who like to earn or display badges. People who care
less about badges don't need to receive them by just not signing up to the
badging system as Rich said.
4. It looks like Rich has addressed Gary's privacy consideration but we can
submit the proposal to ASF Privacy before being implemented for additional
review.
5. I still think projects should opt-in for project-specific badges (ie.
code contributions at project X). If the program is successful, projects
will want to adopt it.

> We should also have a simple way for people to propose new badges. Spot
noted that the bottleneck with Fedora Badges has always been the design of
the badge, not the lack of ideas.

I agree but I think this may distract the initial implementation of the
program. I think we should focus on one or a handful of carefully thought
badges to start, and if they're proven effective then we could create a
process to onboard new badges in the next iteration of the program.

On Fri, Mar 8, 2024 at 11:21 PM Paulo Motta  wrote:

> 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
> project would opt-out, but if they want to they should have this
> prerrogative.
>
> > I am worried about gamification and a flood of PRs just to get badges.
>
> What’s the worry? A flood of PRs seems like a good thing for projects
> needing contributions. 
>
> > Some people may not want badges; they should not be forced to have them
> if they happen to meet the criteria.
>
> Badges need to be accepted by the awardee before being emitted.
>
> > Personally, I do not see the point of them.
>
> You are probably not the target audience for badges if you are a seasoned
> contributor.
>
> > I wonder if there are there any privacy issue we should be able to
> foresee?
>
> priv...@apache.org should determine if the privacy policy of the chosen
> badging provider is acceptable, Badging WG members should not worry about
> this.
> On Fri, 8 Mar 2024 at 12:38 Gary Gregory  wrote:
>
>> 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 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
>> > the internet public might be able to painstakingly assemble, but maybe
>> not.
>> > >
>> >
>> > Every badge that I’ve come up with in brainstorming about this has been
>> > either 1) based on public information or 2) something that the recipient
>> > requests (like “I attended a particular event.”). None of it seemed
>> > particularly painstaking. Do you have concerns?
>> >
>> >
>> > > Should a person be allowed to opt out of a specific badge or the whole
>> > badge system?
>> >
>> >
>> > As I said in the email you responded to …
>> >
>> > >>
>> > >> For every badge system I’ve looked at, n

Re: [WG: Badging] Tooling

[Paulo Motta]

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 project
would opt-out, but if they want to they should have this prerrogative.

> I am worried about gamification and a flood of PRs just to get badges.

What’s the worry? A flood of PRs seems like a good thing for projects
needing contributions. 

> Some people may not want badges; they should not be forced to have them
if they happen to meet the criteria.

Badges need to be accepted by the awardee before being emitted.

> Personally, I do not see the point of them.

You are probably not the target audience for badges if you are a seasoned
contributor.

> I wonder if there are there any privacy issue we should be able to
foresee?

priv...@apache.org should determine if the privacy policy of the chosen
badging provider is acceptable, Badging WG members should not worry about
this.
On Fri, 8 Mar 2024 at 12:38 Gary Gregory  wrote:

> 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 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
> > the internet public might be able to painstakingly assemble, but maybe
> not.
> > >
> >
> > Every badge that I’ve come up with in brainstorming about this has been
> > either 1) based on public information or 2) something that the recipient
> > requests (like “I attended a particular event.”). None of it seemed
> > particularly painstaking. Do you have concerns?
> >
> >
> > > Should a person be allowed to opt out of a specific badge or the whole
> > badge system?
> >
> >
> > As I said in the email you responded to …
> >
> > >>
> > >> For every badge system I’ve looked at, nobody receives any badges
> until
> > they log into the system, creating their account. That is, these systems
> > are all opt-in by default. If people are actual averse to receiving
> > congratulations for their activities, then don’t create a badge system
> > account. Done and done.
> > >>
> >
> > Whether a person can opt out of a particular badge, that’s more a tooling
> > question. I would assume that the answer is “yes” since this is just
> data,
> > and data can be deleted.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

Re: [WG: Badging] Tooling

[Paulo Motta]

> 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 little concerned
about a free-to-use service, because there’s no protection against them
suddenly changing that model when they realize we have *thousands* of
users.

Yes, see above ^

> Would probably be worth having a conversation with them about their
available plans.

This is a nice to have but probably not a blocker to start with initial
badges, as long a public badgr fork exists. Perhaps it would make sense to
check if the fork is deployable in case the self-hosting model is preferred
in the future.

> I think that work can happen in parallel to choosing a tool, so, sure, go
ahead!

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 a pilot badge called 'My First Open Source Contribution'
awarded to anyone first's contribution to an Apache project that opts-in to
this badge. This recognition is straightforward to compute and would allow
testing the program.

We can recommend new/incubating projects to adopt the badge and it should
be uncontroversial for existing projects to adopt the badge, since it helps
with motivating first-time contributors.

The badge image should be formatted to be easily repostable in socials
(Linkedin and X initially) to allow awardees to share the badge and
encourage more people to make first time contributions.

On Thu, Feb 29, 2024 at 10:04 AM Rich Bowen  wrote:

>
> > 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 AGPL. Does that cause anyone concern?
>
> >
> >> can someone step up to do the research to find one?
> >
> > 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
>
> Cool. Thanks for digging deeper than I did. :)
>
> Are you suggesting that we use this service? I’m a little concerned about
> a free-to-use service, because there’s no protection against them suddenly
> changing that model when they realize we have *thousands* of users. Would
> probably be worth having a conversation with them about their available
> plans.
>
> >
> > I've added more details about the fields required to create badges on
> this
> > comment:
> > -
> >
> https://github.com/apache/comdev-working-groups/pull/26#issuecomment-1970310015
> >
> > If moving forward with badgr make sense I can create a spreadsheet for
> > folks to suggest badge types so we can get them set up. Then we can
> > advertise to projects who can opt-in to the badging system.
>
> I think that work can happen in parallel to choosing a tool, so, sure, go
> ahead!
>
>
> >
> > We could initially emit badges manually and later work on automating the
> > process with stats from contribution feeds.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [WG: Badging] Tooling

[Paulo Motta]

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

I've added more details about the fields required to create badges on this
comment:
-
https://github.com/apache/comdev-working-groups/pull/26#issuecomment-1970310015

If moving forward with badgr make sense I can create a spreadsheet for
folks to suggest badge types so we can get them set up. Then we can
advertise to projects who can opt-in to the badging system.

We could initially emit badges manually and later work on automating the
process with stats from contribution feeds.

On Thu, Feb 29, 2024 at 9:18 AM Rich Bowen  wrote:

> So … a few years ago, I looked for badging software, and there were
> several options. It appears that all of them have been acquired and made
> non-open. The most promising of these was Badgr (https://badgr.com/)
> which seems to have become a paid service, and not open any more.
>
> Another one - https://openbadges.org/ - appears to have become a group
> promoting a standard for badges, but not actually providing a reference
> implementation. There are several “certified” implementations (
> https://site.imsglobal.org/certifications?refinementList%5Bstandards_lvlx%5D%5B0%5D=Open%20Badges
> ) but I don’t know if any of those are open source.
>
> My canonical version of badging done well, as I mentioned in the README,
> is Fedora Badges - https://badges.fedoraproject.org/ - but while it is,
> technically, open source (https://github.com/fedora-infra/tahrir), it’s
> also very Fedora specific, and past attempts to get it to be more generic
> were not welcome. (Mostly because, at the time, they, too, were planning to
> move to a more general purpose solution, which, since that time, has gone
> non-open.)
>
> I am *very* reluctant to write something (and, no, I don’t mean me
> personally, but *us*) because that will be a forever project that will
> likely end up unmaintained, like several endeavors in the past. But I
> suppose that’s an option. I just feel like it should be a last resort.
>
> Are any of you aware of a badging solution that we can use? Or, can
> someone step up to do the research to find one?
>
> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>
>
>

Re: [WG: Badging] Proposed working group

[Paulo Motta]

Added a comment to
https://github.com/apache/comdev-working-groups/pull/26#issuecomment-1970310015

On Wed, Feb 28, 2024 at 12:27 PM Paulo Motta  wrote:

> I'd be interested in collaborating on this WG. I'd probably not be able to
> drive this, but would like to participate in discussions and maybe help
> with one of the items.
>
> On Wed, Feb 28, 2024 at 8:54 AM Rich Bowen  wrote:
>
>> TL;DR: https://github.com/apache/comdev-working-groups/pull/26
>>
>> Over the years, we’ve discussed a badging/achievement system, but have
>> never actually figured out the details around doing it. This is a proposal
>> for a working group to figure out what’s necessary, and determine whether
>> we want to set up such a system.
>>
>> I’m interested in being part of the discussion, but don’t want to be the
>> only one driving it, since I’m already taking on too much. But I didn’t
>> want to drop a conversation that comes up several times a year, as far back
>> as I can remember.
>>
>> —
>> Rich Bowen
>> rbo...@rcbowen.com
>>
>>
>>
>>
>>

Re: [WG: Badging] Proposed working group

[Paulo Motta]

I'd be interested in collaborating on this WG. I'd probably not be able to
drive this, but would like to participate in discussions and maybe help
with one of the items.

On Wed, Feb 28, 2024 at 8:54 AM Rich Bowen  wrote:

> TL;DR: https://github.com/apache/comdev-working-groups/pull/26
>
> Over the years, we’ve discussed a badging/achievement system, but have
> never actually figured out the details around doing it. This is a proposal
> for a working group to figure out what’s necessary, and determine whether
> we want to set up such a system.
>
> I’m interested in being part of the discussion, but don’t want to be the
> only one driving it, since I’m already taking on too much. But I didn’t
> want to drop a conversation that comes up several times a year, as far back
> as I can remember.
>
> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>
>
>

Re: Include new GSoC 2022 project Idea

[Paulo Motta]

I also need a page refresh after taging a new project with "gsoc2022". It
seems like the "table of contents" links are not working.

To be honest I don't love that the Ideas Page needs to be refreshed
manually and the information on it does not reflect the actual project
difficulty/size.

Is there any reason we don't use *only* JIRA for ASF GSoC Ideas List? This
is more dynamic and does not require a manual refresh.

Em qua., 2 de mar. de 2022 às 07:26, Bobur Umurzokov 
escreveu:

> Hi Team,
>
> Could you help to include below new project idea to project list
> ,
> please?
>
>
> https://issues.apache.org/jira/browse/COMDEV-451?jql=labels%20%3D%20gsoc2022
>
> Kind regards,
> Bobur
>

Re: How to get started with contribution

[Paulo Motta]

Hi everyone,

I would like to follow-up on this topic, given the recent student seeking
GSoC information in the mentors list .

I would like to hear your opinions on creating a mixed student and mentors
list  for ASF-wide mentors to advertise projects
to potentially interested students, as well as taking general questions
about ASF participation in GSoC.

If there's interest I can volunteer to set up the list with ASF Infra, and
work with Maxim to set it as a point of contact in ASF's GSoC page (<
https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648
>).

Kind regards,

Paulo



Em sex., 19 de nov. de 2021 às 13:32, sebb  escreveu:

> On Fri, 19 Nov 2021 at 15:19, Paulo Motta 
> wrote:
> >
> > > Would it not be better to point to students@ ?
> >
> > Perhaps not if we want mentors to have visibility of prospective
> students, since that list is restricted only to students afaik.
>
> There have not been many posts [1], but they are publicly archived so
> I doubt it is restricted to students. It was created in June 2013 [2]
>
> If the list name were promoted on the webpage it might help to revive
> the list, otherwise it should perhaps be shut down.
>
> Sebb
> [1] https://lists.apache.org/list?stude...@community.apache.org
> [2] https://issues.apache.org/jira/browse/INFRA-6397
>
> > Em sex., 19 de nov. de 2021 às 12:04, sebb  escreveu:
> >>
> >> On Fri, 19 Nov 2021 at 13:38, Paulo Motta 
> wrote:
> >> >
> >> > Good call Hans - I guess we should make that point to dev@community?
> >>
> >> Would it not be better to point to students@ ?
> >>
> >> Also the 'Mailing List' link on that page points to
> >> https://apache.org/foundation/mailinglists.html
> >> which is a general page about how mailing lists operate. Not what I
> expected.
> >>
> >> The page needs a bit of TLC.
> >>
> >> > Also
> >> > perhaps we should make IRC Channel point to
> https://the-asf.slack.com/ ?
> >> >
> >> > Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
> >> > hans.van.akel...@gmail.com> escreveu:
> >> >
> >> > > The contact email on the GSoC is mentors@a.o
> >> > >
> >> > >
> >> > >
> https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
> >> > >
> >> > > On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik <
> solomax...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Afaik there is students@community
> >> > > > Potential gsoc participants would like to follow shortest path to
> mentors
> >> > > > .
> >> > > >
> >> > > >
> >> > > > from mobile (sorry for typos ;)
> >> > > >
> >> > > >
> >> > > > On Fri, Nov 19, 2021, 20:11 Paulo Motta  >
> >> > > wrote:
> >> > > >
> >> > > > > I wonder why so many students are reaching out to the mentors
> list
> >> > > asking
> >> > > > > for information about GSoC. Perhaps we should create a specific
> list
> >> > > for
> >> > > > > GSoC students or maybe make it more explicit that students
> should reach
> >> > > > out
> >> > > > > to dev@community.apache.org to announce interest in
> participating or
> >> > > ask
> >> > > > > questions about GSoC ?
> >> > > > >
> >> > > > > Cheers,
> >> > > > >
> >> > > > > Paulo
> >> > > > >
> >> > > > > Em sex., 19 de nov. de 2021 às 03:02, Maxim Solodovnik <
> >> > > > > solomax...@gmail.com>
> >> > > > > escreveu:
> >> > > > >
> >> > > > > > Hello Suhel,
> >> > > > > >
> >> > > > > > mentors@ is the list for mentors, not for students :)
> >> > > > > > I can recommend you to check this page:
> >> > > > > > https://community.apache.org/gsoc.html
> >> > > > > >
> >> > > > > > Then find the project you would like to participate in here:
> >> > > > > > https://projects.apache.org/projects.html?
> >> > > > > > language#Java
> 

Re: How to get started with contribution

[Paulo Motta]

> Would it not be better to point to students@ ?

Perhaps not if we want mentors to have visibility of prospective students,
since that list is restricted only to students afaik.

Em sex., 19 de nov. de 2021 às 12:04, sebb  escreveu:

> On Fri, 19 Nov 2021 at 13:38, Paulo Motta 
> wrote:
> >
> > Good call Hans - I guess we should make that point to dev@community?
>
> Would it not be better to point to students@ ?
>
> Also the 'Mailing List' link on that page points to
> https://apache.org/foundation/mailinglists.html
> which is a general page about how mailing lists operate. Not what I
> expected.
>
> The page needs a bit of TLC.
>
> > Also
> > perhaps we should make IRC Channel point to https://the-asf.slack.com/ ?
> >
> > Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
> > hans.van.akel...@gmail.com> escreveu:
> >
> > > The contact email on the GSoC is mentors@a.o
> > >
> > >
> > >
> https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
> > >
> > > On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik 
> > > wrote:
> > >
> > > > Afaik there is students@community
> > > > Potential gsoc participants would like to follow shortest path to
> mentors
> > > > .
> > > >
> > > >
> > > > from mobile (sorry for typos ;)
> > > >
> > > >
> > > > On Fri, Nov 19, 2021, 20:11 Paulo Motta 
> > > wrote:
> > > >
> > > > > I wonder why so many students are reaching out to the mentors list
> > > asking
> > > > > for information about GSoC. Perhaps we should create a specific
> list
> > > for
> > > > > GSoC students or maybe make it more explicit that students should
> reach
> > > > out
> > > > > to dev@community.apache.org to announce interest in participating
> or
> > > ask
> > > > > questions about GSoC ?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Paulo
> > > > >
> > > > > Em sex., 19 de nov. de 2021 às 03:02, Maxim Solodovnik <
> > > > > solomax...@gmail.com>
> > > > > escreveu:
> > > > >
> > > > > > Hello Suhel,
> > > > > >
> > > > > > mentors@ is the list for mentors, not for students :)
> > > > > > I can recommend you to check this page:
> > > > > > https://community.apache.org/gsoc.html
> > > > > >
> > > > > > Then find the project you would like to participate in here:
> > > > > > https://projects.apache.org/projects.html?
> > > > > > language#Java
> > > > > >
> > > > > > Additionally you can search for the GSOC label in JIRA :)
> > > > > >
> > > > > > Please send any additional questions to the dev@community
> > > mailing-list
> > > > > > or better to the dev@ list of the particular Apache project you
> > > would
> > > > > > like to contribute :)
> > > > > >
> > > > > > > -- Forwarded message --
> > > > > > > From: Suhel Kapadia
> > > > > > > Cc:
> > > > > > > Bcc:
> > > > > > > Date: Fri, 19 Nov 2021 01:58:31 +0530
> > > > > > > Subject: How to get started with contribution
> > > > > > > Respected Sir/Madam,
> > > > > > > I am Suhel Kapadia, a 2nd year CSE undergrad.
> > > > > > > I am new to open source contributions but I am well versed in
> c and
> > > > > c++.
> > > > > > I also have some experience with javascript and python.
> > > > > > > I would really appreciate it if you could guide me on how to
> start
> > > > > > contributing to your organization
> > > > > > > Hoping to hear from you soon
> > > > > > > Regards
> > > > > > > Suhel.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Maxim
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

Re: How to get started with contribution

[Paulo Motta]

Good call Hans - I guess we should make that point to dev@community? Also
perhaps we should make IRC Channel point to https://the-asf.slack.com/ ?

Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
hans.van.akel...@gmail.com> escreveu:

> The contact email on the GSoC is mentors@a.o
>
>
> https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
>
> On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik 
> wrote:
>
> > Afaik there is students@community
> > Potential gsoc participants would like to follow shortest path to mentors
> > .
> >
> >
> > from mobile (sorry for typos ;)
> >
> >
> > On Fri, Nov 19, 2021, 20:11 Paulo Motta 
> wrote:
> >
> > > I wonder why so many students are reaching out to the mentors list
> asking
> > > for information about GSoC. Perhaps we should create a specific list
> for
> > > GSoC students or maybe make it more explicit that students should reach
> > out
> > > to dev@community.apache.org to announce interest in participating or
> ask
> > > questions about GSoC ?
> > >
> > > Cheers,
> > >
> > > Paulo
> > >
> > > Em sex., 19 de nov. de 2021 às 03:02, Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > escreveu:
> > >
> > > > Hello Suhel,
> > > >
> > > > mentors@ is the list for mentors, not for students :)
> > > > I can recommend you to check this page:
> > > > https://community.apache.org/gsoc.html
> > > >
> > > > Then find the project you would like to participate in here:
> > > > https://projects.apache.org/projects.html?
> > > > language#Java
> > > >
> > > > Additionally you can search for the GSOC label in JIRA :)
> > > >
> > > > Please send any additional questions to the dev@community
> mailing-list
> > > > or better to the dev@ list of the particular Apache project you
> would
> > > > like to contribute :)
> > > >
> > > > > -- Forwarded message --
> > > > > From: Suhel Kapadia
> > > > > Cc:
> > > > > Bcc:
> > > > > Date: Fri, 19 Nov 2021 01:58:31 +0530
> > > > > Subject: How to get started with contribution
> > > > > Respected Sir/Madam,
> > > > > I am Suhel Kapadia, a 2nd year CSE undergrad.
> > > > > I am new to open source contributions but I am well versed in c and
> > > c++.
> > > > I also have some experience with javascript and python.
> > > > > I would really appreciate it if you could guide me on how to start
> > > > contributing to your organization
> > > > > Hoping to hear from you soon
> > > > > Regards
> > > > > Suhel.
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Maxim
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > > >
> > >
> >
>

Re: GSoC21 Mentor Eligibility

[Paulo Motta]

I have mentored a GSoC student without being a committer back in 2016 (but
with a committer as co-mentor), it was a great experience and helped in my
path to committership. I think we should definitely encourage non-committer
mentors, as long as there is a committer as co-mentor or recognition by the
PMC.

Em sex., 5 de mar. de 2021 às 04:18, Rohit Yadav 
escreveu:

> Thanks Furkan, Maxim.
>
> Regards.
>
> On Fri, Mar 5, 2021 at 12:44 PM Maxim Solodovnik 
> wrote:
> >
> > I would say there are no hard limits here :)
> > The only thing that is MUST: mentor should be ACKed by PMC
> >
> > But IMO mentoring will be much easier with commit access to the project
> :)
> >
> > On Fri, 5 Mar 2021 at 14:12, Furkan KAMACI 
> wrote:
> >
> > > Hi Rohit,
> > >
> > > You can check guide to being a mentor from here:
> > > https://community.apache.org/guide-to-being-a-mentor.html
> > >
> > > It is explained as:
> > >
> > >
> > > *ASF Members and committers can volunteer to mentor or co-mentor
> > > proposals.*
> > >
> > > Kind Regards,
> > > Furkan KAMACI
> > >
> > > On Fri, Mar 5, 2021 at 10:06 AM Rohit Yadav  wrote:
> > >
> > > > All,
> > > >
> > > > Does ASF require that mentors for GSoC21 are committers or PMC
> members
> > > > of the project, or can it be any community contributor recognised by
> > > > PMCs?
> > > >
> > > > Regards.
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Maxim
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Invitation to participate with the ASF at GSoC 2021

[Paulo Motta]

Oh it seems it's not dynamic, but generated periodically by Maxim (thanks
for that!). I'll wait a bit until he does the next batch. ;-)

Em ter., 16 de fev. de 2021 às 18:27, Vanjikumaran Sivajothy <
vanjikuma...@gmail.com> escreveu:

> Hi Paulo,
> What I noticed is the last date of the update is still hanging there on Jan
> 31st, 2021.
> Better to create a ticket and inform Infra?
>
> On Tue, Feb 16, 2021 at 1:25 PM Paulo Motta  wrote:
>
> > I was wondering if issues tagged with "gsoc2021" on JIRA will
> automatically
> > appear on the COMDEV GSoC Ideas list?
> >
> > This seems to be the case according to the wording on the mentors guide
> > [2], but I tagged some tickets on the Cassandra JIRA with "gsoc2021" but
> > they're not showing up on the Comdev Ideas list yet.
> >
> > [1] -
> > https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list
> > [2] - https://community.apache.org/guide-to-being-a-mentor.html
> >
> > Em ter., 16 de fev. de 2021 às 07:30, Rohit Yadav 
> > escreveu:
> >
> > > All,
> > >
> > > Apache CloudStack uses Github issues for issue tracking. I've added an
> > idea
> > > with a link to the Github issue to the GSoC2021 page here:
> > >
> https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list
> > > I want to ask the community if this is acceptable or we need to only
> use
> > > JIRA?
> > >
> > > I've also removed the manual contents with the table of concept macro,
> > some
> > > projects/mentors may need to fix the headings of their proposals.
> > >
> > > Regards.
> > >
> > > On Tue, Feb 9, 2021 at 2:00 PM Maxim Solodovnik 
> > > wrote:
> > >
> > > > @All,
> > > >
> > > > can anyone help?
> > > > INFRA send to dev@ mailing list:
> > > > https://issues.apache.org/jira/browse/INFRA-20205
> > > >
> > > > I can try to add myself as moderator can it help?
> > > >
> > > > On Thu, 4 Feb 2021 at 14:06, Vanjikumaran Sivajothy <
> va...@apache.org>
> > > > wrote:
> > > >
> > > > > I also had the same issue and I used my apache email address.
> > > > >
> > > > > On Wed, Feb 3, 2021 at 11:04 PM Juan Pan 
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Update here.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I tried to subscribe mentors-subscr...@community.apache.org once
> > > > again.
> > > > > >
> > > > > > Until now, I received the `confirm reply` but no `welcome reply`.
> > > > > >
> > > > > > It looks like subscribing failed just like [1] said.
> > > > > >
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/ra9a64c766b9bbf07ec16ce69754752eb080977df7dd46385bebf6a9e%40%3Cdev.community.apache.org%3E
> > > > > >
> > > > > >
> > > > > > 
> > > > > >Juan Pan (Trista)
> > > > > >
> > > > > > Senior DBA & PMC of Apache ShardingSphere
> > > > > > E-mail: panj...@apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 02/3/2021 14:09，Juan Pan wrote：
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > Looks like my email app missed the link [1] in my last email.
> > > > > >
> > > > > >
> > > > > > Sorry for that.
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/ra9a64c766b9bbf07ec16ce69754752eb080977df7dd46385bebf6a9e%40%3Cdev.community.apache.org%3E
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 

Re: Invitation to participate with the ASF at GSoC 2021

[Paulo Motta]

I was wondering if issues tagged with "gsoc2021" on JIRA will automatically
appear on the COMDEV GSoC Ideas list?

This seems to be the case according to the wording on the mentors guide
[2], but I tagged some tickets on the Cassandra JIRA with "gsoc2021" but
they're not showing up on the Comdev Ideas list yet.

[1] -
https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list
[2] - https://community.apache.org/guide-to-being-a-mentor.html

Em ter., 16 de fev. de 2021 às 07:30, Rohit Yadav 
escreveu:

> All,
>
> Apache CloudStack uses Github issues for issue tracking. I've added an idea
> with a link to the Github issue to the GSoC2021 page here:
> https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2021+Ideas+list
> I want to ask the community if this is acceptable or we need to only use
> JIRA?
>
> I've also removed the manual contents with the table of concept macro, some
> projects/mentors may need to fix the headings of their proposals.
>
> Regards.
>
> On Tue, Feb 9, 2021 at 2:00 PM Maxim Solodovnik 
> wrote:
>
> > @All,
> >
> > can anyone help?
> > INFRA send to dev@ mailing list:
> > https://issues.apache.org/jira/browse/INFRA-20205
> >
> > I can try to add myself as moderator can it help?
> >
> > On Thu, 4 Feb 2021 at 14:06, Vanjikumaran Sivajothy 
> > wrote:
> >
> > > I also had the same issue and I used my apache email address.
> > >
> > > On Wed, Feb 3, 2021 at 11:04 PM Juan Pan  wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > >
> > > > Update here.
> > > >
> > > >
> > > >
> > > >
> > > > I tried to subscribe mentors-subscr...@community.apache.org once
> > again.
> > > >
> > > > Until now, I received the `confirm reply` but no `welcome reply`.
> > > >
> > > > It looks like subscribing failed just like [1] said.
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://lists.apache.org/thread.html/ra9a64c766b9bbf07ec16ce69754752eb080977df7dd46385bebf6a9e%40%3Cdev.community.apache.org%3E
> > > >
> > > >
> > > > 
> > > >Juan Pan (Trista)
> > > >
> > > > Senior DBA & PMC of Apache ShardingSphere
> > > > E-mail: panj...@apache.org
> > > >
> > > >
> > > >
> > > >
> > > > On 02/3/2021 14:09，Juan Pan wrote：
> > > > Hi,
> > > >
> > > >
> > > > Looks like my email app missed the link [1] in my last email.
> > > >
> > > >
> > > > Sorry for that.
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://lists.apache.org/thread.html/ra9a64c766b9bbf07ec16ce69754752eb080977df7dd46385bebf6a9e%40%3Cdev.community.apache.org%3E
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > > Juan Pan (Trista)
> > > >
> > > > Senior DBA & PMC of Apache ShardingSphere
> > > > E-mail: panj...@apache.org
> > > >
> > > >
> > > >
> > > >
> > > > On 02/3/2021 11:26，Juan Pan wrote：
> > > > Hi Maxim,
> > > >
> > > >
> > > > I still ran into the same issue earlier, and my ask-for-help email
> did
> > > not
> > > > get settled,
> > > > but it can show us more details now.
> > > > I do not know whether we did any changes so far?
> > > > I will try subscribing to it later and give my update.
> > > >
> > > >
> > > > Best wishes,
> > > > Trista
> > > >
> > > >
> > > > [1] [Mentor ML] How to subscribe mentor mail list?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > > Juan Pan (Trista)
> > > >
> > > > Senior DBA & PMC of Apache ShardingSphere
> > > > E-mail: panj...@apache.org
> > > >
> > > >
> > > >
> > > >
> > > > On 02/3/2021 10:30，Maxim Solodovnik wrote：
> > > > I'm not aware of such limitation :(
> > > >
> > > > @All can someone check what are the rules for mentors@community.a.o?
> > > > Maybe subscriptions should be moderated?
> > > >
> > > > On Wed, 3 Feb 2021 at 07:53, Xiangdong Huang 
> > wrote:
> > > >
> > > > Hi Maxim,
> > > >
> > > > I see the "Currently happening" chapter on the webpage, it is cool!
> > > Thanks
> > > > for your huge effort.
> > > >
> > > > Just want to confirm that are there some limitations for subscribing
> > > > mentors@c.a.o?
> > > > e.g., the subscriber must be Member, IPMC, or PMC, etc..
> > > > Or must use @apache.org mail address (like sending email to
> > announce@a.g
> > > )?
> > > > (As I have sent an email to mentors-subscribe@c.a.o, but did not
> > receive
> > > > responses. :(.
> > > >
> > > > Best,
> > > > ---
> > > > Xiangdong Huang
> > > >
> > > >
> > > >
> > > > Maxim Solodovnik  于2021年2月2日周二 下午4:55写道：
> > > >
> > > > Hello Xiangdong Huang,
> > > >
> > > > On Tue, 2 Feb 2021 at 15:34, Xiangdong Huang 
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > According to [1], if we propose projects/tasks to GSoc, we need to
> > > > subscribe the mailing list ment...@community.apache.org.
> > > >
> > > >
> > > > This is still required
> > > >
> > > >
> > > >
> > > > Are there any requirements to subscribe to the mailing list? I
> > > > 

ASF GSoC mentor eligibility

[Paulo Motta]

Hello,

I'm a community member and active contributor of an Apache project and I'd
like to volunteer to be a GSoC mentor this year. However, I'm not currently
an ASF committer or member.

I'd like to clarify if GSoC mentoring is strictly restricted to ASF
committers or can non-committers also volunteer to be mentors or co-mentors?

ps: I'm sending to this list as I didn't find a clear answer on
https://community.apache.org/guide-to-being-a-mentor.html.

Thanks,

Paulo