Apologies Paulo if that was. I have indeed missed that this is a public list. But - for my excuse - I should have taken Airflow as an example because we discussed it in public lists (and I had not realized it should have been secret)
So let me re-cast my considerations here: * Astronomer runs https://www.astronomer.io/champions/ "The Astronomer Champions Program for Apache Airflow" - with all the trademarks reviews, and nominative use of Airflow as expected by Trademarks and our policies, * It's run by Astronomer and it's cool for the community, it has no PMC involvement at all (besides that we know about it) - to avoid the feeling that it's a "PMC" thing - some of the people are already posting blogs and having talks at our "Monthly Town Hall meetings" This is all cool and great, but we can't make it a PMC "badging" program as it is not run by the PMC. Having said that - it would be cool if we have (providing it's "ASF recognized" - similar badging program for Airflow. That's the gist of what I wanted to say - and yes, the Airflow example here is much better as a context for this discussion. J. On Sun, Mar 10, 2024 at 3:47 PM Paulo Motta <pa...@apache.org> wrote: > 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 <pa...@apache.org> 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 <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 > >> > >> >
