93 lines
4 KiB
ReStructuredText
93 lines
4 KiB
ReStructuredText
Fedora Badges
|
|
====
|
|
|
|
Purpose
|
|
----
|
|
|
|
Fedora Badges is a service that grants virtual accolades for milestones and
|
|
completing tasks within the Fedora Project community. For example, a community
|
|
member may collect badges for testing package updates on Bodhi when they test
|
|
1, 5, 10, 20, 40, 80, 125, 250, 500 and 1000 updates.
|
|
|
|
Community members can also gather badges for attending events, or other badges
|
|
that are arbitrarily granted by users of the service, such as the badge the
|
|
Fedora Project Leader can grant whenever they want to.
|
|
|
|
Background
|
|
----
|
|
|
|
It appears that Fedora Badges was initially designed closely in step with
|
|
`Open Badges <https://en.wikipedia.org/wiki/Mozilla_Open_Badges>`_ which now
|
|
has become `Badgr <https://badgr.com/>`_. As far as we can tell, the idea was
|
|
previously to be able to export Fedora Badges into Mozilla Backpack (or now,
|
|
Badgr Backpack) but this export facility was either never implemented or
|
|
deployed.
|
|
|
|
At some point in time, there also appears to have been an
|
|
`free and open source implementation of the Badgr server <https://github.com/concentricsky/badgr-server>`_
|
|
itself, which may have been a solution to replace the Fedora Badges setup, but
|
|
this project is either no longer available or set to be private on GitHub, so
|
|
it is not known what it was or is. For now, Badgr is just a service that
|
|
allows users to collate their badges from different issues into their
|
|
"backpack".
|
|
|
|
Resources
|
|
----
|
|
|
|
* `Fedora Badges backend <https://github.com/fedora-infra/fedbadges/>`_
|
|
* `Fedora Badges frontend <https://github.com/fedora-infra/tahrir>`_
|
|
* `Issue ticket about the ongoing efforts of revitalization <https://github.com/fedora-infra/fedbadges/issues/90>`_
|
|
* `Infrastructure developer guide <https://docs.fedoraproject.org/en-US/infra/developer_guide/>`_
|
|
* `Badges documentation in Fedora docs <https://docs.fedoraproject.org/en-US/badges/>`_
|
|
|
|
Index
|
|
----
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
current_implementation
|
|
exploring_the_development_environment
|
|
expectations_and_wishes
|
|
proposal_rewrite
|
|
proposal_revitalize
|
|
|
|
Conclusions
|
|
----
|
|
|
|
Having explored both the options (i.e. of rewriting the project that consitute
|
|
the system from ground up and of revitalizing the existing codebase), we have
|
|
come to a conclusion that it makes a lot more sense to inherit and expand upon
|
|
the methodologies employed in the current codebase but implement the same from
|
|
groundup in a new functional rewrite.
|
|
|
|
Proposed roadmap
|
|
----
|
|
|
|
* Step 1 - Understand the project remit of the system to decide on the scope
|
|
* Step 2 - Get started with creating/inheriting the database schema for users
|
|
* Step 3 - Dump a snapshot of the existing database according to the new schema
|
|
* Step 4 - Brainstorm and document the interactions expected with the system
|
|
* Step 5 - Connect with the Fedora Design team to begin with the mockup designs
|
|
* Step 6 - Develop and document the Messages Consumer alongside Accolades API
|
|
* Step 7 - Test both against the dumped database and the existing Collection
|
|
* Step 8 - Develop and document the Accolades CLI and test its functionality
|
|
* Step 9 - Build Liberation frontend alongside the Fedora Websites & Apps Team
|
|
* Step 10 - Document and Test the frontend against the above mentioned entities
|
|
* Step 11 - Deploy and document the system on STAGING with the Fedora Infra team
|
|
* Step 12 - Release Accolades CLI as a Python package on PyPI and as RPM
|
|
* Step 13 - Announce public testing invites for the staging deployment
|
|
* Step 14 - Announce deprecation status for the existing Fedora Badges system
|
|
* Step 15 - Migrate database changes continually to keep up with the changes
|
|
* Step 16 - Switch the environment to production and... PROFIT?
|
|
|
|
Of course, there are and will be more things to account for than what meets
|
|
the eye but from a Mount Everest high perspective - these are the steps we
|
|
would want to suggest in the roadmap.
|
|
|
|
Estimate of work
|
|
----
|
|
|
|
Being a remake of a system with multiple internal entities working together,
|
|
it is estimated for the system to take at least 4 quarters to hit the staging
|
|
environment and 1 more quarter to make it to the production one.
|