As some of you know, Forgejo does not currently support private issues in public repositories. Since this feature is important for several of our teams, we have come up with a temporary workaround while work on the actual solution continues.
We plan to create a small Flask application that uses Fedora Accounts (OIDC) for authentication. When you log in, it will display a simple form with your username and email already filled in. You will be able to select the target organization from a dropdown list and write your issue description in a text box. Once submitted, the ticket will automatically be created in the corresponding private repository for that organization.
For now, notifications will be handled manually. The person resolving the ticket will send an email once the issue is closed. In the future, we plan to automate this part as well.
Yeah, you’re right, it’s not ideal. For now, any comment to the reporter will need to be forwarded by email. We hope to automate some of this. But re-posting replies for follow-up will be needed.
Yeah, I don’t think this scales at all. For issues where we only want to inform the reporter at the end when the ticket is closed (as described in the proposal), perhaps. But any back and forth would be horribly tedious. We might as well just say “For private issues, email xyz@fedoraproject.org “
That’s a fair point. I would prefer not to slow down Forge adoption because of a missing feature that affects only a small fraction of the issues currently tracked on pagure.io.
There are number of the request tracking solutions designed to work in a support scenario, where customer request is private and the discussion can happen with and without customer seeing it.
Would not it be possible to setup a separate solution for all private requests in the project?
Is the requirement really to track private issues in public projects in Forgejo or to have an request tracking service for sensitive discussions?
If it is the latter, why don’t we deploy a ready-to-use solution instead of that custom Flask app?
Yes, a separate solution could work. However, that would go against one of the goals of our Forgejo migration, which is to simplify our tooling.
We plan to implement this feature in Forgejo so it can later handle bug and package tracking once src.fp.o is migrated from Pagure to Forgejo instance. This keeps everything in one place and avoids introducing another service we would eventually want to retire.
I have to say that I agree that having a workaround like this is not ideal …
I see that upstream forgejo is aware of the lack of “private issue in public repo” (also for things like “responsible disclosure” for security issues) - so hopefully this solution could be worked on together with forgejo upstream and / or upstreamed when implemented downstream? That way we’d at least not be stuck with downstream patches for significant functionality like this forever.
Yes, upstream is well aware that this feature would be useful beyond Fedora.
We plan to follow a similar approach as we did with the Pagure exporter. Based on upstream guidance, we will develop and stabilize the feature in our fork first, and then work with the Forgejo community to get it merged upstream once it is ready.
So, IMHO we should avoid a complicated app/bunch of work we plan to drop later here.
I’d say we should just tell projects that need to/want to use private tickets to:
tell users to just email them at whatever address/alias. Thats not great because if the people/group getting the email isn’t paying attention the issue could be missed, no handoff to new people, insecure / clear text, etc.
Or
Projects/groups that need private tickets could direct those to some other tracker: pagure, gitlab, etc. Not ideal because they aren’t all on our forge, but could be a stop gap
Once private tickets are implemented we can drop these workarounds.
One thing I think we should also try and do: when private tickets are implemented, could we also modify the importer to allow importing just those existing private tickets into the main forge ticket repo? That would allow keeping them in the final place.
Kevin Fenzi [kevin] wrote:
One thing I think we should also try and do: when private tickets are implemented, could we also modify the importer to allow importing just those existing private tickets into the main forge ticket repo? That would allow keeping them in the final place.
Yes. Currently the mirgrator is set up to with the ability to import them into a seperate (private) repo. The intent here was when private issues are implemented in Forgejo, we can import them over (including any new ones created in the period between initial migration, and private issues feature rollout.)
I am all in for using email for this purpose as a workaround. Do we need to involve any of the project bodies in this decision? Or is it on us, and we need to start clearly communicating the email workaround?
It depends. Will Pagure get closed down before private issues are ready in Forgejo?
Two repos that I have this thought for is the Fedora Code of Conduct repo (all private issues) and the Fedora Council ticket repo (mostly public, some private issues).
If we can hold onto Pagure long enough to figure out private issues on Forgejo, it is a non-issue from my perspective. If we lose Pagure before private issues are on Forgejo, we have a difficult situation.
I think more communication is always a good thing!
There are project-wide processes right now that default to private tickets that would have to have Council and Legal signoff if we materially changed the process.
At present I’m most concerned about the GDPR related processes, that the infrastructure team ends up servicing:
The proposed flask app may be sufficient for these GDPR related processes. I’m not keen on the proposed org dropdown and a blank description template. I would feel much better if the flask app would have to have context-specific calling options to bring up specific issue template instructions and make it clear to the user which process ticket they are filing to ensure we are meeting certain requirements in how requests are structured.
I’m certain that an email alias workaround is insufficient, as the existing FAS OIDC is a critical part of these processes. We will have to have something that is securely gated by FAS OIDC.
I would suspect that any process that was sufficient for the GDPR related tasking serviced by infrastructure, would also be sufficient for the private tickets serviced by the Code of Conduct committee.
There may be other processes that default to private tickets that I’m not aware of. We have to look closely at any process that uses a private ticket by default. and understand if private by default has been chosen to meet an imposed obligation(as is the case of GDPR) or if its entirely an internal policy concern. But again, I would wager that a replacement workflow that is sufficient to meet our obligations for the GDPR processes will be sufficient for a number of other things, so we should primarily solve for these GDPR processes, as the processes with the tightest known imposed constraints, until we identify something more burdensome that can’t be ignored.
It depends. Will Pagure get closed down before private issues are ready in Forgejo?
I personally would not want it to. We could make that a requirement for
pagure retirement even.
Two repos that I have this thought for is the Fedora Code of Conduct repo (all private issues) and the Fedora Council ticket repo (mostly public, some private issues).
If we can hold onto Pagure long enough to figure out private issues on Forgejo, it is a non-issue from my perspective. If we lose Pagure before private issues are on Forgejo, we have a difficult situation.
Closing down of pagure is one thing, adoption by everybody else who does not require private issues is another.
We’ve started discussing migrating the Infrastructure tracker and app repositories to the new forge. I’d really like us to migrate, as it provides the team with better tooling to handle some of its workflows. That said, splitting the tracker between two systems doesn’t feel right.
Looking at the Pagure stats, there are about 20 private issues and 80 comments per month across all active repositories.
I think we should continue encouraging adoption by other teams, while keeping the trackers that rely on private issues on Pagure until we reach feature parity.
This way, without the team having to implement a workaround, people can focus on completing the feature.
I don’t see the proposed workaround for dealing with private issues as enough of a blocker to prevent council from migrating to Fedora Forge. It was a blocker when we had no mechanism to deal with them at all, but this proposal seems ok. For a temporary period of time anyway and for specifically Fedora Councils workflow.
There’s also other options open to Council too to deal with how we handle private issues until we do have feature parity. I’ve updated councils migration tracker ticket with some of these ideas. I totally appreciate none are ideal, but I feel we should just start somewhere and actively work towards what we want, rather than waiting around for a perfect state to present itself - but how nice would it be to have that happen sometimes, eh?!
In any case, I’m speaking purely from a council members pov, and I think we can absolutely deal with using this workaround, or use one of the suggested others from the ticket and migrate to Fedora Forge soon. Private ticket filing in the council repo is low (generally, thankfully!), so there is probably very little extra admin in real life for us to deal with. I would suggest leaving any repositories that do have high private issues filed in them (maybe - 3 issues or more per month) stay in pagure though until a better, permanent solution is in place in the new forge.
The problem is that “temporary” quickly becomes “permanent”. It is an inescapable reality, so if we don’t hold the line here and require that everything actually get done properly first, chances are good that it isn’t going to happen ever.
I understand that this is a real concern, and one that has unfortunately been seen as a pattern before, so its very hard to trust that this wont be a case of history repeating itself And I am also certainly not advocating that the entire fedora project migrate before we have this feature parity either. There are repositories in Fedora that simply cannot migrate until we have this feature in place. Because of this, I do believe that we will have this feature eventually, because we just have to have it to fully complete Fedoras migration.
What I am advocating for, is for project teams to look at their real-life use cases when it comes to the private issue feature. Is holding out for an undetermined amount of time to get this feature in place worth the loss of momentum to the Fedora Forge work? I personally dont think so. We know this feature is still on the dev teams radar, and is also filed upstream. We know we do need this feature to finally be able to call this work done. But does every team need it 100% in place to migrate? I don’t think so. And purely from a Council point of view, I think we have other means we can temporarily use until this feature lands. Worst case scenario, we get loads of private issues filed in a way that’s unmanageable, and then we will have built up a lot of data to pester the dev team and upstream with that this is really badly needed
So I still don’t believe this is enough of a blocker for Council to not migrate to Fedora Forge and conduct our work there as we have been doing (but maybe better ) on pagure. Its certainly a requirement we have and want, but I dont see it as a blocker to not move.
Maybe this workaround could be propositioned as more of a suggested means to an end for teams who wish to migrate now, but need to know how private issues could be handled temporarily? This gives the project teams their own decision on whether to accept this workaround and migrate to the new forge now, or think up their own workaround to use, or simply wait to have feature parity.
and for specifically Fedora Councils workflow.
And I am also certainly not advocating that the entire fedora project migrate before we have this feature parity either. There are repositories in Fedora that simply cannot migrate until we have this feature in place. Because of this, I do believe that we will have this feature eventually, because we just have to have it to fully complete Fedoras migration.