19:03:30 <ggus> #startmeeting RT meeting
19:03:30 <MeetBot> Meeting started Thu Jan 16 19:03:30 2020 UTC.  The chair is ggus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:56 <ggus> I have some topics to discuss about RT
19:04:14 <ggus> the first one is about this proposal: https://trac.torproject.org/projects/tor/ticket/32893
19:04:46 <ggus> community team would like to have a new training alias: training@tpo to RT
19:05:29 <ggus> we thought about using frontdesk@tpo, but we are afraid on missing these emails in other support request
19:06:33 <ggus> at the moment we're ccing everyone from ux and community team and partners
19:06:56 <ggus> people forget to click 'reply to all' and then some of us are missing replies
19:07:07 <anarcat> yeah that doesn't scale :)
19:07:43 <ggus> we would like some thoughts from you about scaling
19:07:44 <anarcat> in the ticket you also mention "Use Gitlab kanban to have an overview"
19:07:53 <anarcat> nextcloud
19:07:56 <anarcat> and an irc channel
19:08:08 <anarcat> just to be clear, how would that interact with RT?
19:08:13 <anarcat> or are those different proposals?
19:08:24 <anarcat> ggus: about scaling RT?
19:08:34 <ggus> no, about scaling my work hehe
19:08:43 <anarcat> ha
19:08:48 <anarcat> well i am not sure i can comment on that...
19:10:06 <hiro> I think an alias is a good way to have people contact you without using the personal email
19:10:08 <anarcat> i mean RT scales fine, it's solid and i've rarely seen it choke on large loads
19:10:15 <anarcat> it has trouble searching large attachment sets
19:10:20 <anarcat> but that's about it
19:10:25 <anarcat> that too yes
19:10:36 <anarcat> might be a good and easy first step
19:11:34 <anarcat> *crickets*? :)
19:12:10 <hiro> nextcloud and gitlab may be a good way to share material or for you to organize content...
19:13:47 <pili> so the idea with irc integration could be something like the bots we have right now to inform us of events
19:13:58 <pili> although I'm not sure if that's something ggus was still thinking of
19:14:31 <pili> we also have a kanban where we progress partners from one stage to another
19:14:45 <pili> e.g intro email sent, training partner agreement signed, training scheduled
19:14:46 <ggus> sorry, my irc session freezed
19:14:49 <hiro> is that a RT kanban?
19:14:56 <pili> nope, in gitlab
19:14:59 <hiro> ah ok
19:15:06 <pili> based on tags
19:15:16 <pili> so we have a card/issue for each partner
19:15:24 <anarcat> i see
19:15:27 <ggus> at the moment we're doing everything manually, and in april we're going to do a public launch
19:15:30 <anarcat> how would we bridge gitlab and RT?
19:15:50 <ggus> anarcat: i saw some sort integration of rt and gitlab
19:15:57 <pili> I know gitlab has APIs, not sure about rt
19:16:02 <pili> ggus: oh, I didn't know that :)
19:16:03 <anarcat> they both have APIs
19:16:16 <anarcat> but that doesn't mean it's easy to integrate
19:16:30 <anarcat> i would particularly worry about integrating gitlab's kanban and RT, for example
19:16:42 <anarcat> because you'd end up having to synchronise two ticket tracking systems
19:16:43 <hiro> are contacts with partners private?
19:16:44 <anarcat> not idea
19:16:47 <ggus> hiro: yep
19:16:48 <anarcat> ideal*
19:17:05 <hiro> could you invite them to gitlab and have private projects with them?
19:17:21 <ggus> i was also thinking if we could have training@tpo pointing to a private repo in gitlab
19:17:22 <pili> anarcat: can you have custom status in rt
19:17:29 <pili> ?
19:17:36 <anarcat> pili: i don't believe so, but maybe?
19:17:41 <pili> e.g with automatic actions at each stage
19:17:44 <anarcat> pili: why would you want that?
19:17:53 <anarcat> hum
19:18:00 <anarcat> what do you have in mind?
19:18:01 <pili> to mirror the gitlab stages
19:18:03 <anarcat> what kind of action
19:18:32 <pili> so, a potential partner sends an email
19:18:47 <pili> we automatically send a response with the details, they reply with the details, the ticket transitions to "pending training partner agreement signature"
19:18:50 <pili> for example
19:18:51 <pili> and so on
19:19:05 <ggus> and we have different people working on each stage
19:19:06 <pili> we have clearly defined actions for each stage
19:19:15 <ggus> one stage is isa signing the agreement
19:19:18 <anarcat> ggus: gitlab can't accept email in the FLOSS edition - we could hack around that with our own wrapper, but the "service desk" feature that does that in gitlab is proprietary
19:19:30 <ggus> another is antonela and nah sending ux test
19:19:47 <ggus> anarcat: ok
19:19:47 <anarcat> there are custom fields in RT that could be used to track those things
19:19:54 <anarcat> in gitlab, you'd use labels
19:20:07 <anarcat> as for sending responses, i am not sure you could do auto-replies on state changes
19:20:12 <anarcat> maybe you could, but i haven't done that
19:20:23 <anarcat> you can auto-reply on ticket creation, that's for sure, and can change that template
19:20:28 <ggus> we thought working on templates
19:20:29 <anarcat> you can also have canned responses in RT, which are different
19:20:46 <anarcat> but could be used by operators to send templated responses at different stages
19:21:29 <anarcat> i think that bridging RT and GitLab would be a lot of work, and i'm not sure having a kanban would be worth that effort :p
19:22:49 <pili> anarcat: fair enough
19:23:53 <anarcat> so i'd say either make a kanban or equivalent in RT, or bridge email in GitLab, but syncing the two is, in my humble opinion, a bad idea :p
19:24:26 <anarcat> as a sysadmin as well, i must say that if we want to get email into GitLab, we get email into gitlab, let's not put RT in the way :p
19:25:06 <anarcat> that said
19:25:16 <ggus> anarcat: this meeting is exactly for that. to understand what gitlab and rt can offer in that context
19:25:19 <anarcat> people seem to be really attached to kanbans around here :)
19:25:26 <anarcat> i don't quite understand that attraction
19:25:43 <anarcat> but if we relax that requirement, i think RT can do whatever you need
19:25:56 <anarcat> or, to reverse that, if you relax the "email" requirement, you could use GitLab
19:26:08 <anarcat> but be warned that registrations is a tricky thing in gitlab
19:26:39 <anarcat> i don't remember if users can register new accounts yet, but that is a typical problem in gitlab instances - spambots register and spam the instance
19:26:42 <anarcat> so we might not be able to rely on it
19:26:55 <hiro> how many partner contacts do you receive?
19:26:56 <anarcat> of course, RT also gets spam, but we have to deal with spam email anyways :p
19:27:00 <pili> maybe we need to write a set of requirements, I think we are not married to any solution or another
19:27:12 <pili> we're just trying to work with the tools available
19:27:26 <anarcat> pili: yeah, it'd be great to have a better spec, with "must have", "nice to have" and "out of scope" requirements
19:27:27 <pili> and explore what options we have right now
19:27:32 <anarcat> right
19:27:58 <ggus> hiro: for this cycle is like ~15
19:28:05 <anarcat> how long is a cycle?
19:28:20 <ggus> until april, and then we open to the world
19:28:44 <anarcat> so what's the rate... like a handful a month?
19:29:13 <ggus> i don't have one, since this is the pilot stage
19:29:31 <ggus> and we saw things don't scale when use private emails
19:30:10 <hiro> so in this case I am trying to understand if creating users in gitlab is too much effort
19:30:23 <hiro> because if that's not too mcuh users you have to create
19:30:36 <hiro> you could create a project for each partner in gitlab maybe
19:32:31 <ggus> hiro: the good part of email is that onboarding is easy
19:32:56 <ggus> with gitlab we would need to have more time for each partner to onboard them
19:33:31 <ggus> but yes, could be a solution
19:33:37 <anarcat> so i just reviewed the RT homepage (!) and yeah, you can have both custom states and custom transitions *and* custom *code* that runs in those transitions
19:33:50 <anarcat> Custom workflows: https://bestpractical.com/request-tracker#block-yui_3_17_2_1_1550179307723_59361
19:34:15 <anarcat> the caveat is that "code" must be Perl :p
19:34:57 <pili> interesting... :)
19:35:26 <anarcat> example of the lifecycle config https://docs.bestpractical.com/rt/4.4.4/customizing/lifecycles.html
19:35:47 <ggus> which version of rt we're running?
19:36:01 <anarcat> and custom actinos https://docs.bestpractical.com/rt/4.4.4/customizing/scrip_conditions_and_action.html
19:36:14 <anarcat> ggus: shouldn't matter, but it looks like 4.4
19:36:27 <anarcat> https://rt.torproject.org/ => »|« RT 4.4.1-3+deb9u3 (Debian) Copyright 1996-2016 Best Practical Solutions, LLC.
19:36:38 <anarcat> i really like RT's business model
19:36:49 <anarcat> their stuff is free software, and they provide consulting on top
19:38:09 <ggus> ok, these links are helpful
19:38:45 <anarcat> i gotta say, RT is pretty much built for that kind of stuff
19:38:51 <anarcat> workflows, lifecycle, and all that
19:39:20 <anarcat> adding a lifecycle requires a sysadmin, but otherwise "Scrips" (custom actions) can be done by an RT admin
19:39:37 <anarcat> so you wouldn't need much of our help, assuming someone knows perl and can decipher those docs :p
19:40:15 <anarcat> also if you really want Kanban + RT, maybe you could figure out if that could be installed :p https://github.com/nixcloud/rt-extension-kanban
19:40:48 <anarcat> (not packaged in Debian, so i'd prefer to avoid it)
19:41:34 <hiro> in theory i am an RT admin
19:41:43 <hiro> but I do not have buffer for taking out RT dev work
19:42:28 <anarcat> yeah i don't think we should assume i would either
19:42:43 <anarcat> the point with RT is more that it does most of what you need out of the box, without our help
19:42:52 <hiro> sorry all I'll leave this meeting a bit before the end of the hour I am hurting a bit again...
19:42:55 <anarcat> you have on-creation auto-replies which you can customize yourself
19:43:00 <ggus> who could setup training@ alias and the RT env?
19:43:08 <anarcat> it's fairly easy to send auto-replies on state changes too
19:43:19 <anarcat> kanban is obviously more work
19:43:22 <anarcat> so would an IRC bot
19:43:34 <anarcat> i would advise against another IRC bot, to be honest :p
19:43:37 <pili> anarcat: those last 2 are nice o have I think
19:43:41 <anarcat> already so much noise
19:43:52 <ggus> nice to have, but not a requirement
19:43:59 <pili> and I would be fine with updating a kanban manually to know where we are
19:44:00 <anarcat> pili: you man kanban and irc are nice to have?
19:44:01 <anarcat> right
19:44:05 <pili> anarcat: yes :)
19:44:08 <anarcat> cool
19:44:23 <anarcat> ggus: setting up RT isn't too much work, i think either me or hiro could
19:45:16 <anarcat> so one thing hiro mentioned when she noticed this discussion is that we might want to eventually depreciate RT
19:45:29 <anarcat> we're thinking of moving stuff like the blog over to Discourse
19:45:42 <anarcat> and that could also serve as an mechanism for what you're looking for, maybe
19:46:00 <ggus> but RT is used for donations, press, etc
19:46:09 <anarcat> sure, it's used for other stuff
19:46:16 <anarcat> the idea is we would replace it with discourse
19:46:31 <pili> anarcat: right, and I think that's something that we wanted to understand also
19:46:32 <pili> before we spend lots of effort in writing a custom solution :)
19:46:36 <anarcat> i'm not saying it's practical in the short term, but if discourse could serve the goals of *this* project, then it might be interesting to consider it in the long term
19:47:03 <anarcat> i personally tend to think RT will be around forever :p
19:47:12 <anarcat> at least as long as email will exist
19:47:18 <anarcat> it's too solid and flexible to just go away
19:47:29 <anarcat> it would be hard to replace by discourse /or/ gitlab
19:47:41 <anarcat> but you know
19:47:46 <anarcat> i'm old and like old stuff :p
19:47:51 <anarcat> so take that with a grain of salt
19:48:02 <anarcat> maybe i'll hate my past self for promoting RT today in a few years, who knows
19:48:42 <ggus> right, so i'll open a ticket on trac for this new instance of RT
19:49:57 <anarcat> i'd know what you mean but just in case someone else finds this
19:50:03 <anarcat> use the word "queue" instead of "instance" :)
19:50:29 <anarcat> because i don't think you want me to create a new database with an entirely different RT with distinct users, queues and so on
19:50:29 <ggus> anarcat: i thought it was needed a new instance
19:50:38 <anarcat> i don't think so
19:50:49 <anarcat> a single RT instance can handle multiple email addresses, each in their own queue
19:50:56 <anarcat> lifecycles can be distinct, per queue as well
19:51:02 <anarcat> same with templates and so on
19:52:19 <anarcat> ggus: does that make sense?
19:52:54 <ggus> anarcat: only RT admin can change RT lifecycles?
19:53:12 <ggus> it does
19:53:19 <pili> ggus: fwiw I'm an RT admin also
19:53:36 <anarcat> only sysadmins, i think yes
19:53:36 * pili should probably read some more on RT...
19:53:46 <anarcat> the sysadmins can create new lifecycles
19:53:53 <anarcat> and then RT admins can assign them to queues
19:53:57 * pili doesn't think she's a sysadmin :P
19:54:04 <anarcat> i don't think so either :)
19:54:14 <anarcat> that would involve giving you write access to the on-disk RT configuration
19:54:26 <anarcat> which i don't exclude outright, it's just not the case yet
19:54:31 <pili> hehe
19:54:36 <pili> nono, thank you :D
19:54:40 <anarcat> i don't think you need to be sysadmin in this case, i can create the lifecycles if you really want them
19:55:01 <anarcat> but right now i would advise using the existing states and just create a new lifecycle if you really, really think the existing states don't suffice
19:56:43 <ggus> anarcat: for the ticket do you also need lifecycle details? or just the queue name?
19:57:02 <ggus> what are the details that we need to fill, so you/sysadmins can create it?
19:57:04 <anarcat> just the queue name for now, i'll assume my life will be easy and i won't need to create a lifecyle :p
19:57:13 <anarcat> email address, queue name, who should have access to it
19:57:46 <ggus> thanks, i think that's it
19:57:52 <ggus> pili: anything else?
19:58:31 <pili> I don't think so
19:58:32 <pili> I think we need to go off and do some reading :)
19:58:44 <anarcat> alright
19:58:55 <anarcat> would be happy to just give a queue to play with, for starters
19:58:59 <anarcat> i think it would already go a very long way
19:59:51 <ggus> #endmeeting