Get rid of the need for github issues

[neithernut]

git-dit was written to replace systems storing issues in an opaque web application. Storing issues in a repository allows communicating them between different (git-based) platforms. Hence, you might wonder why this repo has "issues" enabled.
We do not yet have a viable mechanism for notifying maintainers about changes to issues. Originally, we had mailing lists in mind, but we also planned on creating web-based protocols for general purpose notification mechanism for repo updates (also usable for CI and other stuff), at some point (in another project). However, as long as users do not like to send (partially hand-crafted) emails to us but rely on a web-interface and as long as the aforementioned tools do not exist, we are stuck with github-issues.

We will disable issues on this repo, once git-dit has overcome the PoC-stage and we can, in some way, be notified about contributors' issues.

[joshtriplett]

Multiple tools exist using the github issues API to import/export issues. A two-way bridge between github issues and git-dit would be awesome.

[Profpatsch]

A two-way bridge between github issues and git-dit would be awesome.

We’ve been thinking about that; the major problem is that git-dit forms a message tree (as mail threads do), while github issues are linear. So a nice mapping will have to be done.

[wmertens]

Nice mapping: Github messages are a flattened-by-time tree. You can bidirectionally sync, but from-gh would lack tree parents. You could inspect the text for quoted lines and decide parent on that, or else always attach to last message. Within the context of gh issues, that's pretty much what it is anyway.

[Profpatsch]

Within the context of gh issues, that's pretty much what it is anyway.

That’s what I thought initially, but:
Github issues form a DAG, too! This references a comment from before: #3 (comment)

[wmertens]

Ok but then your comment can have multiple parents and you can't express that, either. Comment threads really aren't all that important imho.

…

On Sun, Mar 19, 2017, 3:28 PM Profpatsch ***@***.***> wrote: Within the context of gh issues, that's pretty much what it is anyway. That’s what I thought initially, *but*: Github issues form a DAG, too! This references a command from before: #3 (comment) <#3 (comment)> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWloc5R4C5bSignDmNPCfvIwrRw0z2ks5rnTtygaJpZM4MMDHr> .

[Profpatsch]

Ok but then your comment can have multiple parents and you can't express
that, either.

Of course you can. git commits form a DAG as well (multiple parents, as example you have merges). You want to be able to reference e.g. commits from conversations as well.
Little known fact: E-Mail also supports multiple parents.

[matthiasbeyer]

I love how our data layout works out so well... ❤️ 😍

[lofidevops]

Beyond GitHub, a general approach to import issues/comments from external trackers would be great. It would then be up to other communities to build (for example) gitlab-to-dit, launchpad-to-dit and so on.

Would submitting to external trackers be feasible / in-scope?

[neithernut]

Beyond GitHub, a general approach to import issues/comments from external trackers would be great. It would then be up to other communities to build (for example) gitlab-to-dit, launchpad-to-dit and so on.

Exactly. Those should also be external tools. I believe @matthiasbeyer is (currently?) working on a GitHub-import-script btw.

Would submitting to external trackers be feasible / in-scope?

As long as one can conceive a mapping from messages to the external tracker, sure. However, the mapping between authors will be problematic in many cases. Consider, for example, an issue reported by someone without a GitHub/GitLab/whatever-account, or just someone who's email does not match.

Even if those problems are resolved, you will generally require the access necessary for crafting messages with another author on the external platform.

[Profpatsch]

However, the mapping between authors will be problematic in many cases. Consider, for example, an issue reported by someone without a GitHub/GitLab/whatever-account, or just someone who's email does not match.

Even if those problems are resolved, you will generally require the access necessary for crafting messages with another author on the external platform.

I think the new Matrix protocol has some solutions for nicely mapping nick names over namespace boundaries? At least they are able to map 1:1 between Matrix and IRC, so maybe git-dit can borrow the approach.

[ScalaWilliam]

Hello. I'm working on something similar and would like to point out WebSub: https://www.w3.org/TR/websub/ and https://www.w3.org/TR/webmention/