There were (IMHO unanswered) concerns about:

• sustainability of the information
• sustainability of the tool
• readability of the information
• discoverability of the information
• an example fo how a change in taiga might look like

I know that the current way of things is tedious for @bcotton, and I'm sorry to say this, but consider me -1 until the concerns are worked out.

I would say the sustainability is the same as the wiki: we don't have any expectation that it will disappear, but I wouldn't make any promises.

The discoverability is no different, really. We'll still produce either the wiki ChangeSet page or a static HTML page that contains similar information, so we'll point people to the right place either way. Both options would still allow for search engines to get the content.

There is an example change available for view.

What's your concern about the readability?

Thanks!

What's your concern about the readability?

For example I consider the example change you've linked as hard to read compared to the wiki.

But those are not my concerns, but mostly just summary of what has been asked on the mailing list. I'd appreciate if you provided answers there.

For example I consider the example change you've linked as hard to read compared to the wiki.

That's because I left most of the context in the wiki markup I copied it from. I've fixed the markup and it should look a little easier to read now.

But those are not my concerns, but mostly just summary of what has been asked on the mailing list. I'd appreciate if you provided answers there.

Done.

One other comment in an attempt to sway @churchyard :-) : using something like Taiga where we have defined values for certain fields would make it easier to provide reporting on changes by the contingency deadline, as requested

Consider my -1 withdrawn.

Just a few cents from me:

sustainability of the information
sustainability of the tool

Taiga is an opensource project which is around for quite some time already which allows to easily export/import data. So in case we ever decide to move to something else, data is stored in structured way (not like in wiki), that should be fairly simple :)

That doesn't actually answer the "sustainability of the tool" problem. This will be created by a GSoC student. But who will maintain it? In Fedora, we are good at creating tools but terrible at maintaining it. Look how fast and gladly everybody ports Fedora Infra tools to Python 3 for example.

I believe the infra team is planning to maintain it. I know i'm on that team, but please don't consider that statement to be authoritative. @kevin, can you confirm whether we will be maintaining Taiga?

I'm a +1 to the proposal.

There's Taiga and there's the tool that orchestrates the change process. Will infra maintain both?

We are not maintaining taiga at all. The teams.fedoraproject.org instance is maintained by the upstream taiga developers via a paid contract with community platform engineering / Fedora council. So, they will be responsible for keeping the instance up, doing backups, etc. We are working with them to come up with a process for managing requests to them.

We don't have any plans to maintain a not yet written tool. Such a tool would need to successfully pass through our Request For Resources process before we could commit to maintaining it.

That all said, I am +1 to the proposal. We can't forsee the future, and we should let the fedora program manager use whatever tools they think best. We don't want to switch tools so often it annoys our maintainers submitting changes, but aside that I think we can adjust to changing situations as needed.

+1

+1 here as well

+1 as well. If FPM wan't to use a tool, and there are no clear reasons not to, we should just accept that. I think all the questions raised are answered in some way. In particular, if structured export is possible, we can always switch to something else if we can't keep taiga up.

I came here to write the same thing @zbyszek did, so I'll just +1 and mosey along back to what I was doing.

I get it that the current way is tedious for @bcotton but I also think this might make the experience worse for the Fedora contributors who actually file the changes, see for example this e-mail by @vondruch. I don't think that all stakeholders had a chance to express their concerns.

Can we maybe be more loud about this and collect more feedback? I don't want to rush this decision.

Technically it has been 7 days so consider me -1 again to prevent autoapproval, happy to change this again after we meet.

Thx @churchyard for mentioning my email.

I am still against this proposal. The whole process of proposing changes is more complicated then it used to be and this step will make the things just harder. Previously, it was enough to use Wiki, now I have to use Pagure and BZ and you want to add another tool (Taiga) on top of it.

I think people will stop proposing changes entirely, because frankly, they are not needed. They are just NTH. Also, there is no way to enforce the change process.

Honestly, it looks to me that we have Taiga instance and now we have to find some justification for it.

@vondruch I appreciate your concerns. For the most part, a change owner's only interaction would be with Taiga. Pagure only comes in if FESCo has questions during the approval process. I'd actually like to get rid of Bugzilla in the Changes process at some point, but right now it's very helpful for some changes to be able to link bugs against the Change Tracker bz. I'm open to other ways to get that functionality without creating tracker bugs in BZ. But essentially, you're still primarily interacting with one tool. We're just changing what that tool is.

Also, there is no way to enforce the change process.

You're right, but that's a separate matter. Right now, FESCo can get a provenpackager to undo a change if necessary, but I don't know that it's ever happened. The Change process does depend on people voluntarily complying, and I don't know that we can ever change that in a way that doesn't grind Fedora to a halt. But that doesn't mean it's not a worthwhile process to aid in communication within the community.

Honestly, it looks to me that we have Taiga instance and now we have to find some justification for it.

You may recall that before we had a Taiga instance, I was looking at using Pagure for this. Once we had a Taiga instance, I determined that it was a better fit for this use case. In both cases, we're separating the data and metadata, so that we can better automate parts of the process and Change owners don't have to worry as much about keeping free-form wiki text machine-parseable.

@vondruch I appreciate your concerns. For the most part, a change owner's only interaction would be with Taiga. Pagure only comes in if FESCo has questions during the approval process.

This is not true. For system wide changes, I have to open releng ticket in Pagure, where relengs just shrugs and close the ticket.

I'd actually like to get rid of Bugzilla in the Changes process at some point, but right now it's very helpful for some changes to be able to link bugs against the Change Tracker bz.

I agree, BZ is useful and I don't want to see it going away.

I'm open to other ways to get that functionality without creating tracker bugs in BZ. But essentially, you're still primarily interacting with one tool. We're just changing what that tool is.

And that is the problem. I am interacting with wiki also for other purposes. That is one tool used for multiple purposes. Now, you going to force me to use wiki for some stuff and Taiga for the other. Do you realize, that over 8 years contributing to Fedora, I did not have single need to use Taiga, but now you impose this tool on me.

Honestly, it looks to me that we have Taiga instance and now we have to find some justification for it.

You may recall that before we had a Taiga instance, I was looking at using Pagure for this.

Pagure would be more acceptable, but anyway.

Once we had a Taiga instance, I determined that it was a better fit for this use case. In both cases, we're separating the data and metadata, so that we can better automate parts of the process and Change owners don't have to worry as much about keeping free-form wiki text machine-parseable.

Keeping free-form wiki text machine-parseable is negligible problem I have submitting the change proposal.

This is not true. For system wide changes, I have to open releng ticket in Pagure, where relengs just shrugs and close the ticket.

Good point. We recently dropped that requirement for self-contained changes, in the hopes that it makes the process a little easier for both change owners and RelEng. But you give me an idea: one of the optional features of the tool that @pac23 is developing is to allow contributors to create change proposals from the command line. We could extend that to have it automatically create a RelEng ticket as part of the process, which would simplify your workflow.

one of the optional features of the tool that @pac23 is developing is to allow contributors to create change proposals from the command line.

That would allow to create the wiki page, where it could assure that it is still machine parseable 😉

This was discussed during today's FESCo meeting:
ACTION: bcotton to test the issue filing process with mhroncok and vondruch.
We'll revisit next week.

I won't probably make it to the meeting.

I've tested this, it seems quite OK, found one bug in taiga (that I believe could be fixed), but no show stoppers. I still have concerns about the community response, but I guess we cannot get that one without trying.

Proposal: We allow this for F32 as a test run, collect feedback via standard channels (devel ML), reevaluate afterwards. (If needed, I can help @bcotton to move everything form F32 back to the wiki.) (And I'm +1 for my proposal FTR.)

If you think that would be "overcarefull" and would rather approve it unconditionally, consider me -1 still.

As somebody said on the meeting, we don't need to vote unanimously, so please only go with my proposal, if you decide it makes sense, not just to please me :)

+1 to @churchyard's proposal.

+1,i would also like to help @bcotton to move everything back if things don't work out.

As of the tool status we are half way there,all the additions suggested have been noted and functionality is going to be added.

Approved during today's meeting without any specific release restriction and required re-evaluation later.

  * AGREED: The Taiga switch is approved without any specific release
    restrictions. We can revisit in the future if there is a need for
    it.  (contyk, 15:13:21)

If this proves to be a bad decision, we can always file a new ticket and a change with suggested steps.