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.
As a Fedora contributor, I want the git forge to be self-hosted so that
Fedora is not dependent on third parties
As a Fedora contributor, I want the git forge to be free/open source
software so that Fedora lives up to its Freedom value.
so that it is privacy-friendly.
As a Fedora contributor, I want the git forge to integrate with FAS so
that it can use FAS to provide authentication and authorization.
As a Fedora contributor, I want the git forge to integrate with
fedora-messaging so that it can be a part of automatic workflows.
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
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.
[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.
[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.
[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.
[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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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
As a package maintainer, I can adopt any orphaned dist-git repo or
branch so that it has an active maintainer.
As a package maintainer, I can easily unretire a retired dist-git repo
or branch so that it has an active maintainer.
As a release engineer, I can easily approve unretire requests for a
dist-git repo or branch so that it has an active maintainer.
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.
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
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.
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
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.
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.
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
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.
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
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
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.
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
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.
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.
As a Fedora contributor, I can use a public API so that I can develop
workflow tools for myself and my team.
As a repository admin, I can define custom labels for a repo so that it
can support my team’s particular workflow.
As a repository admin, I can define arbitrary custom fields for a repo
so that it can support my team’s particular workflow.
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.
As a Fedora team member, I can vote +1/abstain/-1 on issues so that I
can approve or deny proposals.
As a Fedora contributor, I want issues to support inline images in order
to simplify the workflow for visual tasks (e.g. design work)
As a Fedora contributor, I want a Kanban board so that I can visually
track the status of work and do project planning.
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.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream