Hi Pagure Community, During a recent office hours on IRC, I was asked, actually reminded, that the analysis of Pagure had yet to be sent. My apologies for this and thank you Defolos for the reminder :) and for holding me accountable! The below text was lifted from an internal google document used by CPE management and above, when discussing what gitforge option to pursue, and copied to this hackmd file for convenience for readers who are using terminals, etc to consume. I hope this email serves an information sharing purpose and even possibly a roadmap of sorts of improvements that I have no doubt are either being actively worked on or could be developed in Pagure, and I look forward to the good conversations this may generate. # GitForge Decision Considerations Recently, the Community Platform Engineering (CPE) team who look after both the Fedora and CentOS Communities ran an analysis on what their future Gitforge needs would look like. As part of that, we analysed Pagure and in our follow on discussions we promised to feed back into the Pagure community the gaps as we saw them which played a part in our decision making process. The text below can be ported to various issues, just let us know the most appropriate location and we are happy to offer our assistance in fleshing these out. Please note that this is a requirements driven view of the capabilities of Pagure and is not a slight at the work the community and indeed the CPE team have put into this project over the years. We deeply appreciate the efforts of all contributors and we hope that this mail is insightful and helps to build a strong Pagure. ## Technical Recommendations: A number of technical requirements that Pagure would need to consider to meet some of our requirements are as follows: ### Additional Single Sign On (SSO) Integration The CPE team work closely with the RHEL, CentOS and Fedora projects and the ability to have a workflow within the gitforge means a need for SSO integration with those systems is a key need. ### Reliability & Performance Some projects that host Pagure and wish to operate on a high uptime backed by a Service Level Agreement (SLA) -- where uptime is measured in the 99.9% bracket -- are unable to do so without additional considerations already present within the Pagure project. Currently all CPE can offer are general Service Level Expectations (SLE). To enable an SLA, it’s partly additional resourcing to help ensure uptime but a huge investment is required in API monitoring to spot a problem and try and resolve it prior to an issue taking the service off the air. Pagure needs extensive work on API monitoring to improve the ability to transition this from an towards a viable SLA model. Right now there are 6 Nagios checks running on Pagure which the CPE team have created. SLA levels are in the thousands of Nagios Checks (>10k in many cases) to help us understand where improvements need to go and what is causing issues. Pagure is resource heavy and numerous tickets have noted the sluggishness of Pagure (multiple reported issues on PR creation and searching). To solve issues like this, we need observability and even then the route fix might be re architecture of core components to leverage more redundancy and create a means for resiliency whereby individual failures will not take down the entire service. That deep level of architectural analysis would be highly recommended and if CPE can help we are more than happy to offer our expertise. ### Team Collaboration Features Pagure is lacking several key features in team collaboration: inline images in PRs a full suite of PR comments [1] features to allow richer reviews on PRs the ability to collaborate on project planning capabilities (Kanban boards) including linking of issues through to PRs. The ability to infer stats from your codebase and insights for improvements. The ability to migrate issues easily between projects. The ability to rename or move projects between namespaces. The ability to edit tags[1,2] on issues and the ability to cleanup forks through the API. The ability to allow for a better granularity of which events are sent on the webhook to facilitate integration with other applications collaboration of apps through webhooks. While a webhook functionality exists, this is all or nothing approach, whereby every event triggers the hook or none do. In short, the day to day working of a team and collaboration within a project is right now not optimal ### Accessibility and User Interface(UI)/User Experience (UX): Pagure has multiple accessibility compliance issues. While some of these issues are easy fixes, many obvious issues relate to style and theming. The overall UX has a number of issues which need a modern refresh to make the system more amenable to new users of a Git Forge or those familiar with other forge UIs who might struggle with concepts like merging and conflicts [1,2]. Discovery of projects or issues is difficult [3] which hampers attempts at drive by contributors to discover and partake. Attracting and lowering the barrier for new users and particularly those who do not have a strong background in the usage of git was a focal point of several requirements. ### Workflow Integrations Pagure has integrations with other standalone services to help facilitate workflow integrations and general Continuous Integration (CI)/ Continuous Deployment (CD) capabilities. While the integrations are positive, it blooms the scope of responsibility, as addressing Pagure means by extension addressing the individual components that help to plug feature gaps within Pagure. This extends our SLA coverage by an order of magnitude. Additional considerations here are the all or nothing nature of the webhooks which makes integrations with other tooling more problematic (e.g. automatic build triggers) Take care everyone and have a lovely weekend, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford