User stories

Gathered

Following is the investigation on GitLab based on the user stories collected.

1. As a package maintainer, I’d like to be able to run my own CI jobs on distgit PRs.

   Reported by Maxwell G (gotmax23)

2. As a package maintainer, I’d like to be able to control the-new-hotness monitoring status from distgit.

   Reported by Maxwell G (gotmax23)

3. As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.

   Reported by Maxwell G (gotmax23)

4. As a package maintainer and Fedora tooling maintainer, I’d like to be able to use Packit in both distgit and upstream repositories.

   Reported by Maxwell G (gotmax23)

5. As a package maintainer, I’d like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.

   Reported by Maxwell G (gotmax23)

6. As a packager sponsor/mentor, I’d like to help users from outside the packager make their first PR without requiring special tooling or authentication schemes.

   Reported by Maxwell G (gotmax23)

7. As a package maintainer and tooling maintainer, I’d like to be able to set Depends-on: and Blocks: relationships between tickets in the issue tracker.

   Reported by Maxwell G (gotmax23)

8. As a package maintainer, I’d like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.

   Reported by Maxwell G (gotmax23)

9. As a package maintainer, I want to be able to control all aspects of the pull request process (read comments, reply to comments, approve PRs, merge PRs, etc) via an REST API to allow creation command line tools to automate work that otherwise requires a pointy-clicky web UI.

   Reported by Daniel P. Berrange (berrange)

10. As a package maintainer, I want to be able to mark a PR to automatically merge if-and-only-if a running CI pipeline has succeeded. This allows reviewing and approving a PR, and moving onto new work, without having to wait around to see if CI passes or not. The PR only needs re-visiting manually if CI failed.

    Reported by Daniel P. Berrange (berrange)

11. As a contributor, I want to be able to see who the current maintainer(s) are for a package.

    Reported by Daniel P. Berrange (berrange)

12. As a contributor, I want to be able to request to join the maintainer(s) for a package, either as a watcher (just notified of all PRs), or as a developer (participate in MR process), or as a maintainer (control all aspects of the package, ie user ACLs). Joining as merely a watcher should not require approval by current maintainers.

    Reported by Daniel P. Berrange (berrange)

13. As a package maintainer, I want opening a MR to automatically create a scratch-build. Approving the MR, should be able to either automatically promote the scratch-build to non-scratch status, or create a new non-scratch build. The latter should have a way to disable for packages with huge build times where creation of one build for multiple approved MRs is desirable for efficiency.

    Reported by Daniel P. Berrange (berrange)

14. As a package maintainer, I would like to see the dependencies of this package, and what packages that are required by this package on web UI.

    Reported by Felix Wang (topazus)

15. As a contributor, I want to be able to see who the current maintainer(s) are for a package.

    Reported by Fernando Dos Santos (ferox)

16. As a contributor, I want to be able to see the contributors that have contributed to this package.

    Reported by Felix Wang (topazus)

17. “As a packager I want to be able to have commit access without being added to the bugzilla watch list.

    Reported by Pierre-Yves Chibon (pingou)

18. As a community member I want the ability to be added to the bugzilla watch list for a package without having commits or being in the packager group.

    Reported by Pierre-Yves Chibon (pingou)

19. As a Fedora Infrastructure member, I want to ensure people who sign in to watch a package on bugzilla have a valid bugzilla account associated with their FAS account.

    Reported by Pierre-Yves Chibon (pingou)

20. As a user of Fedora, not necessarily a member of the Fedora Project, I want to receive information about Fedora packages in the form of readable HTML documents, not in the form of programs (in Javascript or Web Assembly) that I must execute before I get to see the information.

    Reported by Bjorn Persson (romboberorn)

21. As a security-conscious packager, I want to interact with the web interface without downloading and running programs from a bunch of third parties. I should at most need to whitelist Javascript and Web Assembly from fedoraproject.org only.

    Reported by Bjorn Persson (romboberorn)

22. As a member of the Free Software movement, I want all parts of the system to be Free Software. That includes both server-side software and all Javascript, Web Assembly and/or CSS that my browser will download and execute.

    Reported by Bjorn Persson (romboberorn)

23. As a package maintainer, I want to be able to use a pull-request-only workflow for specific packages (like packages that could break a lot of things, or packages that are security sensitive).

    Reported by Fabio Valentini (decathorpe)

24. As a package maintainer with provenpackager or scm-admin rights, I want to be able to circumvent pull-request-only requirements on packages when pushing changes (i.e. mass rebuilds).

    Reported by Fabio Valentini (decathorpe)

25. As a package maintainer, I’d like existing STI and TMT CI tests to continue working while also providing a simpler, more familiar YAML-based format.

    Reported by Daniel P. Berrange (berrange)

26. As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.

    Reported by Robert-Andre Mauchin (eclipseo)

27. As a package maintainer, I want to be able to deal with bugs directly from the forge, and be able to reassign them between projects.

    Reported by Robert-Andre Mauchin (eclipseo)

28. As a package maintainer, I want to be able to sync a fork with the upstream with a button click.

    Reported by Robert-Andre Mauchin (eclipseo)

29. As a package maintainer, I wish we had CI compatible with Github Actions.

    Reported by Robert-Andre Mauchin (eclipseo)

30. As a contributor, I’d like to be able to interact with git and distgit via email, namely to reply to issue and PR comments.

    Reported by Maxwell G (gotmax23)

31. A contributor, I’d like to be able to create repositories under a personal namespace for work related to Fedora.

    Reported by Maxwell G (gotmax23)

32. As a package maintainer, I’d like to block branch creation outside of official ones, or remove branches outside of official ones.

    Reported by Robert-Andre Mauchin (eclipseo)

33. As a contributor, I’d like the forge to be accessible (alt text for images, respecting whatwg standards for contrast, color blindness, aria support).

    Reported by Robert-Andre Mauchin (eclipseo)

34. As a package maintainer I’d like to be able to delete a wrong file from the look aside cache.

    Reported by Robert-Andre Mauchin (eclipseo)

35. As a package maintainer, I’d wish to be able to see a tree of the Depends-on and Blocks bugs relationship, and export it to JSON or any easily processable document.

    Reported by Robert-Andre Mauchin (eclipseo)

36. As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.

    Reported by Robert-Andre Mauchin (eclipseo)

37. As a package maintainer, I still want to be able to use Grokmirror to mirror the Forge packages locally.

    Reported by Robert-Andre Mauchin (eclipseo)

38. As an engineer involved in the release process, I want to be able to track blocker bugs and freeze exception bugs in the chosen issue tracker.

    Reported by Akashdeep Dhar (t0xic0der)

39. As an engineer involved in the release process, I want to be able to properly triage the state of the blocker bugs and freeze exception bugs with Kanban boards.

    Reported by Akashdeep Dhar (t0xic0der)

40. As an engineer involved in the release process, I should be able to notify the affected package maintainers and package testers.

    Reported by Akashdeep Dhar (t0xic0der)

41. As an engineer involved in the release process, I want to be able to plan for the effects on release phases (Alpha, Beta, Final) using the Gantt chart.

    Reported by Akashdeep Dhar (t0xic0der)

42. As an engineer involved in the release process, I want to be able to control the automated building and testing using comments.

    Reported by Akashdeep Dhar (t0xic0der)

43. As an engineer involved in the release process, I want to be able to triage the priorities of the blocker bugs and freeze exception bugs in the chosen issue tracker.

    Reported by Akashdeep Dhar (t0xic0der)

44. As an engineer involved in the release process, I want to be able to speed up the creation of blocker bugs and freeze exception bugs with the use of issue ticket templates.

    Reported by Akashdeep Dhar (t0xic0der)

45. As an engineer involved in the release process, I want to be able to limit the access of ticket modification to a certain set of people.

    Reported by Akashdeep Dhar (t0xic0der)

46. As an engineer involved in the release process, I want to be able to access the chosen issue tracker with the use of an HTTP API.

    Reported by Akashdeep Dhar (t0xic0der)

47. As an engineer involved in the release process, I want to be able to show related issue tickets to the reporter to avoid repeated rejections.

    Reported by Akashdeep Dhar (t0xic0der)

48. As an engineer involved in the release process, I want to be able to use the already established Bug Status Workflow as closely as possible.

    Reported by Akashdeep Dhar (t0xic0der)

49. As an engineer involved in the release process, I want to be able to automate ticketing workflows according to the phases of a release.

    Reported by Akashdeep Dhar (t0xic0der)

50. As an engineer involved in the release process, I want to be able to track accepted previous release blocker bugs in the chosen issue tracker.

    Reported by Akashdeep Dhar (t0xic0der)

51. As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.

    Reported by Aoife Moloney (amoloney)

52. As a developer/release engineer/QA/contributor, we need the new dist-git service to have hooks to attach new and existing CI pipelines.

    Reported by Aoife Moloney (amoloney)

53. As a contributor, I need to be able to login using my Fedora account.

    Reported by Aoife Moloney (amoloney)

54. As a developer, I would like there to be a separate staging and production instance of dist-git so I can test my changes before pushing them.

    Reported by Aoife Moloney (amoloney)

55. As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.

    Reported by Aoife Moloney (amoloney)

56. As a maintainer, I would like an easy-to-use interface to make suggestions on individual code blocks and suggest changes that the submitter can simply apply.

    Reported by Maxwell G (gotmax23)

57. As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).

    Reported by Maxwell G (gotmax23)

58. A package maintainer, I would like a push hook to block pushes to retired or EOL branches

    Reported by Maxwell G (gotmax23)

59. As a package maintainer, I want to be able to grant access to specific branches, or branches matching a pattern, to individual users. In pagure this is referred to as collaborator access.

    Reported by Carl W. George (carlwgeorge)

60. As a policy enforcer, I want to be able to “orphan” packages that are not mine.

    Reported by Miro Hroncok (churchyard)

61. As a developer, I want to be query packages by their maintainers and vice versa.

    Reported by Miro Hroncok (churchyard)

62. As a packager, I need the new forge to support the orphaned packages process: a maintainer should be able to automatically orphan a package they own and another packager should be able to take ownership through a self-service interface.

    Reported by Maxwell G (gotmax23)

63. As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.

    Reported by Miro Hroncok (churchyard)

64. As a driveby contributor, who is not a provenpackager (or does not want to use their provenpackager rights), I need to be able to open a Pull Request/Merge Request which introduces zero code changes (it has only empty commit(s) to bump the release for packages using %autorelease).

    Reported by Miro Hroncok (churchyard)

65. As a proven packager, I want to be able to do basic repo operations from the command line. For example, I have the following in my history fedpkg fork && git remote rename zbyszek my && git push my rawhide:bin-sbin-merge, which I used maybe a hundred times when working on packages for the bin-sbin merge. I would then click on the link printed by the push command and review the diff before submitting a pull request and possibly adjust the commit message. Generalizing from this, all operations like forking, merging and closing of pull requests, should be possible via a command line tool. The tool must also be packaged in Fedora.

    Reported by Zbigniew Jędrzejewski-Szmek (zbyszek)

66. As a documentation contributor, I would love to try out new Git forge test systems. I’m agnostic to tools, so I believe I can spend time on UX and docs workflow (build, preview, issue tracking, GitHUb Action-like features and so on).

    Reported by Hank L (hankuoffroad)

67. As a member of the CDT team I need to be able to get notified automatically when someone opens a design request. (An email will be sent to a mailing list).

    Reported by Julia Bley (jbley)

68. As a member of release engineering, I need to be able to enforce that all repos in dist-git disallows the rewriting of history. (There’s nuance here; it might be okay to allow rewriting on non-standard branches, but we’d need a way to confirm that none of the affected commits were ever used to perform an official build. This is probably more effort than it’s worth vs simply disallowing rewriting on any branch)

    Reported by Stephen Gallagher (sgallagh)

69. As a packager/user, I’d like to be able to easily determine which commits were used in the creation of particular Fedora builds. A preferred mechanism for this would be to have hooks in place that can automatically commit git tags (signed with an official GPG signature) indicating associated NVRs.

    Reported by Stephen Gallagher (sgallagh)

70. As a packager, I’d like to be able to use “draft builds” in merge requests that are then promoted to official builds when the MR is merged. This is to ensure that the build that was tested and approved in the MR is the same one that gets submitted as an erratum.

    Reported by Stephen Gallagher (sgallagh)

71. As a packager, I’d like the option to have packages submitted as an erratum automatically when a merge request is merged. Ideally, this would be supplemental to the above “draft builds”, just submitting that exact build to errata.

    Reported by Stephen Gallagher (sgallagh)

72. As a packager, I’d like to be able to provide my own test pipelines for merge requests on individual projects (supplemental to any standard tests provided and/or required by Fedora).

    Reported by Stephen Gallagher (sgallagh)

73. As a member of Fedora Quality, I need to be able to transparently move any ticket opened by any user for one package to another package and preserve history.

    Reported by Tomas Hrcka (thrcka)

74. As a member of Fedora Quality, I would like to be able to define ticket submission form templates with custom fields. And create input validations and query all opened tickets based on those field definitions.

    Reported by Tomas Hrcka (thrcka)

75. As a member of Fedora Quality, I need to be able to specify “need_info” on a specific ticket. This function should regularly ping (email/matrix or any other channels) the specified user that I am requesting information from.

    Reported by Tomas Hrcka (thrcka)

76. As a policy enforcer, I need to be able to get all the information about a ticket/issue/bug from a Python script in a structured way.

    Reported by Miro Hroncok (churchyard)

77. As a policy enforcer, I need to be able to open/modify/comment on a ticket/issue/bug from a Python script (including all the possible metadata).

    Reported by Miro Hroncok (churchyard)

78. As a policy designer, I need to be able to add custom and structured metadata to a ticket/issue/bug, in the form of key=value pairs. I need to be able to set rules for individual keys (such as which values are valid).

    Reported by Miro Hroncok (churchyard)

79. As a package maintainer, I want to have syntax highlighting for RPM spec files in the git forge web interface. Currently Pagure and Forgejo have this, but GitLab does not.

    Reported by Carl W. George (carlwgeorge)

80. As a Fedora Badges junkie, I want to be able to receive badges for activities related to dist-git. In technical terms, the dist-git activities must be broadcast to the Fedora Message Bus (or however it’s called nowadays).

    Reported by Miro Hroncok (churchyard)

81. Scalability - As a SaaS administrator, I want the system architecture to support scalability, manually or automatically based on demand, so that we can maintain optimal performance during traffic spikes and efficiently handle user growth.

    Reported by David Kirwan (dkirwan)

82. ** Reliability and High Availability - User Story: As a SaaS administrator, I want the service architecture to be highly available, to ensure 24/7 operation with minimal downtime, so that end users may access and use the application whenever needed without interruptions.**

    Reported by David Kirwan (dkirwan)

83. Security - User Story: As a SaaS administrator, I want robust security measures implemented across our infrastructure, including encryption, access controls, and regular security audits, so that we can protect our end users data and maintain their trust.

    Reported by David Kirwan (dkirwan)

84. Security - User Story: As a SaaS administrator, I want to quickly identify when the system is affected by CVEs, so that steps can be taken to plan upgrades to mitigate vulnerabilities.

    Reported by David Kirwan (dkirwan)

85. Monitoring and Observability - User Story: As a SaaS administrator, I want a centralised monitoring and logging system that provides real-time insights into application performance, resource utilisation, and user experience, so that we can quickly identify and resolve issues before they impact users.

    Reported by David Kirwan (dkirwan)

86. Infrastructure as Code (IaC) - User Story: As a SaaS administrator, I want to manage our the system infrastructure using code that we can version control, easily replicate environments, and automate provisioning and configuration.

    Reported by David Kirwan (dkirwan)

87. Multi-tenancy - User Story: As a SaaS administrator, I want the application to be a secure multi-tenant system that efficiently shares resources among end users while ensuring complete data isolation, so that we can serve multiple clients cost-effectively without compromising security.

    Reported by David Kirwan (dkirwan)

88. Disaster Recovery and Backup - User Story: As a SaaS administrator, I want automated backup systems and a comprehensive disaster recovery plan in place, so that we can quickly recover from any unforeseen events and minimise data loss and downtime.

    Reported by David Kirwan (dkirwan)

89. Upgradability - User Story: As a SaaS administrator, I want to apply automated system upgrades, preferrably without causing system downtime, so we can continue to provide service to end users.

    Reported by David Kirwan (dkirwan)

90. Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.

    Reported by David Kirwan (dkirwan)

91. As a maintainer of packages in Fedora, I would like the ability to move a ticket assigned to my project to a new project. As an example, . I get a few tickets every month against “fedora-release” because people just use that as a stand-in for “I don’t know what package to report against”

    Reported by Stephen Gallagher (sgallagh)

92. As a Fedora CI maintainer, I would like to have the ability to enable mandatory checks for each dist-git pull request to ensure Fedora distribution stability.

    Reported by Miroslav Vadkerti (mvadkert)

93. As a Fedora forge administrator, I would like to have legally-enforceable assurances that features available in the open-source (or “community edition”) of the forge will remain that way in the future in order to prevent platform decay from degrading the functionality.

    Reported by Stephen Gallagher (sgallagh)