Council and community,

The community input period for CPE's git forge initiative is over. I have collected and distilled the mailing list feedback into the list below. Please comment by the *end of this week* so we can send Fedora's requirements to the CPE team.

  1. As a Fedora contributor, I want the git forge to be self-hosted so that Fedora is not dependent on third parties

  2. As a Fedora contributor, I want the git forge to be free/open source software so that Fedora lives up to its Freedom value.

  3. As anybody, I want the git forge to have no JavaScript/cookie tracking so that it is privacy-friendly.

  4. As a Fedora contributor, I want the git forge to integrate with FAS so that it can use FAS to provide authentication and authorization.

  5. As a Fedora contributor, I want the git forge to integrate with fedora-messaging so that it can be a part of automatic workflows.

  6. As a Fedora contributor, I want it to be easy to add new contributors to a project (and optionally to enable self-adding) so that joining new teams is low-friction.

  7. As a Fedora community member, I want to self-organize my personal and team work by creating projects and groups of projects, by defining different access levels, and by having basic contribution allowed for everyone by default, so that I can contribute in full autonomy.

  8. [dist-git] As a Fedora contributor, I want the dist-git to integrate with other packaging services (anitya, koji, Bodhi, etc) so that it can be a part of automatic workflows.

  9. [code hosting] As a Fedora contributor, I want to encourage new contributors with easyfix-like functionality so that newcomers can find easy tasks to get started with.

  10. [code hosting] As anyone, I want good search of code, commits, and issues so that I can find particular parts of the code or project history.

  11. [code hosting] As a software maintainer, I want pull requests to allow me to rebase so that I can accept pull requests without waiting for the submitter to rebase.

  12. As anyone, I want the URI to the archive (tar.xz, tar.bz2, etc) corresponding to various code states (commit/tag/release/fork…) to be regular and stable (ideally, identical to the Pagure URIs to avoid reimplementing existing automation) so that I can point to point-in-time snapshots of the repository.

  13. As a Fedora contributor, I want the git repos to be fully accessible over https (read and write) so that I can contribute from environments where ssh is filtered for security reasons.

  14. As a drive-by reader of Fedora docs, I want to click through to make a suggested improvement without needing to set up a whole code-development infrastructure so that I can make low-friction contributions.

  15. As a Fedora user, I want to easily create pull requests to any dist-git repo so that I can make contributions to repos that I am not a maintainer of.

  16. As a package maintainer, I can only commit to a dist-git repo if I am in the Fedora packager group so that non-packagers cannot directly affect packages.

  17. As a package maintainer, I can only commit to a dist-git repo if I am a maintainer of the branch so that EPEL maintainers and Fedora maintainers can be separate.

  18. As a proven packager, I can commit to all dist-git repos that do not have special restrictions set by FESCo or are retired so that I can make bulk package updates or step in as directed by FESCo.

  19. As a FESCO member, I can configure exceptions to disallow proven packager access to a dist-git repo so that I can protect key packages.

  20. As dist-git repo admin, I can easily add other maintainers to allow commit or admin access for dist-git repo by using their FAS username so that I can enable others to co-maintain a package.

  21. As a dist-git repo admin, I cannot remove access to the repo from Fedora infra, Releng or proven packagers without FESCo approval so that Releng, infra, and provenpackagers have the ability to perform their functions.

  22. As a package maintainer, I can easily orphan a dist-git repo or branch to show that it is not maintained anymore so that other maintainers can adopt it.

  23. As a package maintainer, I can adopt any orphaned dist-git repo or branch so that it has an active maintainer.

  24. As a package maintainer, I can easily unretire a retired dist-git repo or branch so that it has an active maintainer.

  25. As a release engineer, I can easily approve unretire requests for a dist-git repo or branch so that it has an active maintainer.

  26. As anybody, I can easily see the FAS usernames of maintainers for all branches of a dist-git repo so that I know who to contact.

  27. As a non-releng member, I cannot remove any commits from any dist-git repo that were used to build a Fedora package so that the release history remains intact.

  28. As an external user, I can easily get a list of all orphaned or retired dist-git repos and branches so that I know what packages need maintainers.

  29. As anybody, I can watch for issues or pull requests that are created for a dist-git repository so that I can stay up-to-date on repositories I care about.

  30. As anybody, I can easily get a list of all dist-git repos that I am watching so that I can be sure it matches my current needs.

  31. As anybody, I can easily get a list of all dist-git repos that a specific Fedora account has admin/commit access to so that I can see what packages the account is associated with.

  32. As anybody, when looking at the dist-git repo it is clearly visible which branches are still maintained so that I know what release versions are supported.

  33. As anybody, when I look for a specific branch, EOL branches do not clutter my view so that I can more easily see the active branches.

  34. As a package maintainer, I can easily request commit/admin access for a specific branch or dist-git repo so that I can help contribute in a low-friction manner.

  35. As Fedora infra, I can easily audit that no git repo was accessed without authorization so that I can maintain the security of the Fedora infrastructure.

  36. As Fedora infra/security response team, I have access to secure logs to analyse the impact of unauthorized access to all dist-git repos so that I can maintain the security of the Fedora infrastructure.

  37. As anybody, the dist-git web page of a repo points me to Bugzilla to report issues for a repository so that I can file bugs for released packages.

  38. As an ISV developer who contributes to Fedora, I can fork a dist-git repo via mirroring, make changes, and submit them back to Fedora as applicable so that I can contribute to Fedora.

  39. As a distro developer, I can fork dist-git repos via mirroring, make changes, and submit them back to Fedora from my Git server so that I can contribute to Fedora.

  40. As a Fedora contributor, I can use a public API so that I can develop workflow tools for myself and my team.

  41. As a repository admin, I can define custom labels for a repo so that it can support my team’s particular workflow.

  42. As a repository admin, I can define arbitrary custom fields for a repo so that it can support my team’s particular workflow.

  43. As a Fedora contributor, I can file bugs and feature requests in an issue tracker so that I can provide feedback or track desired work.

  44. As a Fedora team member, I can vote +1/abstain/-1 on issues so that I can approve or deny proposals.

  45. As a Fedora contributor, I want issues to support inline images in order to simplify the workflow for visual tasks (e.g. design work)

  46. As a Fedora contributor, I want a Kanban board so that I can visually track the status of work and do project planning.

  47. As a Fedora contributor, I can perform issue and pull request actions on mobile devices via a native mobile app or a mobile-friendly webapp so that I can contribute while away from my desk.



--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis