Hacker Neue

Preferences
comex parent
Interesting. So from what I can see, each issue report and each comment is a ref, like a branch. There's no master file with a list of issues; listing issues/comments is done the same way as listing branches. This avoids the need for an explicit merge step when pulling or pushing; doing one of those 'just works' and combines the list of issues seen by each side. Editing a report or comment seems to not be currently supported, but could be implemented as adding a commit to the branch. So you'd get full edit history just by running 'git log', and if there were conflicting edits to the same report/comment on the local and remote side, git would try to merge just like any other branch divergence. But the dit wrapper script could configure it to bail out by default and force the user to deal with it.

The main obstacle I can see is access control. Most projects would like to allow issue contributions from anyone but limit commit access to the code (obviously). This doesn't map well to public hosting services' access models; even if you use separate repos for issues and code, (a) at least GitHub doesn't even have an "allow commits from anyone" option, and (b) even if there were such an option, you don't want to allow anonymous users to edit any comment, which corresponds to minimal traditional 'commit access', let alone force push or delete, which usually comes along with it. But you do want to allow users to edit their own comments, which might be possible with custom logic based on signed commits.

So basically one would want a custom 'pre-receive' or 'update' hook. I imagine a suitable script will eventually be included in the git-dit repo, which should work fine for self-hosting, but public Git hosting services don't allow uploading arbitrary hook scripts. (GitHub has webhooks, but they're asynchronous so can't block commits, and as I said, there's no anyone-can-commit option anyway.) I guess projects which want to be on GitHub could host an intermediate repo somewhere which allows pushes from anyone but filters them, then pushes on to GitHub from a trusted account…

Does my thinking make sense?

musicmatze
Hi. As angrow has written, yes, patches/patchmails would be an option. We did this explicitly leaving out the access-control problem, which is a hard problem by itself.

Currently we would think of emails as first step, which clearly would make it harder for newbies, true. We also thought about other possible workflows but in the end a project needs some people accepting issues. This could be automated with git-dit of course - something like `git dit fetch-issues --from repo@repohost` which then asks the maintainer for each new issues to review and accept or reject it with a single keystroke. Either way, we currently see no way around that problem.

comex OP
> Either way, we currently see no way around that problem.

Hrm… assuming you mean in general rather than just on GitHub/etc., why wouldn't a pre-receive hook work? Not that `git dit push` is especially friendly to newbies (for that there's no way around a web interface, which is of course a possibility), but it would provide a standard 'protocol' for submission. It's not great if the maintainer needs to approve not only every issue but every comment from the public.

angrow
Or you could just treat issues as another kind of patch, which anyone could send by email or pull request, and maintainers could accept, reject, modify, clarify, etc.

It's true this would be harder for less technical users to submit problems. You might want a way to map anything submitted by Github Issues or the like into patches, though you could also do it manually.

This item has no comments currently.