Giving Access

Community Ops
#1

@tanner has raised a really important discussion. How do we give access to people?

Right now, we give access based on trust alone. There is no structure.

Sadly, to grow, that can’t be the case. We have to make a formal procedure on how access is given, and stick with it.

It’s my opinion that trust should be at the basis of any procedure we do employ. Although we could consider legally binding methods to satisfy the need, we should still be based on trust. That is at the heart of mozilla and our community.

I think that we should use modules as the “power” to grant access. A module owner, or a peer majority vote should make a decision on whether to provide access to a server owned by that module. This decision should be documented.

@tanner mentioned 2 things: a form of “code of conduct” and a non disclosure agreement. Both are possible things we could use, but I wouldn’t appreciate us using either in a way that they block contribution. For certain access, such as access to databases, logs, a code of conduct (or NDA, legal can help) would be a very good way to strengthen trust in a contributor.

What I wouldn’t like to happen is for either of those things to be something all contributors need to complete. Only those with certain access which contains user information, sensitive corporate info (why we would have that is beyond me) or anything which could compromise a user’s identity. For access to encrypted system passwords, I’m not sure I would be too concerned. We are an IT team, we can reset our passwords if needed, and should all be fairly competent in basic security.

Thoughts of any kind?

#2

We don’t have a process sorted out and I never had a process sorted out while I was at Mozilla.

There’s a trust aspect to granting someone privileged access that’s not unlike granting commit access. I had explored using the contributor agreement along with some sort of “code of conduct” but made little progress on that.

I also like the idea of using something like trueability.com to assess.

If I rewind to 2011 or so, I had envisioned new contributors coming in through the NOC where they could vet their skills by responding to pages and triaging Bugzilla.

Anyways, I don’t have a good answer yet.

#3

For access, I would take a look at what the Security team does for new contributors. It seems like they are dealing with similar sorts of issues where people need a way to establish trust before being able to contribute fully for security projects.

https://wiki.mozilla.org/Security/

I would also encourage you to think of opportunities that anyone can help with as a starting point for people who are interested in getting involved. You can then give someone a pathway for how to build trust so that they can get to a point where a team member is comfortable granting them access.

To mrz’s point, if the process is similar to granting commit access, there is a pathway that new coders can follow and there are initial contribution opportunities people can take without having any special access. For reference, the coding contribution pathway is at

https://wiki.mozilla.org/Contribute/Conversion_points#Coding

Thanks,
David

1 Like
#4

All of the pathways I’d suggested require some systems in place. The latter’s been the blocking factor.

Possible pathways:

  • Monitoring

  • stand up Nagios monitoring, integrate with PagerDuty

  • provides an entry for contributors to handle PagerDuty

  • provides an entry to resolve some problems

  • Puppet Config Management

  • provides entry to build new servers/services

  • provides entry to take code contributions (puppet manifests)

  • Wordpress Multisite Administration

  • provides entry for contributors to manage WP sites, work with other

  • Mozilla Communities to setup new sites

  • Software/Application Development Platform

  • Docker / OpenShift / CloudFoundry

  • this is interesting because it drops the barriers for others to deploy applications and turns Community IT/Ops into a Service Provider.

1 Like
#5

These pathways sound really good, and a nice way for us to build trust in new contributors.

Wordpress Administration is similar to where I started - maintaining Plesk and slightly later on, Google Apps.
Puppet Config is where Scott has started, and it’s how I’ve built a certain level of trust in him, where I can feel comfortable giving him little bits of extra access in chunks.

Are these final? Have they been discussed as a group yet (I don’t remember that they have). We should document them somewhere,

This seems similar to how Security do things too, and Coding.

#6

Would you still be interested in using an agreement like this? I can’t decide if I think we really need one, there’s reasons for and against using one.

#7

It’s probably obvious by now that I personally would like to have one. Not necessarily for contributing at all, but for having access to servers - it’s one thing how we started, we’ve all been around for years, but when somebody is just getting started within Mozilla, it’s hard to determine if they’re actually a trustworthy person, or if they just appear that way on the outside. By the time I started getting access to servers, I’d already met several Mozilla IT employees (albeit briefly), but it seems like even a little thing like that builds trust. Same goes for @yousef, I think he’d been to several Mozilla events before he even started with Community IT.

I might be being cynical, but I’m somewhat reluctant to trust people with access, much less root, on our servers without having some sort of agreement. I have absolutely no opposition to signing on myself.

#8

I can’t find the bug I had in Bugzilla on this. @gerv probably remembers this work and probably has access to whatever draft we ended up with. I’d have to re-read it before I know if it still makes sense.

#9

I wouldn’t say final. But probably very close to it. I scrapped those from an email I sent to you ages ago that ended up in our meeting notes in early June. I don’t think my thinking on this has changed much.

The blocker has been around building the systems to support all of this.

Do you want to take the action to put those into the wiki format and then offer it up for discussion?

#10

Sure.

I’ll do that now. Also, I’ll try and pick up some feedback on this from other community builders on Wednesday.

#11

@mrz https://wiki.mozilla.org/IT/Community/Pathways

Could you (and anybody else!) make any changes you thing should be made, preferably before Wednesday?

#12

Does these provide easy avenues for people to start contributing/volunteering?

Here’s some feedback from last November:

You lose people by them not being able to get involved… and 2 weeks since mentioning the barriers to entry being a problem, there still appears to be the same barriers.

Will this decrease those barriers?

#13

We need to add contact information for each pathway, and some clear instructions on how somebody gets involved.

I think that otherwise, they are good things for people to start with. The list can expand over time too. As we develop, we’re likely to build more projects for people to get involved on, and have better infrastructure opening extra opportunities.

This also brings up a discussion about the module system. We should talk about exactly how the module system works, and how we can integrate it into mentorship. Note that mentorship isn’t all about technical ability, but also just introducing people to us as a project. Maybe we can talk about that in our next meeting (whenever that’s going to be?)