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.
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 maintainer of.
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.
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 adopt it.
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 remains intact.
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 about.
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 are supported.
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 low-friction manner.
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.
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 packages.
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 -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org