On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin <lgrif...@redhat.com> wrote: > >> Can we *please* see the final actual definitely official Fedora list, >> then? If this is supposed to be an open process? > @Ben Cotton can oblige here, it's not my place to share it without a > stakeholder approval.
The list sent to CPE is below. While there was no intent to hide it (it can be reconstructed from the council-discuss thread), it was a mistake on my part to not explicitly post this at the end of the discussion. 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 independent software or distro developer, 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 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. As a Fedora contributor, I can reassign issues/bugs to another component so that I can cooperate with other contributors when an issue is mis-assigned. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
