Conundrum of Tracking of Non-Technical Contributions
Interactions with services are the sole means by which messages are published on the Fedora Messaging bus, resulting in their exclusive tracking. These services primarily cater to technical contributions, thus posing a challenge in monitoring non-technical contributions. Given the diverse nature of such contributions and the subjective approaches employed to track them, devising an objective method to describe them becomes notably arduous. What may be perceived as a contribution by one individual may not be considered as such by another, thereby undermining the service’s ability to consistently track non-technical contributions.
One potential workaround to address this issue involves implementing badges on the Fedora Badges platform for various non-technical contributions. However, this approach suffers from severe scalability issues when new badges need to be added manually for each type of non-technical contribution. Consequently, it could result in a scenario where there are thousands of badges associated with a specific type of non-technical contribution, but only a few individuals receiving each badge. Moreover, deviating from the standard practice of assigning “subject” usernames as owners of contribution activities, adopting Fedora Badges for contribution tracking would require both “subject” usernames (the cause of the message publication event) and “object” usernames (involved in the contribution activity) to possess ownership of a contribution activity.
In the context of a contribution event, let us consider a scenario involving “Member X,” who possesses the authority to bestow “Badge A” upon individuals who successfully complete “Task B.” In this case, “Member X” awards “Badge A” to “Member Y.” However, due to the non-technical nature of this contribution, the Fedora Badges’ Message Consumer entity fails to automatically track the occurrence of “Member Y” performing “Task B” with reliability. The act of awarding the badge serves as confirmation for two distinct contribution activities. The first activity involves “Member Y” carrying out “Task B,” while the second activity entails “Member X” granting “Badge A” to “Member Y.” In essence, “Member Y” is responsible for the primary contribution, but they depend on “Member X” to receive the badge for their contribution to be accurately recorded. On the other hand, the act of awarding the badge itself constitutes a separate contribution, making “Member X” the owner of this secondary activity.
This method should only be employed as a final recourse for monitoring non-technical contributions that do not automatically generate a message on the Fedora Messaging bus upon occurrence. Since the badges cannot be closely linked to the contribution activity itself and the tracking process is manual in nature, they are highly susceptible to being left untracked. This can happen if the contribution owner forgets to claim a badge when they perform the contribution activity, or if the badge facilitator is unavailable and causes delays in tracking the activity. Additionally, there is a risk of unfair tracking, such as the badge facilitator granting a specific badge to their friends who may not have actually completed the corresponding contribution activity, or random individuals claiming the badge through the associated link in bad faith. In the broader context, this will significantly skew the contributor statistics in a negative manner.