Page MenuHomePhabricator

investigate shared inbox options
Closed, ResolvedPublic

Description

as discussed in ops offsite,

investigate options to have a shared inbox, where you can see which emails have already been read/answered by others, to be used for maint-announce and maybe other (dns-admin@) mails that should be processed by the group rather than individuals

Event Timeline

  • OTRS
    • (+) Can have private comments/notes (no idea how it works in real life practise)
    • (+) Already in-use and hosted within the WMF community
    • (-) Yet another user account to maintain
      • Can be migrated to use LDAP authenication
  • @emailbot
    • (-) Home brew solution/on-going maintenance vector
    • (+) Into a private space into Phabricator
  • OTRS
    • (+) Can have private comments/notes (no idea how it works in real life practise)

Assuming it still works the same way it did when I was an agent - it gives users the ability to add extra messages to the thread internally within OTRS that don't get sent out to the "customer".

Dzahn triaged this task as Medium priority.

@Peachey88 thank you for summary, that is very useful. i'll report back to the team

mailed the ops list with a summary of this. comments welcome

mailed the ops list with a summary of this. comments welcome

I would think that using @emailbot is non-ideal. I use it daily for my work in S4 with vendors, and just getting it to work there is hit and miss. It needs quite a bit more tweaks for the limited sub-set of email encoding we already get from those few vendors. I think trying to make it work for all of the maint-annoucements would be problematic.

Shared Google Inbox/Groups seems like we would have to ensure we never reply back to the vendors, and ONLY reply to ourselves in each thread to confirm processing. I have no experience with it though, so I don't really have a strong viewpoint on it.

As long as Nuance can shove all of those tasks/tracking tickets into a private space (since we cannot have our maint-annoucements made public), it seems like something to try out. In particular if it can work in conjunction with the current alias going to it and RT (for fallback tracking using the old process.)

I would prefer we try out Nuance (and keep operations workflow within phabricator) over branching our ops clinic workflows into OTRS.

That being said, I already have an OTRS account so I'm happy to assist in any testing of solutions.

As fas as a shared inbox goes my experience with such an approach was that we ended up using it as an archive and not as tracking. Shared Google Inbox/Groups might end up better, at least it looks like it from its page, but I have no experience at all with it. It does have the minus (-) of being practically outside the main ticketing system (phabricator) so chances are it will be a second class citizen, same way RT is now.

As far as OTRS goes, we have the choice of going either with the current installation or a completely new one.

The latter brings us exactly back to the state we are with RT, just with a (personal opinion) slightly better interface. Having to maintain a server+service that is practically one more ticketing system that is going to be second class citizen since the first class citizen is phabricator.

The former just removes the extra maintainance burden of the extra server+service since we will be using the current installation. But it does come with caveats. Admins/users in that installation are members of the community which means less control for us. Also it does raise the issue of volunteer access to our queues. That's true for the admins only of course, who get access to all queues. I don't consider it important, but it has to be made clear.

In both cases, it's an extra ticketing system that will de facto be a second class citizen. So it's just a tad better than RT.

As far as Nuance goes, I think we should evaluate it a bit more. Perhaps it would make sense to clearly specify what our requirements are for this ? Cause I am not fully clear on these.

at $day_job we have a mailbox that recives maint-announce emails and that goes to our ticketing system.

You could do the same by changing the current maint-announce email to task@phabricator.wikimedia.org.

You can even request the vendors to have the first line of the body announce to have !projects maint-announce and it will automatically add the project.

In addition, one can set a new mail address, (e.g. maint-announce@phabricator.wikimedia.org.) and with herald rules automatically add project maint-announce and mark private, give this address to vendors.

Mailing into Phabricator has indeed proven to be pretty hit-and-miss, so let's not do that for now.

The Google Shared mailbox seems worth trying, and should be easy to experiment with.

@Dzahn - could you look into getting one setup, and adjust the mail alias so it goes to both the mailbox and RT for now?

@mark Yep, sounds good. I'll get into that.

Josephine of OIT has created a new Google group for us, we agreed on "ops-maintenance@" (ZenDesk (#11955) )

We can enable the shared inbox ourselves following instructions on

https://support.google.com/a/answer/167430

group is at https://groups.google.com/a/wikimedia.org/forum/#!forum/ops-maintenance

@RobH and myself are initial owners of the group.

I have invited Ariel, Jeff and Papaul as members and tested mailing the group from my personal address and replying to it. It worked and shows as a "topic" in the group. Also set group welcome message.

I have not yet edited the alias for maint-announce@ to actually forward mail to this though.

I tested what happens if you send mail to the group address from an external non-WMF domain, and i got this auto reply:

We're writing to let you know that the group you tried to contact (ops-maintenance) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

 * You might have spelled or formatted the group name incorrectly.
 * The owner of the group may have removed this group.
 * You may need to join the group before receiving permission to post.
 * This group may not be open to posting.

If you have questions related to this or any other Google Group, visit the Help Center at https://support.google.com/a/wikimedia.org/bin/topic.py?topic=25838.

Thanks,

wikimedia.org admins

I looked closer at permissions and general settings of group and changed it so that most actions can be performed by all group members, only members can read topics (messages), but the public can post them. all organization (wmf) members can ask to be added.

Then i sent another test mail from external and it shows up now as a new "topic".

Also changed settings so that there are mail footers with "unsubscribe" link.

Dzahn changed the task status from Open to Stalled.Apr 25 2017, 11:57 PM
Dzahn changed the task status from Stalled to Open.May 22 2017, 4:52 PM
Dzahn raised the priority of this task from Medium to High.

I got positive feedback from at least 3 people using the new Google group. I think i can safely say we are staying with this as thew new solution.

We can turn off the email flow into RT i think.

Dzahn lowered the priority of this task from High to Medium.Jun 16 2017, 7:48 PM

Since we have the new system running since a couple weeks and there was only positive feedback.. i now disabled the duplicate mails still going to RT. Now they only go to our new Google group.

And i will call this resolved.