#73 Opening of a Ticket

Closed
opened 8 months ago by jaywink · 3 comments

The Forgefed spec says:

A request to open a Ticket sent from one actor to another MUST be represented as an Offer activity in which:

The Offer is indicated to be a Ticket without an ID. On receiving the Offer, the target repository will create a Ticket with an ID.

I believe this is not how a federated model should work. In a truly federated model, you should be able to create Ticket's on your cached version of the remote repository and send them as Create activities to the remote repository. The remote repository has the option to either accept them or reject them, but it should not need to take ownership of the objects created.

The same principle exists with posts and comments on for example federated social sites.

Continued from this discussion.

The Forgefed spec [says](https://forgefed.peers.community/behavior.html#opening-a-ticket): > A request to open a Ticket sent from one actor to another MUST be represented as an Offer activity in which: The Offer is indicated to be a Ticket without an ID. On receiving the Offer, the target repository will create a Ticket with an ID. I believe this is not how a federated model should work. In a truly federated model, you should be able to create Ticket's on your cached version of the remote repository and send them as Create activities to the remote repository. The remote repository has the option to either accept them or reject them, but it should not need to take ownership of the objects created. The same principle exists with posts and comments on for example federated social sites. Continued from [this discussion](https://notabug.org/peers/forgefed/issues/7#issuecomment-17038).
fr33domlover commented 7 months ago
Collaborator

@jaywink, posts and comments are different. They're about sharing your personal thoughts, and access control of them must be protected by their author. Someone else editing your words would be impersonation. So, we want them to be hosted by their authors. That way, we can trust them.

But source code, issues and lots of other things are different: We do want to be able to verify their authenticity, but they're part of a project that goes through a process of edits and updates, and the people who manage the project need to control edit access. Even if the authors of some of the content are different people. The way I see it, projects must be able to host their code and issues and MRs and so on, otherwise they can't be in control and trust their own code and to-do list and so on.

Here's an example of a problem.

Suppose you publish an issue on a remote repo, you publish on your own server. The repo lists your issue on their list of open issues. Suddenly, you want to edit the issue. You should be able, right? It's your content, you host it, you must have freedom to edit as you wish. It's like an article you wrote. Maybe you wrote something you know disagree with, your opinion changed, I think it's important that you can change.

The problem is, the repo team disagrees with your edit. They still believe in the old thing on which you changed your mind. They want the old version. Also, if your server goes down next week, they still want to be able to discuss and update the issue (e.g. assigning someone to work on it, adding tags, etc.).

This sounds to me like you and the repo team have conflicting needs that are impossible to fill with a single issue object. You need the issue to express your thoughts, they need the issue to track bugs in their code. But you and them disagree on the issue description. What do we do?

In email, it's easy: You send a bug report by email. Repo team does with it whatever they want. You can publish and send your report anywhere you wish, regardless of what the repo team does. No conflict.

In repo-based bug tracking, it's somewhat easy too: You can open a bug by sending a patch/MR to the repo. The repo team can edit it, but you still retain your version in your fork of their repo. Their version is still the version everyone will see though. However if they have freedom to edit your words, nobody will hurry to attribute to you the issue wording: It's clear the issue is controlled by the repo team and not by you.

In centralized web forges, only one part gets addressed: The issue is in control of the repo, and you don't get to publish your own version.

It seems, to me, that the only way to fill everyone's needs is to allow you to have an copy you control, and to allow the repo to have a copy it controls. They control the status and assigned-person and severity and priority and due date and wording of the items on their to-do list, even items that got contributed by people from other servers; and you get to publish your issue exactly the way you want, just like you may publish a Note or an Image. If people read the repo's issue and they don't like the wording, they can look at yours and be like "oh, this is what Jason meant when he wrote the bug report". So everyone gets their needs met.

You get to host your thoughts. Repo team gets to manage access control to its project management stuff.

This ability-to-have-two-copies was discussed on the ML; and I don't see how we can host the issue in exactly 1 official place and still provide both the needs of the repo team and the author.

Q: Why don't we have that problem with toots?

Because toots don't play a double role. Issues do:

  • Expression of author's thoughts (like a toot)
  • To-do list item to manage work on project

Toots do only the first item. When you read a discussion, you can GET each comment from its author's server and be sure it's authentic. And that's all you need.

(I'll open a forum topic about this in a bit, to get more feedback)

@jaywink, posts and comments are different. They're about sharing your personal thoughts, and access control of them must be protected by their author. Someone else editing your words would be impersonation. So, we *want* them to be hosted by their authors. That way, we can trust them. But source code, issues and lots of other things are different: We do want to be able to verify their authenticity, but they're part of a project that goes through a process of edits and updates, and the people who manage the project need to control edit access. Even if the authors of some of the content are different people. The way I see it, projects must be able to host their code and issues and MRs and so on, otherwise they can't be in control and trust their own code and to-do list and so on. Here's an example of a problem. Suppose you publish an issue on a remote repo, you publish on your own server. The repo lists your issue on their list of open issues. Suddenly, you want to edit the issue. You should be able, right? It's your content, you host it, you must have freedom to edit as you wish. It's like an article you wrote. Maybe you wrote something you know disagree with, your opinion changed, I think it's important that you can change. The problem is, the repo team disagrees with your edit. They still believe in the old thing on which you changed your mind. They want the old version. Also, if your server goes down next week, they still want to be able to discuss and update the issue (e.g. assigning someone to work on it, adding tags, etc.). This sounds to me like you and the repo team have conflicting needs that are impossible to fill with a single issue object. You need the issue to express your thoughts, they need the issue to track bugs in their code. But you and them disagree on the issue description. What do we do? In email, it's easy: You send a bug report by email. Repo team does with it whatever they want. You can publish and send your report anywhere you wish, regardless of what the repo team does. No conflict. In repo-based bug tracking, it's somewhat easy too: You can open a bug by sending a patch/MR to the repo. The repo team can edit it, but you still retain your version in your fork of their repo. Their version is still the version everyone will see though. However if they have freedom to edit your words, nobody will hurry to attribute to you the issue wording: It's clear the issue is controlled by the repo team and not by you. In centralized web forges, only one part gets addressed: The issue is in control of the repo, and you don't get to publish your own version. It seems, to me, that the only way to fill everyone's needs is to allow you to have an copy you control, and to allow the repo to have a copy it controls. They control the status and assigned-person and severity and priority and due date and wording of the items on their to-do list, even items that got *contributed* by people from other servers; and you get to publish your issue exactly the way you want, just like you may publish a `Note` or an `Image`. If people read the repo's issue and they don't like the wording, they can look at yours and be like "oh, this is what Jason meant when he wrote the bug report". So everyone gets their needs met. You get to host your thoughts. Repo team gets to manage access control to its project management stuff. This ability-to-have-two-copies was discussed on the ML; and I don't see how we can host the issue in exactly 1 official place and still provide both the needs of the repo team and the author. # Q: Why don't we have that problem with toots? Because toots don't play a double role. Issues do: - Expression of author's thoughts (like a toot) - To-do list item to manage work on project Toots do only the first item. When you read a discussion, you can GET each comment from its author's server and be sure it's authentic. And that's all you need. (I'll open a forum topic about this in a bit, to get more feedback)
fr33domlover commented 7 months ago
Collaborator
[Feneas forum thread](https://talk.feneas.org/t/where-to-host-issues/198)
fr33domlover commented 6 months ago
Collaborator

Solved after a very long discussion in forum. We'll be doing both flows, the Create one and the Offer one. I updated the spec. Closing.

Solved after a very long discussion in forum. We'll be doing both flows, the Create one and the Offer one. I updated the spec. Closing.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.