#social 2020-01-22

2020-01-22 UTC
tantek joined the channel
#
fr33domlover jaywink[m], nightpool[m], trwnh: another question about this: For some kinds of objects, e.g. tickets, MRs, commits etc. the title and the summary are the sane thing, I've been using 'name' for those (e.g. ticket title) and wondering whether to use 'summary' instead. No particular reason to do that, just wondering and wanting to decide on this
#
fr33domlover (current situation is to use 'name' for titles of stuff, and 'summary' only if there's some description in addition to the name)
#
fr33domlover e.g. for repos, 'name' could be the repo name and 'summary' is the short description text
#
jaywink[m] I kind of prefer summary for ticket, MR, titles. But for repos, definitely name should be the name of the repo, summary would make no sense
#
jaywink[m] not sure a ticket or PR should have a name?
#
fr33domlover jaywink[m], well in some platforms that one-line title is called the name of the object
#
fr33domlover So I'm finding both 'name' and 'summary' to be candidates
#
jaywink[m] but for example github, gitlab etc have "name" and "description"
#
jaywink[m] and clearly name ... is a name, not a summary :)
#
fr33domlover jaywink[m], well sometimes a name is a summary :) e.g. in Darcs the one-line text of a patch is called the patch name (that's the equivalent of the first line of a git commit message)
#
fr33domlover But yeah can switch to summary
#
jaywink[m] well, you're going to need two fields anyway, to fit both cases
#
jaywink[m] otherwise one can't replicate what github etc do
#
fr33domlover jaywink[m], well yeah but that's for repos. I'm asking about other stuf, e.g. a ticket. WHere does the ticket title go, 'name' or 'summary'? ^_^
#
fr33domlover If we do want to represent those ticket IDs that forges have, they could be 'name' and ticket title goes to 'summary'
#
jaywink[m] voted already for summary :)
#
fr33domlover Ok +1 for summary :)
#
jaywink[m] btw commented on the ticket ID's in the forgefed repo
#
jaywink[m] tl/dr; I think it adds a lot of complexity and doesn't fit the way mentions work in the fediverse
#
jaywink[m] because that's what the use case is for, mentioning other tickets and such
#
jaywink[m] numeric ID's don't work very well in a distributed space
#
fr33domlover jaywink[m], I agree. Commenting on your comment now
tantek_, ajordan, Chocobozzz, ajordan_ and BitBot joined the channel
#
fr33domlover o/
#
tantek_ o/
#
fr33domlover ForgeFed question, seeking advice: When commenting on a patch sent by email, comments on different versions of the patch are separate, since each version is a separate email. Is it important to keep it separate in ActivityPub too? Imagine a Patch object you keep Updating, and people comment on the patch, and then all the comments about the different versions are mixed together. So I'm thinking, it would
#
fr33domlover be beneficial if the topic of the discussion is something whose ID URL changes with each Update, but without deleting the previous versions. For example if a patch is represented as a Ticket with a Patch attached, there can be comments on the Ticket, and there can be code review comments on the Patch itself. Update on the Ticket can change the ID URL of the attached patch, allowing for separate code
#
fr33domlover review on the new version. Perhaps the Ticket or the Patch could keep a list of the previous versions etc. How does that sound?
#
fr33domlover tantek_, ^
#
fr33domlover ^_^
#
tantek_ I think it's important for each such "post" to be its own URL, especially since it can come from different authors
#
tantek_ versioning is a bit more interesting
#
tantek_ as I do think edited posts should keep their URL *and* provide some way to view older versions
#
fr33domlover tantek_, how about when you create a new Patch, right from the start it has a list of versions and it has only 1 item there of course, so that when you add more versions, the Patch itself retains the same URL?
#
tantek_ That makes sense to me and for example is how GitHub pull request URLs behave AFAIK
#
tantek_ "Patch itself retains the same URL"
BitBot joined the channel
#
fr33domlover tantek_, hmmm but there's another option: If we represent a patch/merge request as a Ticket with a Patch attached, then the Ticket can keep the same URL while the attached Patch gets a new URL for each new version
#
fr33domlover Which is kind of very similar
#
tantek_ That option is also reasonable. I think that's how bugzilla works
#
tantek_ bugzilla bugs keep the same URL, whereas you attach new patches to it for edits
#
tantek_ and each patch attachment gets its own link
#
tantek_ I think I prefer the GitHub model. I like the *separate* conversation around a specific patch, and edits / updates to that patch, independent of the issue(s) it is trying to fix/resolve
#
fr33domlover tantek_, that separation would be the case either way: Imagine we represent a merge request in ActivityPub as a Ticket. So you'd have 2 tickets: The one that says "I found a bug" and a ticket that says "Please review this code, it's a fix for issue #123". Both the issue and the merge request would be a Ticket in AP behind the scenes, and they'd get separate discussion the way it's on githu8 etc.
#
fr33domlover wonders how to represent the comments and code review of different patch versions
#
tantek_ I think that duplication of tickets is confusing will cause forked conversations
#
tantek_ the only "ticket" (what the IndieWeb calls an "issue", same as GitHub: https://indieweb.org/issue) is the "I found a bug" post
#
tantek_ "Please review this code" is a pull request with an invitation for review
#
tantek_ For "how to represent the comments and code review of different patch versions", I'd study how GitHub does it, their UX there seems to work fairly well to communicate which coments/reviews apply to which versions of a pull request
#
fr33domlover tantek_, yeah that's what I mean. I just meant, the "pull request" could be of type 'Ticket' in its ActivityPub representation; that's just trivial detail. The point is that the ticket and the "pull request" can be separate objects
#
fr33domlover On which we seem to agree, so, no problem there
#
fr33domlover Good point, I'll check how gitlab ce does it :p
#
tantek_ yes the issue and pull request should be separate "objects" (posts) :)
#
tantek_ Good point, definitely worth documenting more real world examples beyond GitHub
#
tantek_ Feels weird to make pull request a "ticket". weird like semantic dilution
#
tantek_ pull request feels more like an edit post: https://indieweb.org/edit
#
fr33domlover Well technically a merge request is a work item that says "review this code"
#
fr33domlover e.g. iirc in Gitea they share the numbering sequence
#
tantek_ disagree, I don't think pull requests have strongly implied review semantics on their own without explicit invitation to review
#
tantek_ maybe in some communities there may be that assumption
#
fr33domlover tantek_, hmmm then let's rephrase, how about this: a merge request is a work item that says "merge this branch into the code"
#
fr33domlover or "hi, here's some code, maybe you'll find it useful to merge"
#
tantek_ those sound reasonable
#
tantek_ I consider it a special case of, here's some typo fixes to your blog post, maybe you'll find it useful to incorporate them
#
tantek_ which is why I prefer to think of code/branch suggestions as edit posts
#
tantek_ in reply to some sort of original
#
fr33domlover tantek_, how would you represent such an edit post in ActivityPub, and what would be the original?
#
tantek_ the original could be any post
#
tantek_ IDK if ActivityPub ever got the explicit semantic of an edit post, so you'd have to start with a reply
#
fr33domlover Thanks for the feedback, tantek_ :)
#
tantek_ Appreciate the discussion fr33domlover, hoping increasing shared understanding increases chances of interop across systems
#
fr33domlover :)
#
fr33domlover tantek_, / everyone else: How are quotes represented in AP? Does anyone have those in their implementation? I mean like quoting someone else's words in your message
#
fr33domlover Asking because we could represent commenting on lines of code in a similar way ^_^
#
fr33domlover gtg bbl o/
#
tantek_ commenting on lines of code is interesting. maybe https://indieweb.org/fragmentions can help with that
#
tantek_ ttyl fr33domlover !
#
trwnh fr33domlover: you probably want name+summary or summary+content. a repo doesn't really have text content, but an issue might.
includeals and biodan joined the channel
#
csarven fr33domlover: Check out Web Annotation's quote selector: https://www.w3.org/TR/annotation-vocab/#textquoteselector (or see many other ways of selecting different kinds of media) for quoting (with some existing motivations eg. commenting, or just use your own). There is also the URI selector based on the same model: the https://www.w3.org/TR/selectors-states/ that you can use to target practically anything. JSON-LD friendly if you want to mix it up with AS2.
#
csarven If you're not familiar with Web Annotation, see a live example in the marginalia here: https://csarven.ca/linked-research-decentralised-web#abstract , where the annotation (a reply) is under different authority than the article it is replying to. LDN (which is in AP) is used as the mechanism to discover the notification about the annotation..
#
csarven fr33domlover: As for "one-line text description of a repo", as:summary sounds good to me. If you're not restricted to only using AS2, you you may want to look into DOAP (Description of a Project): https://github.com/ewilderj/doap .. See http://usefulinc.com/ns/doap and eg. doap:shortdesc
#
Loqi [ewilderj] doap: RDF schema for describing software projects
#
csarven ctrl-f "repo" for repository related stuff.
BitBot joined the channel
#
fr33domlover Thanks for the feedback csarven!