56 lines
3.7 KiB
ReStructuredText
56 lines
3.7 KiB
ReStructuredText
.. _solution_probntec.rst:
|
|
|
|
Conundrum of Tracking of Non-Technical Contributions
|
|
====================================================
|
|
|
|
Problem statement
|
|
-----------------
|
|
|
|
Interactions with services are the sole means by which messages are published on the
|
|
`Fedora Messaging <https://fedora-messaging.readthedocs.io/>`_ 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 <https://fedora-arc.readthedocs.io/en/latest/badges/index.html>`_
|
|
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.
|
|
|
|
Probable workaround
|
|
-------------------
|
|
|
|
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.
|