+     solution_probntec

+ .. _solution_probntec.rst:

+ 

+ Conundrum of Tracking of Non-Technical Contributions

+ ====

+ 

+ As contributions that involve interacting with services are the only ones that

+ publish a message on the 

+ `Fedora Messaging <https://fedora-messaging.readthedocs.io/>`_ bus, they are

+ the only ones that get tracked. These services predominantly facilitate for

+ technical contributions alone and hence, it becomes increasingly difficult to

+ track non-technical contributions. Owing to the wide range of creating non

+ technical contributions and a similarly huge number of subjective methods to

+ keep track of those - it is comparatively difficult to come up with an

+ objective method of describing them. What might look like a contribution to one

+ might not look like a contribution to someone else and therefore, the service

+ would not be able to reliably track non-technical contributions.

+ 

+ One of the workarounds that could help solving this problem is by creating 

+ badges on the 

+ `Fedora Badges <https://fedora-arc.readthedocs.io/en/latest/badges/index.html>`_

+ platform for each type of non-technical contribution. This cannot be a

+ solution as this method scales incredibly poorly as the members go on adding

+ new badges of the manually-awarded kind for tracking each type of non-technical

+ contributions. This could potentially lead to situations where there are

+ thousands of badges pertaining to a type of non-technical contribution but with

+ handful of awardees per badge. Going against the norm of having "subject" 

+ usernames as owners of contribution activities, using Fedora Badges to track

+ contributions would lead to treating both "subject" usernames (cause of the

+ message publication event) and "object" usernames (involved in the said

+ contribution activity) to own a contribution activity.

+ 

+ How? Assuming a contribution event where a "Member X" (who has the access to

+ award a certain "Badge A" to members who do "Task B") awards a "Badge A" to

+ "Member Y". As this was a non-technical contribution and because this could not

+ be automatically tracked by the Fedora Badges' Message Consumer entity - the 

+ event of "Member Y" performing "Task B" could not be reliably and automatically

+ tracked. The event of awarding the badge essentially confirms two contribution

+ activities - the first one being "Member Y" performing "Task B" and the second

+ one being "Member X" awarding the "Member Y" with "Badge A". In the first 

+ contribution activity, the "Member Y" owns the contribution but they are 

+ dependent on "Member X" to award them the badge to have their contribution 

+ tracked. The activity of awarding the badge itself is a contribution so in the

+ second activity, the "Member X" owns the contribution. 

+ 

+ This should be used as an absolute "last ditch effort" to track non-technical

+ contributions of the kind that do not automatically publish a message on the

+ Fedora Messaging bus when they take place. As the badges cannot be tightly

+ associated with the contribution activity itself and the fact that the way of

+ tracking those are manual in nature, they are very susceptible to be left 

+ untracked (due to reasons like the "contribution owner" forgetting to claim 

+ a badge when they made the "contribution activity" or the "badge felicitator"

+ being unavailable when being reached out causing delays in tracking of the 

+ said activity) or to be tracked unfairly (due to reasons like the "badge 

+ felicitator" awarding a certain badge to their friends who might not have done

+ the said "contribution activity" or random members claiming the badge from the

+ associated link in bad faith). In the larger scheme of things - this will end

+ greatly skewing the contributor statistics for the worse.