93 lines
4.1 KiB
ReStructuredText
93 lines
4.1 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
|
|
proposal_rewrite
|
|
proposal_revitalize
|
|
discourse_integration
|
|
|
|
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.
|