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 '<MY_PMC> 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 <cottag...@gmail.com> wrote: > > Can I have the 'not badging' badge? > > On Sat, Mar 9, 2024 at 9:16 AM Gary Gregory <garydgreg...@gmail.com> 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 <pa...@apache.org> 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 <pa...@apache.org> 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 <garydgreg...@gmail.com> > > 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 <rbo...@rcbowen.com> wrote: > > > >> > > > >> > > On Mar 8, 2024, at 12:09 PM, Gary D. Gregory <ggreg...@apache.org > > > > > > >> > 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 > > > >> > > > > >> > > > > >> > > > > > > > > > > > > -- > Andrew Wetmore > > Editor, Moose House Publications <https://moosehousepress.com/> > Editor-Writer, The Apache Software Foundation <https://apache.org/> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
