This subject was discussed during our lengthy oral meeting.
@dachary highlighted that time will especially constrain what could be done.
I said that:
first some context is required; i don’t fully understand the steps above. Which user interface? For which workflow? It was initially planned to avoid any interface (using the interfaces of the existing forges and for example a prefix with the federated issues such as fedeproxy:). Is there an admin user interface?
I took a look at the deliverables due end of January 2022 because they are listed in the proposal. It reads I3 Create the fedeproxy server user interface. I think it makes sense that the user is a system administrator running fedeproxy alongside a GitLab or Gitea instance. The interface I like to have as a system administrator is a cli, with a configuration file.
This can be achieved by wrapping fedeproxy into a docker image. The options available from the underlying web framework (Django or chi) when running the server are modified to include new options, specific to fedeproxy. The configuration file also has additional options that are only meaningful to fedeproxy.
Once this is complete, or in parallel, it would be good to design a UI that is friendly to the forge users (Gitea or GitLab), but that’s not a required deliverable by January 2022.
It looks like a way to embed Fedeproxy in the UI of the forges currently in use means: Fedeproxy is integrated/dissolved in these forges. This isn’t an realistic goal for before the end of January 2022 Instead, using a format recognized by Fedeproxy in the issue titles is achievable (It was something we evoked during an oral discussion).
Did we define the user experience roadmap for interacting with the fedeproxy server in a formal way? We had a lot of spoken exchanges on this subject, isn’t the time to write down the user workflows?
Returning to the milestone, the remaining implementable user interface is the admin one, a cli and/or a configuration file would fit. About the schedule of this milestone, this cli and/or configuration file will be an outcome of the future developments.
Some mechanisms are not clear, updates will be required. Once refined, i will use a version control friendly text format, for example the DOT language.
@misc mentioned a useful use case: one project (or one user?) follows a dependency project hosted on another forge and there is a notification (a new issue could be created) when a new release of the dependency is created.