Many components of Fedora Badges are heavily integrated into Trac, and there are unique complications for migrating the Fedora Badges Trac to Pagure. A solution needs to be identified for migrating this Trac.
So, this is not a new topic, and has been discussed in the Infrastructure and Design team mailing lists at different points in time, but I think we need to have a centralized place to discuss this and try to figure out how we want to proceed with doing this. I figured the Infra Pagure would be the best place to host this discussion and track it over time.
Unlike most other Tracs, Fedora Badges has a lot of special considerations for migrating that other projects don't have to consider. I've tried to categorize this things as follows.
Every badge in Tahrir has a "Criteria" field. In the "Criteria" field, we put the link to the ticket where the badge was originally discussed, planned, and implemented. This makes it easy for (1) contributors, to see how to get a badge if it's not immediately clear, and (2) for developers / admins, for investigating history behind a badge that is broken or unclear about how it works.
For example, in the Flock 2015 Attendee badge, there is a link on the published badge page to https://fedorahosted.org/fedora-badges/ticket/366.
Every single badge on badges.fp.o is this way. If we break the domain, the "Criteria" field becomes irrelevant on all of the hundreds of badges we have pushed out now.
There is a series of badges (Badge Muse) that are awarded to people who create tickets in the Fedora Badges Trac and have their tickets closed as "pushed". You can see the Badge Muse (Badge Ideas I) badge as an example. An example pf the fedmsg event shows where the badge is awarded (the example was for one of the later ones in the series for me).
By moving to Pagure, this badge will break and will not be automatically awarded. This should be fixable, but it has to be addressed before we move.
There is another series of badges for designers. Although I think the automated approach for these has been broken for some time, my understanding is that at one time, it was meant to be automated by who a ticket was assigned to in Trac. When the ticket was closed as "pushed", the person who was assigned ownership would be given one of these badges (I may be totally off here on this one, but this has been my understanding). The first badge in this series, Apprentice (Badge Artist I), is an example.
Unlike other Tracs, the Fedora Badges Trac uses heavily customized metadata that was set up and identified at a Design FAD a few years ago. This includes things such as…
has_name
has_description
concept_approved
manually_awarded_
triaged
Most of these things can be easily replaced by Pagure tags, like the boolean options. Priorities are also easy to set up. Things like the artwork and badge definition statuses are a little trickier. I also anticipate that over time, if we don't map out a way to ensure tickets are properly tagged, this will become something that we forget to do, and the tickets for Fedora Badges will become extremely disorganized (this is one of my biggest fears about migrating to Pagure for this specific Trac). One of the affordances of us using Trac for this is that these fields are permanent and cannot be forgotten – so they are always present and set in a ticket one way another.
To understand how all of this metadata affects the Fedora Badges workflow, it's important to see the Reports page of the Fedora Badges Trac. There are several custom reports that are helpful for both designers, admins, and contributors for tracking tickets in different stages. For example, for me, it's easy for me to quickly see badges that are artwork approved and need to be pushed in one click. It's easy for a designer to see badges that need artwork (especially useful for new badge designers since a lot of people in Fedora Design get started with badges).
Additionally, we're also faced by the technical issues from how this metadata is used in badges like the Badge Muse series (explained more fully above).
Normally I would try to offer a step-by-step proposal for how we can try to achieve this, but I'm a little stuck on this one. We have several different areas that need to be considered for this migration. I want to discuss this earlier than later, because if this migration is done without careful planning, I think it will be detrimental to the Fedora Badge workflow and drastically slow down the development and progress of more badges (making things feel like they're all broken and neglected).
I know we have a sunset date for FedoraHosted, but I can't think of any other Trac that's as customized or heavily dependent on being hosted within Fedora's infrastructure like this one. I think to migrate this one, we're creating a significant amount of work across different parts of the project too. We need key stakeholders with Fedora Badges to review this ticket and provide input to ensure that the Badges workflow doesn't suffer from the outcome of what we choose to do after February.
There's a lot of key stakeholders in Badges that should definitely have input to this ticket. I wasn't involved at the time of conception for Fedora Badges, so there's things that some of the original developers of fedbadges / Tahrir could help add context to.
…and surely plenty more I'm forgetting… feel free to ping others too.
Linking to tickets on fedorahosted.org Every single badge on badges.fp.o is this way. If we break the domain, the "Criteria" field becomes irrelevant on all of the hundreds of badges we have pushed out now.
Is this field in the DB or in the yml of the badge? In the DB, we would need a migration script, in the yml a massive git commit to adjust all of them.
Badges awarded to ticket creators By moving to Pagure, this badge will break and will not be automatically awarded. This should be fixable, but it has to be addressed before we move.
Indeed, the rule of the badge has to be adjusted to account for both trac and pagure as otherwise, we'll loose history and people having say 9 tickets closed in trac will restart from 0 with the move to pagure.
Maybe we could make a wiki page of all the badges impacted and then create a pagure branch in the repo where we update the definitions as time allows.
Badges for designers
This sounds to me similar to the previous point, we need to list all the badges/rules that need adjustments and proceed with them.
Metadata in the workflow
This sounds like something that will use the custom fields and the reports features. I do thing we could offer a similar workflow as what is currently used, the only thing I see that trac offers and not pagure is for custom fields a drop-down list, while pagure leaves the field open to any text.
The field for criteria is in the db. The edit-badge script can adjust the entry for criteria.
I believe the badges for badge artist has always been manually awarded, if i am not mistaken.
For the critera field also we can setup redirects so the old links just redirect to the new issue in pagure. We did this for fedora-infrastructure tickets.
For ticket creator badges we can change that to look for pagure instance closed -> pushed (you can now do custom closed statuses in pagure).
The workflow/statuses/reports/tags is the bigger issue. I don't think we can do a one to one setup, so I think what we might have to do is sit down and design a new workflow that works for pagure (possibly with new features).
@pingou @nb is right on this, it is in the database, not the YML file. The edit-badge script does offer a way to update badge criteria if I recall, as mentioned.
edit-badge
Indeed, the rule of the badge has to be adjusted to account for both trac and pagure as otherwise, we'll loose history and people having say 9 tickets closed in trac will restart from 0 with the move to pagure. Maybe we could make a wiki page of all the badges impacted and then create a pagure branch in the repo where we update the definitions as time allows.
This can try to be something the Badges team help with. I don't think there should be many dependent on this but we can try to round them up.
This is actually awesome, when I filed the ticket I wasn't aware that custom metadata was a new feature! I think it should be possible to recreate all the specific things that would be helpful for triaging purposes. It wouldn't be too hard to construct custom queries for quickly highlighting sets of badges that are ready for the next step in the design process.
If we set the custom closed status before migrating to Pagure, will it migrate tickets with the "pushed" status to that in Pagure with the pagure-importer tool? If so, then it should be an easy adjustment.
pagure-importer
It might be helpful to allocate a set amount of time to discuss and work through this one.
I don't know here. We should check with @cverna on it.
Sure, lets plan an irc meeting after f25 is out the door?
For now pagure-importer does not support custom fields, but @vivekanand1101 is working on it. I don't think it will support custom close status, but I don't see why we could not support these. It might need some input from the user, but we can come up with a solution.
Quick note - as the person who set up a lot of the custom trac stuff, please let me know if I can help with anything. Not sure if I can promise a ton of time but I do feel responsible if this is tricky!
Yeah, this would be great. I think we'll need some time to organize a "stakeholder's meeting" to get past and present contributors involved so that we can make a jump that (1) does not negatively impact the Badges Team workflow, and (2) ensures that all pre-existing hooks / requirements on Trac are replaced in Pagure.
This seems like something that would be very useful. For later reference, here is the issue.
Thanks for commenting, @adamwill! While I don't think we'll need you to commit a lot of time to setting up the new tools, what will be helpful is to have your perspective and opinions when we discuss migrating it in case there's things we're missing or forgetting that hold importance.
The badge artist badge is now manually awarded by me using this wiki page, https://fedoraproject.org/wiki/Open_Badges/ArtworkLog, so it would be great to see that automated in the future. As of right now, we are awarding credit to people who have helped at all to create the artwork for a particular badge(this does not include critiquers or commenters). So if we could have more than one owner or assignee to an issue that would be helpful in automating, otherwise we may have to keep with the wiki for keeping track of artists contributions.
There is quite a bit of resources used for badges, so the way to store those on pagure should be addressed. Mleonova suggested the files tab, which seems fine to me. We can point people to that location on the front page.
Currently, we are able to view images in the comments on trac. Having that functionality helps the badge system for critiquing. That way people can comment their thoughts and/or critiques without having to download and open the files. It also helps to easily see the differences between drafts of the artwork. If we could have that feature on pagure, that would be great!
On the same topic, it would be nice to have the PNG file in the comments, but have a spot where all the SVGs are stored on the issue, instead of attached to each comment. So a place to generally attach files to an issue would be a helpful feature.
I think have a standard set of tags will be helpful in transitioning badges to pagure. Those should be listed on the front page of the project. That way badge idea creators and triagers can easily tag new badge ideas with the appropriate tags. This may in fact help people navigate the queue better than when badges was on trac. For example we can tag badges with artwork-simple, artwork-intermediate, artwork-complex, to denote the difficulty of the proposed artwork concept. The same system could probably work for the development side. Also we can use the tag system as a prioritization system... On the front page we can list which tags need the most attention, for example, event badges are usually on a quick deadline. Though I do see a priority field on this issue, so that may be a standard high priority set for all event badge ideas.
I haven't had much reason to use pagure yet, so if these features exist already, or are impossible, please leave commentary on what is what :)
we could have more than one owner or assignee to an issue that would be helpful
This is a though one and tbh, I'm not 100% sure I want to go that way, sorry :(
There is quite a bit of resources used for badges
Either including them in the main git repo of the project or its doc sound like possible options.
we are able to view images in the comments on trac.
Same on pagure:
<img alt="pagure_logo.png" src="/fedora-infrastructure/issue/raw/files/c338ae47df620878bf0441bd334cd3a8b97811ee39b1ab986a770a0b174510ab-pagure_logo.png" />
(sorry replying in two comments, something went wrong with my browser)
So a place to generally attach files to an issue would be a helpful feature.
There is an RFE to list all attachments in one place: #1597 (which even has a patch!)
I think have a standard set of tags
I think that's something up to the maintainer of the project :)
we could have more than one owner or assignee to an issue that would be helpful This is a though one and tbh, I'm not 100% sure I want to go that way, sorry :(
Maybe using a custom filed here would help, instead of using the owner or assignee you could have a designer field.
designer
Going off of @cverna's suggestion, it would be really cool to have a field that holds FAS usernames for designers, and then have the badge automation script check that field for usernames, and award badge to user when the ticket is closed as "pushed". This would probably require some wizardry by a fedmsg hacker to figure out, though…
I definitely think combining a clever use of tags and custom metadata (which is awesome that we have this now!) is the best way to make an effective workflow. We can try to convert some things and try out new things, like rating the complexity of a ticket (and then we can build custom queries for badges that need artwork and also are easy, for newcomers).
The one thing I see as a potential blocker to this, or maybe what would make this easier, is to allow the person filing a ticket to fill in metadata or tags (and maybe require them to do so). This is kind of, sort of covered in pagure#1530.
Just a quick update about pagure-importer There is a PR ready to add the support for pagure's custom close status in the importer tool. (https://pagure.io/pagure-importer/pull-request/87) .
This all sounds great! Besides coming up with the standard tags, what else can the design team side of this do? Also when is this all becoming official? Should I plan to be involved in the day/week it actually transitions? I am considering having a small Fedora Badges hackfest to deal with the tagging and writing up good documentation for the front page, etc etc.
jflory7, since we are both Rochester local, perhaps we could meet up for this?
@riecatnor Sorry for the slow response here. I think all we will need from the Design Team for now is the standard tags, but if anything else pops up, I'll be sure to add it to this ticket. I don't know if we have set a deadline for us specifically yet, but the Trac End-Of-Life is February 28th, so no later than then.
A small hackfest would be helpful for this. I am still in Rochester, but only until Sunday. :pensive: With it being finals week this week, my time is also more limited than it normally would be. We could try to aim for something Saturday?
@jflory7, sorry I didn't see your response until just now!! Its been a busy month. When will you be back in Rochester? I would still like to meet up with you before/around badges transition to Pagure.
Mleonova and I will work on the standard set of tags at our next Badges meeting which is 1/18/17. We should be able to finish that during that meeting and I will post those here and keep a separate record of what we decide on.
ok. We are down to the last month now. ;)
How can we move this forward? Perhaps a test instance on pagure-stg to see if things will all work, then a real migration?
Here is a set of a tags that I thought of
If needed we can add more tags to it. Right now I am working on importing pagure-stg with this sets of tags to see how things turn out.
Hi Sayan, we are working on a list of tags in a doc together with Marie. It includes some of these + more.
Here is a set of a tags that I thought of badge-def-notpossible badge-def-partial badge-def fullneedsreview badge-def-approved manually-awarded status-concept status-proposed status-design-team-approved status-concept-approved If needed we can add more tags to it. Right now I am working on importing pagure-stg with this sets of tags to see how things turn out.
badge-def-notpossible badge-def-partial badge-def fullneedsreview badge-def-approved manually-awarded status-concept status-proposed status-design-team-approved status-concept-approved
I just completed migrating the badges to staging pagure. You can test it here https://stg.pagure.io/fedora-badges/
Excellent. Is there anything further needed here? Or shall we close this and just fix issues as we come to them?
Today we had our Fedora Badges meeting and we reviewed https://stg.pagure.io/fedora-badges/. It is looking great! Mleonova and I have a few things we would like to address. These things may shake out once it is no longer in the staging process, but please advise.
How do we access changing tags, in general and more specifically? We see a few typos within the tags, so would like to be able to edit the existing tags and would also like to be able to add more. Also, we need access to changing/adding tags in the individual issues.
How do we access changing the different statuses on the issue? For example Artwork proposed to then Artwork approved. If this a matter of access, please add mleonova and myself to these privileges.
We will be writing up the front page description from an amalgamation of the descriptions on Fedora Badges, the old trac and our edits/additions. Will hopefully have that ready within the next couple weeks.
Yeah, @sayanchowdhury needs to add you there to the stg instance as owners and then you should be able to change tags, add tags, etc.
I see you got added there.
Is there anything further we can do here? Or should we close this now?
@riecatnor @mleonova I have given access to the staging repo. If everything looks good should we run the importer to migrate to pagure.io/fedora-badges?
Time is pretty much running out here... can you do the migrate asap?
It's a go from our side! We are still working on some of the documentation but that is ok to add in as we go. Thanks
ok, so @sayanchowdhury will be migrating things today?
Do make sure to disable updates in the trac first, I saw a number of people updating tickets this morning.
Let me know if I can do anything from here...
Migration is done. So, going over and closing this issue.
I don't have the access so @jflory7 or @kevin can you close this issue?
Sure thing. Thanks!
:bee:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.