Hmm... if the function carried out by RT is this, Github's issue tracker is a _direct competitor_ to it! E.g. it also tracks issues and related patches, has labels to classify them, code review tools etc. So, there are only two possible solutions: synchronize them for related issues or somehow replace the built-in tracker at Github with some interface to RT (the third is, yes, to disable the built-in tracker; it can be reduced to the 2nd option by e.g. replacng the UI with the message "use <link> instead"). I would write to Github and ask if they have anything to suggest/provide you for this general problem. It would also clarify their position regarding the competition matter: if they're willing to let other products freely compete with theirs which includes providing tools for that. On 10.04.2016 2:27, Craig A. Berry wrote: > On Sat, Apr 9, 2016 at 2:11 PM, Ivan Pozdeev via perl5-porters > <perl5-porters@perl.org> wrote: >> Github PR are yet another channel of contribution. Some may prefer its >> interface to p5p. >> Your incentive appears to be to avoid splitting the discussion between >> multiple places. >> If so, why not have them replicated here like RT already is? >> https://github.com/google/pull-request-mailer looks like the thing made with >> exactly this in mind. > The thing is, patches need to go to RT first so they can be tracked > and only then forwarded to the mailing list for discussion. But the > thought of an automated mailer on GitHub sending patches to RT, and > then (much worse) the two automated systems managing responses gives > me a headache. The maintainers of RT and the perl.org mailing lists > have enough things to give them nightmares already. -- Regards, IvanThread Previous