How can volunteers become trusted in the community?

[David Boswell]

As part of the Stewards program, I'm talking with people from all across the organization about how to bring volunteers into their projects. I've started running into some governance related issues and I wanted to bring those up for discussion.

A good topic to start with is the question of how trust is established in the project because several groups have mentioned trust as a barrier for working with volunteers (such as IT, Finance, People, Bizdev).

Does each group need to figure out by themselves how to provide a trust-building framework? Could we build on what the Security group has done to establish trust with their volunteers or is that process just too specific to their needs?

For reference, I found information around how to establish trust for the Security Group in the 'Organizational structure for handling security bugs' section of the following page but there may be more information somewhere else that I don't know about.

https://www.mozilla.org/projects/security/security-bugs-policy.html

I think this could have benefits for both employees (who wouldn't have to create these frameworks from scratch) and for volunteers (who would have a clearly understood path to establishing trust).

I asked Gerv about this last week and he wrote a blog post with some of his thoughts.

http://blog.gerv.net/2012/01/establishing-trust-online/

If anyone else has additional thoughts or suggestions, please feel free to share.

Thanks,
David

[Justin Wood (Callek)]

I find it hard for me to look at this objectively, since I have been
part of the project for over 8 years now (I think its closer to 9-10).
And have received trust already in various forms. But let me try anyway.

I feel that, as a basic we need a *few* different conventions for trust,
and to try and morph existing conventions/process to suit new needs, if
possible -- rather than having hundreds of divergent processes.

That said, I also do think we need to let each project, likely in
conjunction with some overarching trust caring group, to establish the
"right" process for them.

This boils down to the trust levels for a "Comitter Agreement" being
different than the trust levels for "IT volunteers", different than
trust levels for "Security Group", different than Trust Levels for
(e.g.) SeaMonkey giving someone access to manage the SeaMonkey Releng
infra etc.

Those all have many different trust needs, and likely many different
processes that would make sense.

For me I think the largest entry point is "known", where how that person
is known can vary greatly from reason to reason. Such as an employee
would become known on day 1, but we wouldn't necessarily grant checkin
rights, or root access to our primary DB servers, etc. on day 1. It
would evolve in giving the *employee* (or volunteer) as little access as
possible, for them to do what *we* want them to do.

As the trust relationship forms, from us trusting they won't "screw
something major up" as well as whatever barriers we have in place for
legal-leakage (say a committer agreement preventing them from commiting
exploit code onto our build network, or an IT legal agreement preventing
them from disclosing infrasec issues, etc.)

I myself have been around a long time, and helped out in both verbal
communication and physical work to earn my trust, but 8 years is a long
time to ask a volunteer to devote just to get "trusted" agreed.

Conclusion: very fluid requirements make sense for each area we would
expect to trust a user/person. But we should endeavor to make those
requirements as sane and relatably shared as possible.

--
~Justin Wood (Callek)

[Jay Garcia]

On 01.02.2012 22:19, David Boswell wrote:

Peer review and subsequent recommendations following is a strong asset
to most any arena where volunteers abound.

I resemeble that remark don't I? :-)

--
Jay Garcia - www.ufaq.org - Netscape - Firefox - SeaMonkey - Thunderbird
Mozilla Contribute Coordinator Team - www.mozilla.org/contribute/
Mozilla Mozillian Member - www.mozillians.org
Mozilla Contributor Member - www.mozilla.org/credits/

[Benjamin Smedberg]

On 2/1/2012 11:19 PM, David Boswell wrote:
> A good topic to start with is the question of how trust is established in the project because several groups have mentioned trust as a barrier for working with volunteers (such as IT, Finance, People, Bizdev).
>
> Does each group need to figure out by themselves how to provide a trust-building framework? Could we build on what the Security group has done to establish trust with their volunteers or is that process just too specific to their needs?

I'm wary of making this solution too generic. In each of these cases, we
are trusting people with something specific:

* access to the try server
* access to commit to mozilla-central
* access to all our security bugs
* access to critical Mozilla infrastructure (IT)
* access to details of Mozilla's financials (finance)
* access to partnership details which are not yet public (bizdev)
* access to private information about employees? (people)

There are certainly some common patterns between some of the existing
patterns: the vouching/seconding mechanism seems to have evolved
naturally and successfully. However, the devil is in the details. Can we
spell out exactly how are we trusting a person? For example, in the
security group there seems to be an implicit trust that a member will
not make a security group public without consensus, but as far as I know
that was not explicitly stated. When we grant commit access to try,
we're basically trusting somebody not to try to hack our build farm. For
some of these other activities, the elements of trust may be much more
specific: not revealing financial details to anyone without prior
permission, for example. Or proactively notifying people if your
infrastructure passwords have been compromised. I expect that in some of
the examples above, there are legal requirements which we would have to
satisfy as well.

--BDS

[Justin Dolske]

On 2/1/12 8:19 PM, David Boswell wrote:

> A good topic to start with is the question of how trust is
> established in the project because several groups have mentioned
> trust as a barrier for working with volunteers (such as IT, Finance,
> People, Bizdev).

I don't like the term "trust".

It's seems like a bad starting point, because it's so squishy to define,
and is pretty loaded when used as a negative ("We don't trust you.")

This sorta came up when we were refining the Commit Access policy a year
or two ago. Someone (Connor?) pointed out that in that context "trust"
actually had very little relevance -- getting commit access was more
about knowing the rules and being able to follow them.

Perhaps "demonstrated responsibility" is a better starting point? Part
of this is obviously tied up in what "responsibility" means in a given
context (standards should differ between, say, moderator access on a
forum and security bugs access). But in general is seems like whatever
naming is used, we should base it in more concrete measures. For
example: What is the risk (and benefit) to Mozilla? What is the cost to
a volunteer for being irresponsible? How to balance the two?

Justin

[Aakash Desai]

Justin,

You're right; I do believe we need to curtail how we permit folks in
various tools and communities toward gaining responsibility. Ultimately,
we're all here to work towards bettering the mission as the highest
priority and becoming friends and family aren't the ultimate purpose. How
does the saying go?

I think: "I don't like you, but I can respect you."

Respect for responsibility, commitment and work accomplished is a guiding
set of attributes to base metrics on and, finally, decide who to give more
responsibility to in the community via various tools and platforms.

I'd like to take a crack at grabbing all the various ways we allow for
greater permissions in our community. What do folks think?

-- Aakash

On Fri, Feb 3, 2012 at 12:11 AM, Justin Dolske <dol...@mozilla.com> wrote:

> On 2/1/12 8:19 PM, David Boswell wrote:
>

> A good topic to start with is the question of how trust is
>> established in the project because several groups have mentioned
>> trust as a barrier for working with volunteers (such as IT, Finance,
>> People, Bizdev).
>>
>

> I don't like the term "trust".
>
> It's seems like a bad starting point, because it's so squishy to define,
> and is pretty loaded when used as a negative ("We don't trust you.")
>
> This sorta came up when we were refining the Commit Access policy a year
> or two ago. Someone (Connor?) pointed out that in that context "trust"
> actually had very little relevance -- getting commit access was more about
> knowing the rules and being able to follow them.
>
> Perhaps "demonstrated responsibility" is a better starting point? Part of
> this is obviously tied up in what "responsibility" means in a given context
> (standards should differ between, say, moderator access on a forum and
> security bugs access). But in general is seems like whatever naming is
> used, we should base it in more concrete measures. For example: What is the
> risk (and benefit) to Mozilla? What is the cost to a volunteer for being
> irresponsible? How to balance the two?
>
> Justin

> ______________________________**_________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/governance<https://lists.mozilla.org/listinfo/governance>
>

[Gervase Markham]

On 02/02/12 04:19, David Boswell wrote:
> A good topic to start with is the question of how trust is
> established in the project because several groups have mentioned
> trust as a barrier for working with volunteers (such as IT, Finance,
> People, Bizdev).

It would be helpful if you could expand that list of examples into a
full list of groups who have mentioned this. Because I think the
solution might be different in each case.

In the case of People, for example, it is likely that there are legal
issues with giving people who don't have a legal relationship with
Mozilla access to personnel information. So they might have to go the IT
route and have a contract.

In the case of Bizdev, there may be no legal (as in, governmental legal)
issues, but perhaps other companies might be quite wary of talking to
Mozilla volunteers without an NDA, and the other company doesn't want to
have to execute a separate NDA with every volunteer (which is fair enough).

In the case of finance, I guess we can tell whoever we like our
financial information (unless we have signed a contract saying we won't
discuss particular deals or amounts - which I suspect may be the case
for some deals) but the risk is to Mozilla. We already publish our form
990, and are happy to do so, but there is danger both from a PR and a
business leverage perspective (which is a danger to the mission) if e.g.
our full books turned up on Bittorrent.

> Does each group need to figure out by themselves how to provide a
> trust-building framework? Could we build on what the Security group
> has done to establish trust with their volunteers or is that process
> just too specific to their needs?

It's not _that_ common that a 'pure' volunteer gets added to the
security group - most additions are new people at MoCo who do
security-related work, or contacts at other companies who we partner with.

Exceptions I can remember include:

* The previous Debian Firefox maintainer nominated the new one (so I
guess that's an A in my scheme)
http://blog.gerv.net/2012/01/establishing-trust-online/

* I _think_ the same thing happened when the person responsible for
SeaMonkey RelEng changed

It would be interesting to ask dveditz when the last time he can
remember was that someone entered the security group who was not
employed by Mozilla or a partner, and did not enter via a "succession"
mechanism.

Gerv

[Gervase Markham]

On 03/02/12 16:06, Aakash Desai wrote:
> You're right; I do believe we need to curtail how we permit folks in
> various tools and communities toward gaining responsibility.

Are you sure you mean that? "Curtail" means "restrict or stop".

> Ultimately,
> we're all here to work towards bettering the mission as the highest
> priority and becoming friends and family aren't the ultimate purpose.

Perhaps your view is more nuanced than that sentence, but as it stands,
I think this is overly-utilitarian, and takes too little account of
people's emotional needs - particularly when they are doing voluntary
work, and can walk away at any time.

People at Mozilla are bound together by a shared belief in the mission,
sure - but also by being friends with people who share that belief, and
because Mozilla is a fun place to contribute and to be. If you want to
build a community around a project (be it Mozilla as a whole or some
smaller component), they need to be just that - a community.

> I'd like to take a crack at grabbing all the various ways we allow for
> greater permissions in our community. What do folks think?

That sounds like an excellent idea :-)

Gerv

[davidwboswell]

Thanks for the feedback on this thread. I have a few thoughts based
on these comments:

* It seems like there will probably be enough differences among teams
where we can't generalize the process of establishing trust too much,
although there may be some parts that apply broadly (such as vouching/
seconding as a mechanism).

* 'Trust' might not be the best word to use here. I don't think
'responsibility' is the right alternative though. In the commit
access example it's certainly important that people know the rules,
but people are getting access to something that's already public.
There's something else going on when people are dealing with
information that is somehow confidential.

* I like Gerv's point about being more clear with examples. I'll add
one more. The Communications Reps program is a way for the
Communications team to work with volunteers who can be given access to
certain information before it's made public because they are known and
have gone through PR training.

* Considering these points, maybe a better question for this thread is
'How can volunteers get access to confidential information?'

* Even if there's not a single process or policy that fits for
everyone, I think it could help other teams if they had access to
examples of how other people have solved similar problems. For
instance, the Security Bugs Policy is not easy to find. Maybe the
solution here is to make this example from the Security team more
widely known?

David

[Gervase Markham]

On 06/02/12 22:00, davidwboswell wrote:
> * I like Gerv's point about being more clear with examples. I'll add
> one more. The Communications Reps program is a way for the
> Communications team to work with volunteers who can be given access to
> certain information before it's made public because they are known and
> have gone through PR training.

That's a great example. Now the PR team might disagree :-) but, bearing
in mind that our previous practice was to prepare announcements in
public, I think that this is a good example of somewhere we could employ
"default trust" from a very early stage, with a lot of the relevant
data. After all, if someone leaks the Firefox 12 press blog
announcement, it's not an enormous deal (although perhaps the PR team
would find it irritating!) - and we could then "fire" that person.

Once they had proved trustworthy with that sort of thing, we could move
up to them handling embargoed information involving third parties, and
so on.

> * Even if there's not a single process or policy that fits for
> everyone, I think it could help other teams if they had access to
> examples of how other people have solved similar problems. For
> instance, the Security Bugs Policy is not easy to find. Maybe the
> solution here is to make this example from the Security team more
> widely known?

No objection there.

Gerv

[davidwboswell]

> > * Even if there's not a single process or policy that fits for
> > everyone, I think it could help other teams if they had access to
> > examples of how other people have solved similar problems.  For
> > instance, the Security Bugs Policy is not easy to find.  Maybe the
> > solution here is to make this example from the Security team more
> > widely known?
>
> No objection there.

OK, it seems like case studies instead of creating policies is the
solution here. The Security team and Communications team both have
good examples for establishing trust that other teams can learn from
if they're aware of what's been done.

I have the feeling that better promoting what's worked for other teams
will also be needed for several other community building issues. This
is a good segue to another topic I wanted to discuss here, so let me
start a new thread for that...

David

[Aakash Desai]

Hey All,

So, I took the lead and ran a survey on how different groups offer
privileges around the community. Here's the results of the major tools
I was able to find:

https://mozillians.etherpad.mozilla.org/authorizationmethods

>From there, I applied the things we're building out with Community
Tools in 2012 and started looking at bettering the vouching and
authorization levels on Mozillians.org. Below is the Feature wiki for
it; remember that this is a work in progress as a proposal, so be
kind ;).

https://wiki.mozilla.org/Mozillians/Phonebook/Vouching

In terms of feedback, I'd please ask folks to focus on whether there's
anything that doesn't seem appropriate for the desired level and if
there are certain privileges that should be added/edited/removed from
the wiki. Please stray away from talking about whether or not this is
implementable; we can save that for a future discussion.

Regards,
Aakash

> > governa...@lists.mozilla.org
> >https://lists.mozilla.org/**listinfo/governance<https://lists.mozilla.org/listinfo/governance>

[Axel Hecht]

On 05.03.12 22:45, Aakash Desai wrote:
> Hey All,
>
> So, I took the lead and ran a survey on how different groups offer
> privileges around the community. Here's the results of the major tools
> I was able to find:
>
> https://mozillians.etherpad.mozilla.org/authorizationmethods
>
>> From there, I applied the things we're building out with Community
> Tools in 2012 and started looking at bettering the vouching and
> authorization levels on Mozillians.org. Below is the Feature wiki for
> it; remember that this is a work in progress as a proposal, so be
> kind ;).
>
> https://wiki.mozilla.org/Mozillians/Phonebook/Vouching
>
> In terms of feedback, I'd please ask folks to focus on whether there's
> anything that doesn't seem appropriate for the desired level and if
> there are certain privileges that should be added/edited/removed from
> the wiki. Please stray away from talking about whether or not this is
> implementable; we can save that for a future discussion.
>
> Regards,
> Aakash

I'd have one detail comment and one general one.

In practice, I think there's room between active and core. That'd be in
detail.

In general, I can see a gap between the passion and emotional connection
contributor-mozilla, and the technical abilities to put those into action.

Thus, are you proposing we put the two into one bucket, and if so, what
do we gain from that?

Axel

[Josh Matthews]

On 12-03-05 4:45 PM, Aakash Desai wrote:
> Hey All,
>
> So, I took the lead and ran a survey on how different groups offer
> privileges around the community. Here's the results of the major tools
> I was able to find:
>
> https://mozillians.etherpad.mozilla.org/authorizationmethods
>
>> From there, I applied the things we're building out with Community
> Tools in 2012 and started looking at bettering the vouching and
> authorization levels on Mozillians.org. Below is the Feature wiki for
> it; remember that this is a work in progress as a proposal, so be
> kind ;).
>
> https://wiki.mozilla.org/Mozillians/Phonebook/Vouching
>
> In terms of feedback, I'd please ask folks to focus on whether there's
> anything that doesn't seem appropriate for the desired level and if
> there are certain privileges that should be added/edited/removed from
> the wiki. Please stray away from talking about whether or not this is
> implementable; we can save that for a future discussion.
>
> Regards,
> Aakash

I am one of the people blessing new contribuors with canconfirm and
editbugs privileges these days, and gerv pointed out to me when granting
me those abilities that canconfirm and editbugs are frequently bestowed
at the same time. Given that reality, it doesn't really make sense to me
to separate editbugs from canconfirm in that list.

[Byron Jones]

Josh Matthews wrote:
> I am one of the people blessing new contribuors with canconfirm and
> editbugs privileges these days, and gerv pointed out to me when
> granting me those abilities that canconfirm and editbugs are
> frequently bestowed at the same time. Given that reality, it doesn't
> really make sense to me to separate editbugs from canconfirm in that
> list.

i agree; editbugs belongs in "active" not "core".

i see a lot of items there for non-technical things people have done in
the community, but i don't see any attributes relating to technical
things people have done -- for example "active" should contain "fixed a
bug by attaching a patch or by some other means".



--
byron - irc:glob - bugzilla.mozilla.org team -

[deimidis]

El 07/02/12 08:29, Gervase Markham escribió:

> On 06/02/12 22:00, davidwboswell wrote:
>> * I like Gerv's point about being more clear with examples. I'll add
>> one more. The Communications Reps program is a way for the
>> Communications team to work with volunteers who can be given access to
>> certain information before it's made public because they are known and
>> have gone through PR training.
>
> That's a great example. Now the PR team might disagree :-) but, bearing
> in mind that our previous practice was to prepare announcements in
> public, I think that this is a good example of somewhere we could employ
> "default trust" from a very early stage, with a lot of the relevant
> data. After all, if someone leaks the Firefox 12 press blog
> announcement, it's not an enormous deal (although perhaps the PR team
> would find it irritating!) - and we could then "fire" that person.
>
> Once they had proved trustworthy with that sort of thing, we could move
> up to them handling embargoed information involving third parties, and
> so on.
>

Using this Communication example, I think that educational courses could
help to build this trust/responsability/confidence. If each group has a
way to educate new volunteers in their practice, through this
educational procees, volunteer could obtain this trust.

I participate in two different Mozilla PR training program, and is a
good way to see how the volunteer work and explain. So, basically,
Communication could see how he/she works.

[Gervase Markham]

On 06/03/12 05:02, Byron Jones wrote:
> i agree; editbugs belongs in "active" not "core".

Yes, I concur.

> i see a lot of items there for non-technical things people have done in
> the community, but i don't see any attributes relating to technical
> things people have done -- for example "active" should contain "fixed a
> bug by attaching a patch or by some other means".

I think that's subsumed under the general "done a task"...

Gerv

[Aakash Desai]

Glob: The act of performing tasks in each of the levels is supposed to be a
placeholder for things like fulfilling technical tasks such as attaching a
patch on a mentored bug all the way to non-technical items such as
completing icon work for one of our projects.


Josh: Is there a way we can augment that approach going forward to
accommodate the separation of permission levels between active/core
contributors?

On Mon, Mar 5, 2012 at 7:41 PM, Josh Matthews <jo...@joshmatthews.net> wrote:

> On 12-03-05 4:45 PM, Aakash Desai wrote:
>

>> Hey All,
>>
>> So, I took the lead and ran a survey on how different groups offer
>> privileges around the community. Here's the results of the major tools
>> I was able to find:
>>

>> https://mozillians.etherpad.**mozilla.org/**authorizationmethods<https://mozillians.etherpad.mozilla.org/authorizationmethods>

>>
>> From there, I applied the things we're building out with Community
>>>
>> Tools in 2012 and started looking at bettering the vouching and
>> authorization levels on Mozillians.org. Below is the Feature wiki for
>> it; remember that this is a work in progress as a proposal, so be
>> kind ;).
>>

>> https://wiki.mozilla.org/**Mozillians/Phonebook/Vouching<https://wiki.mozilla.org/Mozillians/Phonebook/Vouching>

>>
>> In terms of feedback, I'd please ask folks to focus on whether there's
>> anything that doesn't seem appropriate for the desired level and if
>> there are certain privileges that should be added/edited/removed from
>> the wiki. Please stray away from talking about whether or not this is
>> implementable; we can save that for a future discussion.
>>
>> Regards,
>> Aakash
>>
>

> I am one of the people blessing new contribuors with canconfirm and
> editbugs privileges these days, and gerv pointed out to me when granting me
> those abilities that canconfirm and editbugs are frequently bestowed at the
> same time. Given that reality, it doesn't really make sense to me to
> separate editbugs from canconfirm in that list.
>
>

[Gervase Markham]

On 05/03/12 21:45, Aakash Desai wrote:
> So, I took the lead and ran a survey on how different groups offer
> privileges around the community. Here's the results of the major tools
> I was able to find:
>
> https://mozillians.etherpad.mozilla.org/authorizationmethods

Hi Aakash,

Reading this list, it looks like it's a survey of what privileges are
available and who grants them, but not really what _basis_ they grant
them on. E.g. it doesn't explain how I decide whether or not to give
someone editbugs, or how a module owner decides whether or not to give
someone level 2 access.

Would that be right?

If so, I can see that this is useful for your determination of levels
for Mozillians (and that's fine :-), but it's not enough information to
help us with the question which is the topic of the thread - _how_ can
volunteers become trusted in the community.

> In terms of feedback, I'd please ask folks to focus on whether there's
> anything that doesn't seem appropriate for the desired level and if
> there are certain privileges that should be added/edited/removed from
> the wiki. Please stray away from talking about whether or not this is
> implementable; we can save that for a future discussion.

Comments elsewhere in the thread.

Gerv