You can award and revoke badges from conduit, though we may build a more robust award api later.

I'll send you some kind of something-or-other for dropping "Quality" from Conduit for the moment.

Do you have a rough suggestion on what to do with badges.search? Seems like noone would use these feature regardless.

... and then there was one ...

After D17422, I used bin/lipsum to generate about 20,000 badges. (They all have USERS permission so the permission checks are about as fast as possible.)

I'm just trying to understand the feedback. There are points that come very close to "redesign badges" to which I'm like years away from doing, if ever.

I'm fine with just declining to implement that, it just seems like something we should fix if we're calling it a bug.

Why do we need T10698 specifically? Seems overkill.

Darn race condition.

Looks like search and edit are implemented, but not awards. Awarding a badge through conduit seems nice to have? but I don't see any requests for it, so not sure it's worth holding up unbeta.

This has been implemented and in use for a while, so closing and will finish up smaller tasks in backlog.

That data doesn't exist unfortunately, so it wasn't able to be migrated. You shouldn't see that on current badge awards.

I've got this on most of my Badges on the profile page (not here, 2 local Phabricator installations):

That's my expectation too -- the user cycles their "2012 Hackathon Winner" badge out for "2013 Easter Egg Finder" once they get bored of it, so badges are always fresh and lookin' fly.

I expect every user to have millions of participation badges. Yet they'll have to select just two to prominently display.

I'm struggling with how to think about the 'temporal' nature of some peer awards that might fit badges. For example, I'd like to give the team that won the popular vote at a hackathon, but it would not feel so special if after a year "everyone" had an Epic badge displayed all the time. I'm thinking more "you get celebrated for a month" and less "list of all the typos I found 3 year ago".

I expect two more diffs for this task: one for awarding/revoking badges in the badges.edit API call, and one for querying who awarded whom.

Yeah, I was pondering the award/revoke flow. PasteEditConduitAPIMethod is so bare bones as an example, and PhabricatorBadgesEditEngine is so different from other edit engines... I'm just not sure how that will hook into the badges edit API method.

The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.

Is there a reason, other than scope, why we're not implementing a badges.create Conduit API method? Or any of the other ones?

What's left is adding Awarded by ... to recipient list on badge view:

No, badges themselves don't have an awarder.

We currently track awarderPHID in the badges_award table. Do we still need an awarderPHID in badges_badge table?

Too many deck slots, product literally unplayable.

Wait are they not Blizzard colors any more? My team can't handle using different colors from WoW and Diablo III and will find this feature too confusing if they have to learn about ponies too. Phabricator is ruined forever.