Re: Self Introduction - Xuanwo
On March 9, 2024 11:20:20 PM CST, Xuanwo wrote: >Hello, everyone > >I'm Xuanwo, and I'm following the "Contribute" guide in >comdev-working-groups[1] to introduce myself and kickstart my contributions :) > >My personal vision is "Empowering freely data access from ANY storage service >in ANY method". Open source is definitely an important part of achieving my >vision. > >- I'm the PMC Chair for Apache OpenDAL [2], a project that graduated in >January 2024, aimed at enabling free data access. >- I work at Databend Labs [3], focusing on cost-effective data analysis. >- I'm also contributing to Apache Iceberg [4] to simplify reading SQL tables. > >My current interest lies in open source sustainability. I want to learn how to >ensure a project's sustainability and foster community growth. I'm here to >explore how I can contribute to expanding the ASF community. > >Pleased to meet you here; I'm looking forward to working together with you. > >[1]: https://github.com/apache/comdev-working-groups >[2]: https://github.com/apache/opendal >[3]: https://github.com/datafuselabs/databend/ >[4]: https://github.com/apache/iceberg-rust > >Xuanwo > >- >To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >For additional commands, e-mail: dev-h...@community.apache.org >
Re: How to build the community page?
Locate and fix - https://github.com/apache/comdev-site/pull/161
Best,
tison.
tison 于2024年3月10日周日 00:05写道：
> Hi,
>
> The README file writes: run `hugo` to get the static content.
>
> I got:
>
> $ hugo
> Start building sites …
> hugo v0.123.8-5fed9c591b694f314e5939548e11cc3dcb79a79c+extended
> darwin/arm64 BuildDate=2024-03-07T13:14:42Z VendorInfo=brew
>
> ERROR render of "section" failed:
> "/Users/tison/Brittani/comdev-site/layouts/_default/baseof.html:87:13":
> execute of template failed: template: _default/list.html:87:13: executing
> "_default/list.html" at : error calling
> partial:
> "/Users/tison/Brittani/comdev-site/layouts/partials/website-source.html:5:86":
> execute of template failed: template: partials/website-source.html:5:86:
> executing "partials/website-source.html" at <.Page.File.Path>: error
> calling Path: runtime error: invalid memory address or nil pointer
> dereference
> Total in 77 ms
> Error: error building site: render: failed to render pages: render of
> "section" failed:
> "/Users/tison/Brittani/comdev-site/layouts/_default/baseof.html:87:13":
> execute of template failed: template: _default/list.html:87:13: executing
> "_default/list.html" – File is nil; wrap it in if or with: {{ with partial
> "website-source.html" .>: error calling partial:
> "/Users/tison/Brittani/comdev-site/layouts/partials/website-source.html:5:86":
> execute of template failed: template: partials/website-source.html:5:86:
> executing "partials/website-source.html" at <.Page.File }}{{ .Path }}{{ end
> }}
>
> Is the version the issue or I miss some steps?
>
> Best,
> tison.
>
Self Introduction - Xuanwo
Hello, everyone I'm Xuanwo, and I'm following the "Contribute" guide in comdev-working-groups[1] to introduce myself and kickstart my contributions :) My personal vision is "Empowering freely data access from ANY storage service in ANY method". Open source is definitely an important part of achieving my vision. - I'm the PMC Chair for Apache OpenDAL [2], a project that graduated in January 2024, aimed at enabling free data access. - I work at Databend Labs [3], focusing on cost-effective data analysis. - I'm also contributing to Apache Iceberg [4] to simplify reading SQL tables. My current interest lies in open source sustainability. I want to learn how to ensure a project's sustainability and foster community growth. I'm here to explore how I can contribute to expanding the ASF community. Pleased to meet you here; I'm looking forward to working together with you. [1]: https://github.com/apache/comdev-working-groups [2]: https://github.com/apache/opendal [3]: https://github.com/datafuselabs/databend/ [4]: https://github.com/apache/iceberg-rust Xuanwo - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: [WG: Badging] Tooling
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 > > > > 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
How to build the community page?
Hi,
The README file writes: run `hugo` to get the static content.
I got:
$ hugo
Start building sites …
hugo v0.123.8-5fed9c591b694f314e5939548e11cc3dcb79a79c+extended
darwin/arm64 BuildDate=2024-03-07T13:14:42Z VendorInfo=brew
ERROR render of "section" failed:
"/Users/tison/Brittani/comdev-site/layouts/_default/baseof.html:87:13":
execute of template failed: template: _default/list.html:87:13: executing
"_default/list.html" at : error calling
partial:
"/Users/tison/Brittani/comdev-site/layouts/partials/website-source.html:5:86":
execute of template failed: template: partials/website-source.html:5:86:
executing "partials/website-source.html" at <.Page.File.Path>: error
calling Path: runtime error: invalid memory address or nil pointer
dereference
Total in 77 ms
Error: error building site: render: failed to render pages: render of
"section" failed:
"/Users/tison/Brittani/comdev-site/layouts/_default/baseof.html:87:13":
execute of template failed: template: _default/list.html:87:13: executing
"_default/list.html" – File is nil; wrap it in if or with: {{ with partial
"website-source.html" .>: error calling partial:
"/Users/tison/Brittani/comdev-site/layouts/partials/website-source.html:5:86":
execute of template failed: template: partials/website-source.html:5:86:
executing "partials/website-source.html" at <.Page.File }}{{ .Path }}{{ end
}}
Is the version the issue or I miss some steps?
Best,
tison.
Re: [WG: Badging] Tooling
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 > > > 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
Re: [WG: Badging] Tooling
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 > > 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
Re: [WG: Badging] Tooling
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 > 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
Re: [WG: Badging] Tooling
> 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 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
Re: [WG: Badging] Tooling
> 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 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 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
Re: [WG: Badging] Tooling
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 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
Re: [WG: Badging] Tooling
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, 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. >> > >> > >> > >> > - >>
