Framing for milestone 1

[michielbdejong]

I think to frame our questions and answers for milestone 1 we can use a running example:

Some sync scenarios:

• Alice creates an issue, Bob sees it.
• Alice creates an issue, Bob adds information to it.
• Alice edits the issue using two different devices. Can we make this single-party local-first?
• Alice and Bob both edit the same piece of information (e.g. "triage status" of the issue). Can we support multi-party edit?

Some network topologies:

• Direct API Integration: Alice (client) -> System A (server) -> System B (server) -> Bob (client)
• Multi-hop integration: Alice (client) -> System A (server) -> System B (server) -> System C (server) -> Bob (client)

[mcalligator]

This is a helpful start - conceiving of real-world use cases to inform our refined definitions and protocol design will (a) focus our minds on the problems to be addressed; and (b) provide the basis for concrete demonstrations of the progress we have made (as outputs for other milestones).

[michielbdejong]

See also https://docs.google.com/document/d/1jJT4eKlHceWPnKB8Xlm2L6ORJ4uBtEsnt3yq7siCqDM (not public yet)

[michielbdejong]

We should distinguish some roles:

• the issue reporter / task raiser
• the project maintainer who are authorised to certify whether a task was successfully completed / issue was adequately resolved
• worker who completes a task / solves an issue.

We can distinguish open from closed issue trackers (are those the right names for this?) on whether only project maintainers or also others can raise issues / propose tasks.

Often, there is a triage phase and issues can start as "proposed" by anyone; after that, a project maintainer can mark them as "triaged". After that a project maintainer can mark them as "completed". The worker can basically only add comments.

Of course, the issue reporter and the worker may also be project maintainers, then the same person has multiple roles, but in the generic case we can keep those separated.

[michielbdejong]

When an issue is linked to a timesheet, in general we can see the "manager" as the person who approves the timesheet of the worker. This can in general happen after the project maintainer marked the task as completed.

Obviously, sometimes the manager is also the project maintainer. And sometimes the customer is a local manager who represents an organisation, or who proxies for a final manager.

There may also be multiple people sharing the task of maintaining a project, but we assume that closing an issue is a solo task and there is one single person in the role of project maintainer doing that.

[michielbdejong]

Whether data is synced between multiple servers or not should not matter for the data views of each role. It should be possible for the issue reporter, the worker, the customer, and the project maintainer to all have their own account on one server. But they may also be spread around 2, 3 or 4 servers, and then each server is responsible for correctly communicating with each of the other servers.

[michielbdejong]

We can further split up the project maintainer into the "triager" and the "closer". So then the roles are what we may call the "RTWCM" framework:

• Reporter
• Triager
• Worker
• Closer
• Manager

[michielbdejong]

Framing 1: one-way sync

In the one-way sync case, each of RTWCM have a designated "home system", and that system is then also a single source of truth for data provided by the person in that role.

Framing 2: one-way sync + local-first

Zooming in on for instance the home system of the Worker, suppose it is made up of a smartphone app and a web application. The Worker may mark an issue as "hard" through the web application, and concurrently mark it as "easy" in the smartphone app. It is between the system and its user how this conflict should be resolved. In any case, to the outside world, the Worker's home system should always only expose one truth.

Framing 3: two-way sync with single-homed data

It may also be that we link a GitHub issue tracker with a Jira issue tracker, and mark both the GitHub account and the Jira account of for instance the Worker as authoritative, but only GitHub is marked as the Worker's home system. This may lead to data conflicts in which Jira shows that the Worker labeled the issue as "hard" and GitHub shows that the Worker labeled the issue as "easy". Now Jira can temporarily show data entered by the Worker, but will always need to send it to GitHub for approval, and revert if GitHub rejects the edit.

Framing 4: two-way sync with multi-homed data

This scenario is almost the same as framing 3, but in this case the question "who wins" is answered in a way that treats the various servers as equal. So it may be that the user is consulted on both GitHub and on Jira, or that "hard" always trumps "easy", or that the winning value is determined by the wall clock time of the edit, etc.

[michielbdejong]

Framing 5: two-way sync with multi-user edit

Slight variation on framing 4; in this case different humans are controlling the different devices, e.g. multiple workers or multiple closers collaborating to fulfill a single one of the roles

[mcalligator]

It is important to express the above in the context of particular use cases, since these will shed light on different facets of multi-party collaboration, having different roles and likely responsibilities and actions. The use case you have outlined thus far is that of an open source software project with contributors and maintainers in different organisations using different issue trackers to manage their work.

There is also another, operational, use case under consideration, which is of a managed service provider serving a customer organisation. and supported by a subcontractor. In this, issues are service changes, incidents, problems, etc. (as per the ITIL Service Management framework), data from which are propagated across organisational boundaries. This gives rise to a different set of stakeholders, participants, priorities, and other considerations, that is well worth examining.

[michielbdejong]

True! So we need to track dependencies between tickets, across org boundaries. But the RTWCM roles still work, right?

[michielbdejong]

Do you see other possible roles? A Planner, maybe?

[michielbdejong]

Regarding framing 3, why would a user make an edit in another system if you know it will be overwritten? It only makes sense if you trust the home node to do its best to merge all edits