#74: Moving off of Trac to someting ------------------------+--------------------- Reporter: bex | Owner: Status: new | Priority: normal Component: Board Meta | Resolution: Keywords: | ------------------------+--------------------- Comment (by jflory7): Hi all! Sorry for taking so long to circle back to this ticket. Some of my thoughts are down below. = Pagure vs. Bugzilla vs. $OTHER = I think it is especially important for the Fedora Council to consider using Pagure as the targeted platform for migrating to. The primary reason for me emphasizing this is that most of the Fedora community using Trac / FedoraHosted is being guided towards Pagure as the new home for tickets, codebases, and discussion. Even though the Council is strictly a ticket- based team, I think it's important to use Pagure to help keep the Council accessible to project members. Bugzilla is not an easy-to-use tool as far as someone who may be of a non- technical background (thinking of Marketing / community / translations types of contributors), so I think using something like Bugzilla would isolate a fair number of contributors who may need to file a ticket to reach the Council's attention. Pagure has a fairly easy-to-use GUI and it shouldn't be too hard for a contributor to log in, file an issue and format it with markdown, and submit. Additionally, there are some nice Pagure fedmsg hooks that may be of use that would be harder to capture with another platform like Bugzilla, Taiga, or something outside of Fedora. = Migration toolset = Using Pagure also ensures easy migration of past discussions and tickets from this Trac. Members of the Infrastructure team are developing the [https://pagure.io/pagure-importer pagure-importer] tool, which cleanly exports data from a FedoraHosted Trac instance and moves it to a Pagure ticket repository. As far as I know, no other tools or platforms will preserve history like we are able to do with Pagure (if there are ways to do this for other platforms, I wonder how easy something like that is to do). This tool is under active development, but does work well for most Trac=>Pagure migrations I've tried. This tool alone makes Pagure an attractive option to move to. = Examples = There's a few ticket-based teams so far that are avidly using Pagure as a Trac replacement or alternative. You can see some of them below (explanations of the types of workflows they're using are explained farther down). * [https://pagure.io/fedora-commops/ fedora-commops] * [https://pagure.io/fedora-marketing fedora-marketing] * [https://pagure.io/fedora-diversity fedora-diversity] * [https://pagure.io/i18n i18n] I've helped set up / migrate the CommOps, Marketing, and Diversity team repos, so I'll base my explanations off of those teams. = Components to tags = The Council Trac usings components to "categorize" tickets into relevant subject areas for people to submit their tickets for. This feature can be replicated within Pagure with tags, and although it's shown in a different manner than it is with Trac, it's an effective way to categorize tickets based on main subject areas. There's actually a flag in the [https://pagure.io/pagure-importer pagure-importer] to export things like components and keywords into Pagure tags. It requires a little manual cleanup, but it helps preserve components in Trac Pagure tags without too much manual work. Additionally, milestones are also super easy to set up and use, so it would be easy to further categorize tickets in the Council Pagure to Fedora releases (e.g. Fedora 25, Fedora 26, Fedora 27, "Future releases", etc.). This could be a helpful way to ensure that tickets are dealt with in a timely manner within each release cycle. ---- Although I may be a little biased based on personal preference, I find Pagure a **great** replacement for Trac and I whole-heartedly recommend it to the Council for consideration. -- Ticket URL: <https://fedorahosted.org/council/ticket/74#comment:10> council <https://fedorahosted.org/council> Fedora Council Public Tickets _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx