> 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 <seb...@gmail.com> 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 <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 > > >> > > > >> > > > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
