Hi Marie!

I know you are intending to start public, transparent discussion around communication, but maybe to put this upfront to avoid steering off-course, I assume that there was an affirmative decision to move forward with GitLab over Pagure. :)

On 4/1/20 10:30 AM, Marie Nordin wrote:

How do we ease the path of acceptance around Gitlab for those teams that have to and/or want to move there. The decision to go with it has been made. We need to help the community see, understand, and accept why the decision was made, and then hopefully become inspired to contribute to it. We are working against a lot for this second piece, though I have a couple ideas. I would really love to get input from everyone else.

If I could make a single wish, it would be to migrate issues/PR history from Pagure to GitLab.

From my perspective, I like GitLab over Pagure from features/tooling perspective for issue management, which is what (most) non-software teams use Pagure for. But the historical archive of issues, PRs, and git commits is important to me. I can set up new labels, new workflows, and get used to a new UI, but I can't reference historical discussions and perspectives without going to an archived site and fishing out a link, when today I can type #XYZ to reference something in less than five seconds.

When Fedorahosted/Trac was sunset, folks went to great lengths to write a Python CLI tool to migrate Trac tickets to Pagure issues. This was immensely helpful to me. While I would have liked some help to actually move the Trac repos over to Pagure, just having a tool to go from Pagure to GitLab would be dandy.

On Wed, Apr 1, 2020 at 10:31 AM Marie Nordin mnordin@redhat.com wrote:

Evaluating this situation, taking some time to document what went badly, what maybe went well, how we can roll out decisions like this more effectively in the future. Perhaps even writing something publicly so that the community sees we see it went badly, and that we are listening.

Independently of what people think of the outcome, I think the exercise of collecting and vetting user stories was good and we should do this for future application-related decisions. As Matthew noted in the meeting, we agreed in the past that "the Council is willing to accept closed source or non-free tools in Fedora’s infrastructure where free and open source tools are not viable or not available." Of course, the definition of "viable" is open to a lot of debate. Having a list of requirements (whether expressed as user stories or in some other form) helps to make "viable" more clear. There's still room for disagreement, of course, but at least there's a concrete starting point.

For the teams that want to stay on Pagure, is that an option?

I don't see why not. In the same way that we allow teams to choose what communication channels they use, they are also free to use what git forge/issue tracker they choose.

How do we ease the path of acceptance around Gitlab for those teams that have to and/or want to move there. The decision to go with it has been made. We need to help the community see, understand, and accept why the decision was made, and then hopefully become inspired to contribute to it. We are working against a lot for this second piece, though I have a couple ideas. I would really love to get input from everyone else.

We could have someone from GitLab be a guest on one of the upcoming Council Video Meetings. Right now we're open from June on. If June is too soon, we can schedule it for later.