Splitting responsibilities of Google Apps

Mozilla Communities Web Services
#1

So, right now, I don’t know who should be managing Google Apps, there isn’t a clear policy currently.

It doesn’t make sense the Community Ops manages this, even if they have historically managed it. It’s simply not an operations tool. It definitely fits under the MCWS umbrella, though.

I’m wondering if it would make sense to split responsibilities of it like this:

Community ServiceDesk

  • User Management
  • Organisational Management
  • Account Configuration
  • General administration of the account
  • Creating admin users (including for the Community Ops team)
  • Tier 1 incident response

Community Ops

  • Creating domains
  • DNS records
  • SPF records, DKIM etc
  • Tier 2 incident response

MCWS Review Process
(this is ambiguous, I guess right now it’s new domains and misc: ReMo, new user accounts: community manager. the specifics of what this means is liable to change)

  • Reviewing user accounts
  • Deciding which accounts to keep
  • Choosing domains
  • Essentially tells ServiceDesk what to do (within scope), who tells Community Ops what to do

The Community Servicedesk guys have experience with handling tickets/workflow from the Community Hardware project. They’d be happy to take over general Google Apps and would give them scope to grow.

1 Like
#6
#7

r+

I agree lets move this over to ServiceDesk

#8

I also agree with this plan. We need to have a lead for these tasks in Service Desk to make sure the agents are fulfilling the tickets correctly. This should be Stefan.

#9

@comzeradd @pierros Any feedback here?

#10

It seems like a good plan. Indeed it doesn’t make much sense for Community Ops to handle more of these requests.

But we should be clear in process. Both programmatically and technically.

  • What’s the process of getting a request approved? Some requests (like a mailbox for a community member) never had a clear path for getting it approved. Reps used to have an IT SIG, for approving these kind of requests, but I think it’s no longer active.
  • What will be the process in terms of tools? Are we going to use bugzilla as a Service Desk? Do all of these requests fall under one specific Bugzilla product/component?
#11

Yes, the process is a little ad hoc right now. This is part of the process
of fixing the process. There have been no objections on governance to the
MCWS module, so at least clearly Tom and I get to make decisions. We don’t
want to hold anyone up while we’re implementing a new process so it will be
ad hoc for a little bit longer, but everything is going to be revamped.

As for a tool, we are leaning towards using JIRA Service Desk. We’d love to
see similar functionality available with Bugzilla, but Service Desk does
what we want out of the box and we have no bandwidth for development.

#12

I know you are a process type of person, so I don’t worry about you and Ton figuring out the process :slight_smile:

Ideally I would prefer we don’t force contributors to create yet another account on another platform just to request a resource, but if Bugizlla is not sufficient I understand. But we should always strive for using Open Source tools at least.

#13

I completely understand both of the concerns surrounding JIRA.

Bugzilla simply isn’t a sufficient tool for us here, and the best tool is
JIRA. I think unfortunately, making this request process slick and
efficient will be more beneficial from a big picture standpoint that just
using the open source system. That said, if something open source that
meets our needs comes along, we should totally research that. I’m
completely unaware of anything like that just yet though. It’s a useful
thing to raise though, so thank you.

I think, since there are no objections to the actual team organisation,
we’re going to go ahead with building this structure into the real world.