Greetings Rich, On 2024/02/29 14:18:03 Rich Bowen wrote:> So … a few years ago, I looked for badging software, and there were several options. It appears that all of them have been acquired and made non-open. The most promising of these was Badgr (https://badgr.com/) which seems to have become a paid service, and not open any more.
>> Another one - https://openbadges.org/ - appears to have become a group promoting a standard for badges, but not actually providing a reference implementation. There are several “certified” implementations (https://site.imsglobal.org/certifications?refinementList%5Bstandards_lvlx%5D%5B0%5D=Open%20Badges ) but I don’t know if any of those are open source.
>> My canonical version of badging done well, as I mentioned in the README, is Fedora Badges - https://badges.fedoraproject.org/ - but while it is, technically, open source (https://github.com/fedora-infra/tahrir), it’s also very Fedora specific, and past attempts to get it to be more generic were not welcome. (Mostly because, at the time, they, too, were planning to move to a more general purpose solution, which, since that time, has gone non-open.)
>> I am *very* reluctant to write something (and, no, I don’t mean me personally, but *us*) because that will be a forever project that will likely end up unmaintained, like several endeavors in the past. But I suppose that’s an option. I just feel like it should be a last resort.
>
> Are any of you aware of a badging solution that we can use?I am not aware of a badging solution… in fact, this is the first time I hear about “badging”. I fear there may be a small XY problem here; our goal should be to recognize/reward contributions. Badges are just one possible form of recognition.
If we broaden the topic, the one solution I remember seeing for crediting contributors is All Contributors: https://allcontributors.org All Contributors is a little confusing, but it can be considered both a specification and a tool implementing it. The tool is quite limited (notably, see https://github.com/all-contributors/cli/issues/325), but I have noticed a few projects using it lately. But regardless of the status of the tool and the specification, this is a community with similar/identical goals. Creating a new system should not be excluded, but I agree we should look elsewhere closely before, and All Contributors, despite significant challenges, should not be brushed off IMHO (I have never implemented it and barely know it).
Thank you very much for bringing up this topic. To me, a contribution tracking system could achieve much more than credit. It can also build a portfolio of contributions, as All Contributors aims to do. A real portfolio brings several advantages:
* It helps contributors realize how much these small miscellaneous contributions end up amounting to. * It helps contributors understand how they spend their time. * It looks a lot more serious (and convincing) than badges for those who want to showcase their work to potential clients. * It helps identifying and managing problematic contributors/contributions. * For an organization which claims to be meritocratic like the ASF, it makes it much easier to measure everybody’s value/reliability―merit.I consider a portfolio more useful than badges, but a portfolio can perfectly cohabit with an opt-in badge system. Stack Exchange uses both badges and some reputation score. Despite their reputation being simplistic, the whole system is so much better than nothing that it achieved tremendous success.
Ideally, I would like to see a merit evaluation system addressing the gaming concerns. That could bring the side benefit of identifying those with dwindling reputation, possibly going through burnout or other mental health issues. But that, of course, is way more ambitious, and I haven’t seen anything at that level.
Apologies if this strays a bit, but I take issue with your description of code as “easy”: https://github.com/apache/comdev-working-groups/blob/b64772e50d0eda6885b308c3b0d2532b0ac0ede9/wg-badging/README.md?plain=1#L33 Deciphering rushed “clever” Perl or a clueless junior’s uncommented and broken C is not necessarily easy. In particular when that junior was fired years ago and nobody reviewed the code. “Vibe coding” may be easy, but writing performant, clear, reusable, secure, well-documented, reliable, i18ned multi-platform and future-proof code, fitting it in an arcane C codebase, and getting it accepted by the only maintainer left, who has no time to teach or supervise you, but enough to point out how your solution disrespects the project’s undocumented architecture and equally undocumented standards, all while the customer sees little value in upstreaming, is not necessarily easy.
I fully agree with your presumed intention of encouraging other work, which CBPP projects struggle to provision, but that is no reason to call the few tasks which we provision more easily… easy. Few software development tasks are consistently easy, in particular with CBPP―at least if you seek excellence. In fact, I am not even convinced that coding is less hard than particularly underprovisioned tasks. The reasons why provisioning of different tasks is disproportionate in CBPP are complex, but poor recognition is a major factor, and I would much rather valorize underprovisioned roles than diminishing those which cause less concern.
-- 🅭🄍:https://www.philippecloutier.com/Common+infrastructure+licensing#list Philippe Cloutier
OpenPGP_0x8A37FF445EA6611D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
