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 <ja...@potiuk.com> 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 '<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 > >
