From ticker-lists at lister.dnsalias.net Mon Oct 10 16:22:17 2005 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Mon Oct 10 16:24:09 2005 Subject: [ticker-dev] Reply-To and Reply-From Message-ID: Hi all, Protocol development seems to have been stagnant for a while, but I'd like to propose a couple of new attributes related to cross-channel threading that I think would be useful. This might be a bit contentious because I know not everybody believes in cross-channel threading, but I see it and use it frequently (and find it useful) and think it could be made even more useful if these attributes are widely adopted. There are two main situations in which cross-channel threading is used that I've seen. The first is when a conversation starts on one topic and then meanders (or branches) off onto another topic that is more appropriate in a different group. This is frequently a conversation moving (in either direction) between technical work and casual chat or between different fields of work. The other common situation is producers that essentially have their own group but may trigger discussion that is best done in another group. For example we have cvs2ticker set up to report all CVS commits to a "cvs" group, but that may trigger discussion about the merits of that particular patch, more work that needs to be done or other related technical issues, all of which is better done in the "dev" group. Similarly our automated builds generate a notification to the "build" group but can cause conversations about the causes of build failures that are best done in "dev". Currently they're sometimes done in "dev", sometimes in "cvs" or "build" and often the conversation switches at some arbitrary point when somebody realises they're on an inappropriate channel. There's an argument that both CVS and build notifications (as well as anything else that might be related) should be in the same group as technical discussion. In fact we used to operate this way some years back but there sufficient feeling that they should be split that we did so. More recently we've also had the need to split some technical discussion into different groups. Anyway, the first new attribute is "Reply-To", which specifies the name of a group that replies should be sent to by default (if different to the current group). The intended use of this is producers in the second case above. Both our CVS and build producers set a "Reply-To" attribute with a value of "dev" and, if ticker clients honoured it, follow-up discussion would always go to "dev" unless explicitly overridden by the user. I don't see a particular need for the GUI of Tickertape clients to be complicated by an option to set it on outgoing notifications, though. The other attribute is "Reply-From", which specifies the name of the group of the message that this message is in reply to (if different to the current group). For example, anybody replying to a CVS notification would set a "Reply-From" attribute with a value of "cvs". This allows other consumers to see where it was that something came from, and possibly assist them in getting context if they needed to. I would suggest that Tickertape clients, as well as emitting the attribute where appropriate, display the message with "(from cvs)" prepended, or something along those lines. This includes scrollers and threaded history displays within both clients and loggers where the message parent is not shown immediately above the message. Below is an example of both attributes in use: --- A commit notification on "cvs", with replies directed to "dev": Group: "cvs" From: "alice@example.com" Message: "In yatc: Modified scroller.s: Initialise foo before bar so that baz doesn't break. Fixes bug #123." Reply-To: "dev" Message-Id: "a" --- A follow-up comment directed to "dev" by the Reply-To attribute: Group: "dev" From: "alice@example.com" In-Reply-To: "a" Reply-From: "cvs" Message: "I think that's the last of the serious bugs fixed for this week. We can move on to those new features next week." Message-Id: "b" --- A reply directed to "Chat" by hand: Group: "Chat" From: "bob@example.com" In-Reply-To: "b" Reply-From: "dev" Message: "Yay! I reckon that makes it beer o'clock." Message-Id: "c" --- Possibly both attributes should have "-Group" on the end of them to make them a bit less ambiguous and to reduce the chance of collision with something different in the future. "Reply-From" could possibly also do with a better name. Any thoughts? Anybody interested in implementing this? Ian From david at mantara.com Mon Oct 10 18:27:21 2005 From: david at mantara.com (David Arnold) Date: Mon Oct 10 18:27:34 2005 Subject: [ticker-dev] Reply-To and Reply-From In-Reply-To: Your message of "Tue, 11 Oct 2005 07:22:17 +1000." Message-ID: -->"Ian" == Ian Lister writes: Ian> Protocol development seems to have been stagnant for a Ian> while, but I'd like to propose a couple of new attributes Ian> related to cross-channel threading that I think would be Ian> useful. for some related historical content, see also http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/follow_up_reply_to/index.html d From ticker-lists at lister.dnsalias.net Mon Oct 10 18:35:28 2005 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Mon Oct 10 18:36:19 2005 Subject: [ticker-dev] Reply-To and Reply-From In-Reply-To: References: Message-ID: On Tue, 11 Oct 2005, David Arnold wrote: > for some related historical content, see also > > http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/follow_up_reply_to/index.html Thanks, I'd forgotten about that. Any recollection or record of what happened to the idea or why it didn't go into Tickertape v3? Cheers, Ian From Matthew.Phillips at dsto.defence.gov.au Tue Oct 11 20:28:06 2005 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 11 20:31:20 2005 Subject: [ticker-dev] Reply-To and Reply-From Message-ID: <6949B1A32630D811B8CB00306E013ADE032D7E83@EDNEX502> > From: ticker-dev-bounces@tickertape.org > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of Ian Lister > Sent: Tuesday, 11 October 2005 6:52 AM > > Protocol development seems to have been stagnant for a while, > but I'd like to propose a couple of new attributes related to > cross-channel threading that I think would be useful. This > might be a bit contentious because I know not everybody > believes in cross-channel threading, but I see it and use it > frequently (and find it useful) and think it could be made > even more useful if these attributes are widely adopted. [snip] > Anyway, the first new attribute is "Reply-To", which > specifies the name of a group that replies should be sent to > by default (if different to the current group). [snip] I'm still a bit dubious about cross-channel threading from a general usability POV, but would still be happy enough to implement Reply-To for the other reasons you described. I have an ulterior motive for doing this because the current personal-messaging-via-Thread-Id-subscription based system that I implemented in Sticker is proving hard for most non-Matthew's out there to grok :/ The obvious alternative would be just to use Reply-To to ensure a reply goes to the correct personal channel and display all "personal" channels in a single list. It also has the advantage that this would work with other clients, since I haven't seen great deal of enthusiasm outside of Sticker for Thread-Id based auto subscription One aspect of Reply-To that isn't clear is whether we want to be able to set Reply-To for news channels? Cheers, Matthew. From phelps at gnusto.com Wed Oct 12 03:36:09 2005 From: phelps at gnusto.com (Ted Phelps) Date: Wed Oct 12 03:36:12 2005 Subject: [ticker-dev] Reply-To and Reply-From In-Reply-To: Your message of Tue, 11 Oct 2005 07:22:17 +1000. References: Message-ID: <200510120836.j9C8aAaT021513@laika.gnusto.com> Ian Lister writes: > Anyway, the first new attribute is "Reply-To", which specifies the > name of a group that replies should be sent to by default (if > different to the current group). The intended use of this is > producers in the second case above. Both our CVS and build producers > set a "Reply-To" attribute with a value of "dev" and, if ticker > clients honoured it, follow-up discussion would always go to "dev" > unless explicitly overridden by the user. I don't see a particular > need for the GUI of Tickertape clients to be complicated by an > option to set it on outgoing notifications, though. I think this makes sense and I intend to add it in xtickertape-2.1 unless someone comes up with a clever objection. > The other attribute is "Reply-From", which specifies the name of the group > of the message that this message is in reply to (if different to the > current group). For example, anybody replying to a CVS notification would > set a "Reply-From" attribute with a value of "cvs". This allows other > consumers to see where it was that something came from, and possibly > assist them in getting context if they needed to. I would suggest that > Tickertape clients, as well as emitting the attribute where appropriate, > display the message with "(from cvs)" prepended, or something along those > lines. This includes scrollers and threaded history displays within both > clients and loggers where the message parent is not shown immediately > above the message. I can see that this could be useful. I'll have to think about how I'd like to see this information presented to the user, but I have no objection in principle. Again, for xtickertape-2.1. Cheers, -Ted