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
