I agree, I think we need something else. Based on the previous discussion, I wouldn't want to see the patch I submitted in my codebase.
Probably we need to at least send the response to the pool it came from and have a flag that enables the response posting (it should not be the default). I did think about the idea of sending the responses to a specified pool. I think this introduces a real danger of facilitating messages escaping their pools (since most responses will include all or part of the posted message). Ethan On Tue, Dec 15, 2009 at 7:04 AM, Anne Kathrine Petterøe <[email protected]> wrote: > I agree with you Vassil. We need to keep the default timeline as clean as > possible and let the users chose what they want to see. > +1 to both of the points suggested. > > /Anne > > On 15. des. 2009, at 11.10, Richard Hirsch wrote: > >> I'd like to blog about 12sprints integration today if possible and >> that means using Ethan's change as an interim solution. >> >>> * have a way to specify whether we post the response or not >>> * post the response to a pool so we don't pollute the timeline of others >> >> I agree to both points. The ideal solution would be to have some flag >> "pool=[poolname]" that is added to the action. If is present, the >> response is returned. If not, then the response is ignored. >> >> What about sending the response to the pool in which the trigger >> message was located? >> >>> create bots in the long term. And, who knows, someone might contribute >>> XMPP integration, which would make interaction much easier ;-) >> >> This would of course be very cool. >> >> D. >> >> On Tue, Dec 15, 2009 at 10:59 AM, Vassil Dichev <[email protected]> wrote: >>>> I wanted to integrate the open patches today and wanted to discuss >>>> whether I should commit Ethan's change or not. >>>> >>>> Any reason why I shouldn't commit it. I think it is good interim >>>> solution but not the final one. >>>> >>>> This could also help with our integration with akibot. >>> >>> Depends on how fast we need the integration scenarios working. I would >>> prefer if we do either or both: >>> >>> * have a way to specify whether we post the response or not >>> * post the response to a pool so we don't pollute the timeline of others >>> >>> The biggest problem here is not only that there's too much noise in >>> your timeline, but that all of your followers would have to either put >>> up with these responses or create a filtering action themselves. Long >>> term we have to make the defaults as clean as possible. >>> >>> So, the question is: how fast do you want this repost feature? >>> >>> As an aside, specifically for the integration scenarios we could >>> create bots in the long term. And, who knows, someone might contribute >>> XMPP integration, which would make interaction much easier ;-) >>> > >
