I think there's a lot to be said about this issue. Give users a dopamine hit, to keep them going with their Composr journey.
It's obvious why it hasn't been prioritised, practical things like basic user experience, fixing bugs, features people really need, come first. But I'd argue that implementing this would do more to promote Composr use than say better drag and drop editing. So as soon as the project has the bandwidth to try something big, I think this should be considered.

I think I might decide to implement this for v11, not necessarily for v11 itself but for composr.app, first targeting members rather than webmasters. Given we are changing to a Bazaar model, I can see how a feature similar to this would encourage more community participation, which would be very beneficial for composr.app .

I think for the time being it will be a non-bundled addon, but just like hybridauth and karma, it will show up on the Setup Wizard for immediate install if desired. I see it being useful, but not on a mass scale.

As far as its functionality, I think what I'll do is instead of everything being hooks, I'll use an XML configuration. The XML will define each achievement in a tag block with qualification tags inside (which all have to be met to receive the achievement, or perhaps I could also allow for simple "AND/OR" logic). Qualification tags can be focused on number of content types posted (and can define categories limited to, for example), pages accessed, or the values of custom profile fields. Maybe also allow for using a raw count of rows in a database table as a qualification. Hooks can define additional non-bundled XML configuration that can be used, for example, karma. Qualifications could also be other things, like usergroup membership or specific members for manual awarding.

Manual achievements can also be defined as well given the ability to define usergroups or specific members as the qualifications for earning. This could prove very useful for a manual account verification process to vet verified members, as an example.

In the future, the achievements system will need to have a special XML attribute for achievements specific to webmasters. Or perhaps I can just mark an attribute as visible only to the member who receives it, and that would be true for webmaster achievements.

An additional attribute would mark whether the achievement is visible publicly on a special page that would list the achievements that can be earned (and a member's progress towards that, if applicable).

Earned achievements would be public on a member's profile. I might re-do the rank tab a bit to accommodate achievements, and make rank public (but change it up when another member is viewing).

Actually a better solution may be to use XML as the overall configuration, but the qualifications are defined as hooks. So each qualification to determine if an achievement can be earned would be a hook. The XML can take attributes for the qualification which are then passed as a map of parameters to the hook's function. And the hook returns either true if the qualification passes, false if it does not, or null if the qualification should be ignored for whatever reason (e.g. addon not installed). Hooks would have an additional optional function for determining the % progress towards completion of that particular qualification. In cases where multiple qualification blocks are defined (an "OR" condition), whichever block has the highest overall percent is what will be used for the actual percent towards completion for that achievement. And for qualifications within a block (an "AND" condition), achievements will take the sum of every returned % progress from each qualification (a float between 0 and 1), and divide it by the total number of qualifications which returned a progress, to get the overall progress for that block of qualifications.

Example:

<qualifications>
<qualification name="content" types="image,video" galleries="nature" condition=">=" count="100" />
<qualification name="content" types="image" galleries="space,politics" condition=">=" count="10" />
</qualifications>
<qualifications>
<qualification name="content" types="post" forum="1" condition=">=" count="10" />
</qualifications>
<qualifications>
<qualification name="group" condition="in" id="1" />
<qualification name="group" condition="not_in" id="2" />
</qualifications>

This defines that the achievement is "earned" if:
- The member posted 100 or more collective images and videos in the nature gallery AND 10 or more images collectively in the space and politics galleries... OR
- The member made 10 or more posts in the forum ID 1... OR
- The member is in usergroup 1 but not usergroup 2

Let's say they made 10 image/video posts in nature, 1 image in space/politics, and 9 posts in forum ID 1. The member is in usergroup 3.

Qualification block 1 is only 10% complete. But qualification block 2 is 90% complete. And block 3 does not report a progress since progresses are not applicable to usergroups. Since only one block needs to be 100% to earn the achievement, we take the highest value (90%) as the overall progress towards this achievement.

In progress

Marking resolved.

While I do not have achievements for everything listed implemented by default, theoretically a large majority of the missing ones can be implemented especially with the actionlog hook for achievements.

I will think on whether to implement webmaster specific ones by default. This isn't practical right now since achievements is a non-bundled addon (I made the determination to set it non-bundled for now since configuring it requires some XML expertise; if multiple people declare they find this addon useful, I may move it bundled in the future).