Thank you very much to everyone who contributed and gave their thoughts and
opinions on how best to move this forward. I appreciate the time, passion
and energy you put into making this happen.
On Mon, Feb 10, 2020 at 7:40 PM Ben Cotton <bcotton(a)redhat.com> wrote:
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 is low-friction.
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
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
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
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
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
council-discuss mailing list -- council-discuss(a)lists.fedoraproject.org
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Cork Road, Waterford City
M: +353877545162 IM: lgriffin