[Sir_Cmpwn]

Thanks for your detailed thoughts, I'm taking all of this down and using it to influence my work on lists.sr.ht (the mailing list and code review tool I'm building).

The chores of this approach - finding and collating feedback, sheparding a patch through the flow, and so on - are all things I'm acutely aware of. I don't think we need to throw the baby out with the bathwater like GitHub does, though, and I see these as places to improve our tools rather than replace them.

Take a look at this here:

https://git.sr.ht/~emersion/python-emailthreads/tree/test/da...

The specific output format you see here is just a testing tool, this isn't the final user-facing product. The important part is ingesting a bunch of emails and creating a thread where you can associate all of the responses over time with the particular parts of the patch. Combining this with a gerrit-like tool which tracks new patches over time and avoids duplicating review work is planned.

[cryptonector]

Thinking about it more... There is not much need for XML.

The inputs are plaintext replies (or HTML formatted as plaintext).

The original document is immutable.

There is no state (because it can be collated from scratch every time). EDIT: If updates are allowed in any non-email based way (e.g., via a BUI, REST APIs) then email must be generated and sent so that all the state is in the email archives and all participants can collate the same state.

But the result of the collation is more like a database and less like a document. In particular there's not much need for marking up commentary.

Multiple collation output formats will be needed: plain text, XML, XHTML, JSON. These formats/schemas are only needed for display purposes, not interchange, as the collation results can be computed independently by all who have access to the emails. This means there is nothing to standardize!

Thus collation state can be kept any way you want. XML, SQLite3, some NoSQL, any in-memory representation you like -- whatever suits you. Still, I'd use anything that has a nice, declarative query language. XML (XSLT/XPath), JSON (JSONPath, jq), or an RDBMS (SQL) -- all will do. For you, and given your emphasis on open source, SQLite3 or PostgreSQL will work best, I think. You can generate all of the output formats you need from such a database.

[cryptonector]

No, of course we shouldn't throw the baby out with the bathwater. But this is, for me and many others, the biggest issue in using an email-driven approach to code review and patch integration -- I say this as a very TUI-focused user, a tmux/mutt/vim/cscope/shell/... power user. That's not a fatal problem, but a critical challenge. Simply put, without a way to address this issue satisfactorily, an email-driven approach to patch integration will only be a niche thing. Now, mutt and such only work for a small enough number of people, so they are niche tools too. But email-driven patch integration will be even more niche, though it could be at least as popular as vim if this problem is solved.

Another thing is that with an approach to email code review that solves the collation problem you might... be able to seamlessly bridge email and web interfaces. For example, GitHub does actually have an email interface -- a very poor interface (markdown won't be interpreted, yo wth GH?) and only for issues, not code review. But your service could provide a superior email interface to code review... that also plays well with the web. I'm glad you're already thinking of this.

(GH doesn't care about email integration because with a REST API and BUI they can cover all their users' needs (except email-centrism!) without having to deal with the challenge of email issues (like this collation issue). GH has chosen to not bother with email, while you're taking up the challenge. As a lover of email, I say good for you (and for the rest of us)!)

Again it's tempting to think of XML. If you want to convert to a plain text format, XSLT can do it. And if you want to convert it to HTML, XSLT can do it. Or you can fetch the XML with XHR. Or convert it to JSON for fetching with XHR... again, XSLT can do it (well, I've never written XSLT code to produce JSON, and I'm guessing doing it right isn't easy, but maybe newer XSLT iterations have support for JSON? idk, I've not followed it). If you use JSON you could use jq, natch, but JSON is a poor format for what is really document-like data, so I'd stay away from JSON. Even if you choose not to use XML (I wouldn't blame you! XML is for masochists), thinking about this problem with XML in mind might help you design a non-XML format that covers all the things you need to cover.

I'm not just a TUI power user. I'm also a jq and XSLT power user, meaning that APIs (meaning, nowadays, "RESTful" APIs) are very convenient. Structured document formats add a lot of value, but in an email context you just can't access that value due to lack of a) a notion of "email API", b) MUA integration with editors for different MIME types, c) a total dearth of editors for those formats lying in between vim on the TUI side and Word on the GUI side. In this particular context you have the benefit that you can consumer plain text and extract from it commentary due to the traditional email angle-bracket quoting style, then merge that content into a structured document from which you can render plain text again if desired.

Anyways, really, best of luck. If you want to exchange further thoughts off HN, I'm sure you can find my email address.