New modules proposal: Mozilla Reps

[Gervase Markham]

The Mozilla Reps program is not covered by the module owner system; we'd
like to propose some new Activities Modules to cover it. The proposed
module descriptions are here:

https://wiki.mozilla.org/Modules/Mozilla_Reps

We've done something a bit unusual, in that there is not a named module
owner for the Mozilla Reps Council. The chair of the council is a
rotating position among the members, both employee and volunteer. So we
decided to propose specifying the module owner as "the current chair of
the council". We would want to specify a way of finding out who it was.
By similar logic, the peers are "all the other council members".

Please do comment.

Gerv

[Axel Hecht]

In which situations would I talk to reps module owner/peers and in which
to the reps council?

Also, in which situations would I talk to the mentors owner/peers and in
which to the council?

Right now, there's a good deal of overlap in individuals, so the
questions are mutually exclusive, but as we codify them, I wonder if we
can get this more crisp.

Axel

[William Quiviger]

On Feb 19, 2013, at 12:44 PM, Axel Hecht <l1...@mozilla.com> wrote:

> On 19.02.13 11:45, Gervase Markham wrote:

> In which situations would I talk to reps module owner/peers and in which to the reps council?

The Reps module owner/peers oversee the general health of the program and makes sure that the Council is doing its job. If you have a very general question or concern about the program as a whole and how it fits within the Mozilla project, you would contact the Reps module owner/peers.

The Reps Council module owner/peers oversee the day to day of the program, manage Mozilla Reps Mentors, represents Mozilla Reps and serves as an advisory body within the Mozilla organization. The module owner/peers change regularly with the Mozilla Reps 6-month election cycle. If you have a specific question related to the program's governance structure, finances, day-to-day management, then you would ask the Reps Council module owner/peers.

>
> Also, in which situations would I talk to the mentors owner/peers and in which to the council?

The Reps Mentors module owner/peers look after the Mozilla Reps program's mentorship base. Mentors on-board new applicants, look after and mentor Reps, monitor their activities and help them grow in the program.

If you have a question related to what Mozilla Reps do and how they are supported (eg. resources, tools, materials etc..), you should ask the Reps Mentor module owner/peers.

>
> Right now, there's a good deal of overlap in individuals, so the questions are mutually exclusive, but as we codify them, I wonder if we can get this more crisp.

I agree. Thanks for the feedback. I'll work with the Council and Gerv to make the text a bit crisper.

William

---
William Quiviger
Mozilla Reps Council Chair
https://reps.mozilla.org/u/wquiviger/

[Lukas Blakk]

If the chair of the council is a rotating position, I am a bit concerned about module ownership churn. Most of our module owners seem to get the position and then stay attached to their module(s) for a fairly long time. Of course we are welcome to experiment, and Mozilla Reps is a pretty unique program, but reading Gerv's statement makes me have a bit of a knee-jerk reaction, wanting more continuity than "the current chair" if that position rotates often and I'm not sure what that would look like. Perhaps the current and most recent former chair so that there's some coverage from the past at the same time?

-Lukas

On Feb 19, 2013, at 4:46 AM, William Quiviger <wqui...@mozilla.com> wrote:

>
> On Feb 19, 2013, at 12:44 PM, Axel Hecht <l1...@mozilla.com> wrote:
>
>> On 19.02.13 11:45, Gervase Markham wrote:

>> In which situations would I talk to reps module owner/peers and in which to the reps council?
>
> The Reps module owner/peers oversee the general health of the program and makes sure that the Council is doing its job. If you have a very general question or concern about the program as a whole and how it fits within the Mozilla project, you would contact the Reps module owner/peers.
>
> The Reps Council module owner/peers oversee the day to day of the program, manage Mozilla Reps Mentors, represents Mozilla Reps and serves as an advisory body within the Mozilla organization. The module owner/peers change regularly with the Mozilla Reps 6-month election cycle. If you have a specific question related to the program's governance structure, finances, day-to-day management, then you would ask the Reps Council module owner/peers.
>
>>
>> Also, in which situations would I talk to the mentors owner/peers and in which to the council?
>
> The Reps Mentors module owner/peers look after the Mozilla Reps program's mentorship base. Mentors on-board new applicants, look after and mentor Reps, monitor their activities and help them grow in the program.
>
> If you have a question related to what Mozilla Reps do and how they are supported (eg. resources, tools, materials etc..), you should ask the Reps Mentor module owner/peers.
>
>>
>> Right now, there's a good deal of overlap in individuals, so the questions are mutually exclusive, but as we codify them, I wonder if we can get this more crisp.
>
> I agree. Thanks for the feedback. I'll work with the Council and Gerv to make the text a bit crisper.
>
> William
>
> ---
> William Quiviger
> Mozilla Reps Council Chair
> https://reps.mozilla.org/u/wquiviger/
>

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance

[Axel Hecht]

On 20.02.13 06:59, Lukas Blakk wrote:
> If the chair of the council is a rotating position, I am a bit concerned about module ownership churn. Most of our module owners seem to get the position and then stay attached to their module(s) for a fairly long time. Of course we are welcome to experiment, and Mozilla Reps is a pretty unique program, but reading Gerv's statement makes me have a bit of a knee-jerk reaction, wanting more continuity than "the current chair" if that position rotates often and I'm not sure what that would look like. Perhaps the current and most recent former chair so that there's some coverage from the past at the same time?

I had a similar reaction when the reps program proposed the current mode
of operations for the council. But I consider that to be a purposeful
decision on behalf of the reps program itself.

I'm wondering if the council needs to be reflected as a module at all.
Maybe the following is a closer description of reality?

Make the council as a group a peer of the reps module. As-a-group would
mean that as it's elected and makes decisions. The individual members of
the council wouldn't have a role in the module ownership per se, aside
of overlap in individuals.

Axel

[Pierros Papadeas]

Hey Axel,

On Wed, Feb 20, 2013 at 1:07 PM, Axel Hecht <l1...@mozilla.com> wrote:
> On 20.02.13 06:59, Lukas Blakk wrote:
>>

>> If the chair of the council is a rotating position, I am a bit concerned
>> about module ownership churn. Most of our module owners seem to get the
>> position and then stay attached to their module(s) for a fairly long time.
>> Of course we are welcome to experiment, and Mozilla Reps is a pretty unique
>> program, but reading Gerv's statement makes me have a bit of a knee-jerk
>> reaction, wanting more continuity than "the current chair" if that position
>> rotates often and I'm not sure what that would look like. Perhaps the
>> current and most recent former chair so that there's some coverage from the
>> past at the same time?
>

> I had a similar reaction when the reps program proposed the current mode of
> operations for the council. But I consider that to be a purposeful decision
> on behalf of the reps program itself.
>
> I'm wondering if the council needs to be reflected as a module at all. Maybe
> the following is a closer description of reality?
>
> Make the council as a group a peer of the reps module. As-a-group would mean
> that as it's elected and makes decisions. The individual members of the
> council wouldn't have a role in the module ownership per se, aside of
> overlap in individuals.

This combination of responsibilities, overcomplicates the roles of the
two distinctive groups that William described (reps module and reps
council module) They have different scope and the module owner
rotation (For the council module) reflects the dynamics of the
program. That's why I think that they would be better as separate
modules.

~pierros

>
> Axel

--
Pierros Papadeas
Community Architect
pierros @ irc.mozilla.org

[Gervase Markham]

On 20/02/13 05:59, Lukas Blakk wrote:
> If the chair of the council is a rotating position, I am a bit
> concerned about module ownership churn. Most of our module owners
> seem to get the position and then stay attached to their module(s)
> for a fairly long time.

Do you think there is a valid distinction here between code and non-code
modules? Clearly there's advantage to a code module owner being in place
for a long time. Is that equally true of all non-code modules?

In this case, it's effectively that a different peer becomes owner in
each period, then goes back to being a peer.

> than "the current chair" if that position rotates often and I'm not
> sure what that would look like. Perhaps the current and most recent
> former chair so that there's some coverage from the past at the same
> time?

Can someone remind us of the frequency with which the chairmanship rotates?

Gerv

[Lukas Blakk]

We seem to have fallen off the list with this discussion.
Chairmanship will rotate every 2 months and during that 2 months the person needs to be listed in the Wiki as a module owner?

I'm definitely concerned then that this will results in potentially stale documentation and a tremendous lack of historical perspective for the Mozilla Reps module itself. The Module system seems to exist largely to give each module a sense of historical perspective: the hows and whys of a module over time. Sure, there are other reasons too but the history of decisions around a module's path forward seems to me the largest loss if ownership changes hands every 2 months.

-Lukas


On Feb 20, 2013, at 6:45 AM, William Quiviger <wqui...@mozilla.com> wrote:

>
> On Feb 20, 2013, at 3:40 PM, Gervase Markham <ge...@mozilla.org> wrote:
>
>> On 20/02/13 05:59, Lukas Blakk wrote:

>>> If the chair of the council is a rotating position, I am a bit
>>> concerned about module ownership churn. Most of our module owners
>>> seem to get the position and then stay attached to their module(s)
>>> for a fairly long time.
>>

>> Do you think there is a valid distinction here between code and non-code
>> modules? Clearly there's advantage to a code module owner being in place
>> for a long time. Is that equally true of all non-code modules?
>

> I would argue that it is not equally true for non-code modules.

>>
>> In this case, it's effectively that a different peer becomes owner in
>> each period, then goes back to being a peer.
>>

>>> than "the current chair" if that position rotates often and I'm not
>>> sure what that would look like. Perhaps the current and most recent
>>> former chair so that there's some coverage from the past at the same
>>> time?
>>

>> Can someone remind us of the frequency with which the chairmanship rotates?
>

> Chairmanship used to rotate on a monthly basis, but starting March 1st it will be every 2 months.
>
> - w

[William Quiviger]

On Feb 20, 2013, at 6:31 PM, Lukas Blakk <lsb...@mozilla.com> wrote:

> We seem to have fallen off the list with this discussion.
> Chairmanship will rotate every 2 months and during that 2 months the person needs to be listed in the Wiki as a module owner?

Correct.

>
> I'm definitely concerned then that this will results in potentially stale documentation and a tremendous lack of historical perspective for the Mozilla Reps module itself.

To be clear: there is the Mozilla Reps module which has a long-term module owner then there is the Mozilla Reps Council sub-module which has a different owner every 2 months. It's for this sub-module that we want to experiment with rotating ownership.

William

> The Module system seems to exist largely to give each module a sense of historical perspective: the hows and whys of a module over time. Sure, there are other reasons too but the history of decisions around a module's path forward seems to me the largest loss if ownership changes hands every 2 months.
>
> -Lukas
>
>
> On Feb 20, 2013, at 6:45 AM, William Quiviger <wqui...@mozilla.com> wrote:
>
>>
>> On Feb 20, 2013, at 3:40 PM, Gervase Markham <ge...@mozilla.org> wrote:
>>
>>> On 20/02/13 05:59, Lukas Blakk wrote:

>>>> If the chair of the council is a rotating position, I am a bit
>>>> concerned about module ownership churn. Most of our module owners
>>>> seem to get the position and then stay attached to their module(s)
>>>> for a fairly long time.
>>>

>>> Do you think there is a valid distinction here between code and non-code
>>> modules? Clearly there's advantage to a code module owner being in place
>>> for a long time. Is that equally true of all non-code modules?
>>
>> I would argue that it is not equally true for non-code modules.
>>>
>>> In this case, it's effectively that a different peer becomes owner in
>>> each period, then goes back to being a peer.
>>>

>>>> than "the current chair" if that position rotates often and I'm not
>>>> sure what that would look like. Perhaps the current and most recent
>>>> former chair so that there's some coverage from the past at the same
>>>> time?
>>>

[Lukas Blakk]

On Feb 20, 2013, at 10:18 AM, William Quiviger <wqui...@mozilla.com> wrote:
>
>>
>> I'm definitely concerned then that this will results in potentially stale documentation and a tremendous lack of historical perspective for the Mozilla Reps module itself.
>
> To be clear: there is the Mozilla Reps module which has a long-term module owner then there is the Mozilla Reps Council sub-module which has a different owner every 2 months. It's for this sub-module that we want to experiment with rotating ownership.
>

Ah! Such an important distinction :) My apologies for not being aware of that.

Cheers,
Lukas

[Alina Mierlus]

Hi,

I mostly agree with Lukas and Axel's comments. I also don't see the
"chairman" as a module owner.
And I don't see the "why?" for a REMO specific module (together with
its submodules, including Council).

Looking back at REMO's objectives, they are: building tools for
community, facilitating resources, building local participation.

If I look at the Governance Module System, there are already modules
like Participation Metrics module, Productive Communication Module and
other code modules where current/former council members and mentors
could contribute (eventually as peers).

-Alina

> We seem to have fallen off the list with this discussion.
> Chairmanship will rotate every 2 months and during that 2 months the person needs to be listed in the Wiki as a module owner?
>

> I'm definitely concerned then that this will results in potentially stale documentation and a tremendous lack of historical perspective for the Mozilla Reps module itself. The Module system seems to exist largely to give each module a sense of historical perspective: the hows and whys of a module over time. Sure, there are other reasons too but the history of decisions around a module's path forward seems to me the largest loss if ownership changes hands every 2 months.

>
> -Lukas
>
>
> On Feb 20, 2013, at 6:45 AM, William Quiviger <wqui...@mozilla.com> wrote:
>
>>
>> On Feb 20, 2013, at 3:40 PM, Gervase Markham <ge...@mozilla.org> wrote:
>>
>>> On 20/02/13 05:59, Lukas Blakk wrote:

>>>> If the chair of the council is a rotating position, I am a bit
>>>> concerned about module ownership churn. Most of our module owners
>>>> seem to get the position and then stay attached to their module(s)
>>>> for a fairly long time.
>>>

>>> Do you think there is a valid distinction here between code and non-code
>>> modules? Clearly there's advantage to a code module owner being in place
>>> for a long time. Is that equally true of all non-code modules?
>>
>> I would argue that it is not equally true for non-code modules.
>>>
>>> In this case, it's effectively that a different peer becomes owner in
>>> each period, then goes back to being a peer.
>>>

>>>> than "the current chair" if that position rotates often and I'm not
>>>> sure what that would look like. Perhaps the current and most recent
>>>> former chair so that there's some coverage from the past at the same
>>>> time?
>>>

>>> Can someone remind us of the frequency with which the chairmanship rotates?
>>
>> Chairmanship used to rotate on a monthly basis, but starting March 1st it will be every 2 months.
>>
>> - w
>

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

--
Alina Mierlus
@alina_mierlus

[Majken Connor]

Hi all,

I don't have too much experience with the module system, other than knowing
that it exists for code, where it is fairly simple to understand. I have
been excited since I first saw discussion here for extending the module
system for all projects within Mozilla as I think it's a really great
system and will help bring consistency, structure and transparency to the
other teams and projects.

ReMo isn't simply a mailing list for people to discuss the objectives Alina
has rightly listed. Take facilitating resources, for example. Part of the
role of the Reps program is to distribute resources to local communities to
support their efforts in promoting Mozilla. Not everyone can be a Rep,
there is a screening process where we look for a certain level of skill
within the Mozilla project as well as a commitment to promoting Mozilla
regularly. Our volunteers sign NDAs. There is a lot that is Reps specific
to oversee.

As the Reps program is taking off, there is also some turbulence about how
Reps volunteers are treated vs non-reps volunteers. I think having a formal
module well help define where Reps fit in the Mozilla project. I also hope
to see more modules for managing (and encouraging and recognizing) other
types of volunteers.

I agree there is overlap in the goals with the modules Alina has listed,
but these are distinctive teams within Mozilla. Is there a similar example
with coding modules overlapping?

Either way, I don't think any module operates in a bubble, success depends
on interaction. It would be great to have someone from the participation
metric module help guide Reps tools and practices in that area (if that
isn't happening already). We may see more and more module overlap as we
include more teams.

On Wed, Feb 20, 2013 at 2:28 PM, Alina Mierlus <con...@alinamierlus.com>wrote:

> Hi,
>
> I mostly agree with Lukas and Axel's comments. I also don't see the
> "chairman" as a module owner.
> And I don't see the "why?" for a REMO specific module (together with its
> submodules, including Council).
>
> Looking back at REMO's objectives, they are: building tools for
> community, facilitating resources, building local participation.
>
> If I look at the Governance Module System, there are already modules like
> Participation Metrics module, Productive Communication Module and other
> code modules where current/former council members and mentors could
> contribute (eventually as peers).
>
> -Alina
>
>
>
> We seem to have fallen off the list with this discussion.
>> Chairmanship will rotate every 2 months and during that 2 months the
>> person needs to be listed in the Wiki as a module owner?
>>
>> I'm definitely concerned then that this will results in potentially stale
>> documentation and a tremendous lack of historical perspective for the
>> Mozilla Reps module itself. The Module system seems to exist largely to
>> give each module a sense of historical perspective: the hows and whys of a
>> module over time. Sure, there are other reasons too but the history of
>> decisions around a module's path forward seems to me the largest loss if
>> ownership changes hands every 2 months.
>>
>> -Lukas
>>
>>

>> On Feb 20, 2013, at 6:45 AM, William Quiviger <wqui...@mozilla.com>

>> wrote:
>>
>>
>>> On Feb 20, 2013, at 3:40 PM, Gervase Markham <ge...@mozilla.org> wrote:
>>>
>>> On 20/02/13 05:59, Lukas Blakk wrote:
>>>>

>>>>> If the chair of the council is a rotating position, I am a bit
>>>>> concerned about module ownership churn. Most of our module owners
>>>>> seem to get the position and then stay attached to their module(s)
>>>>> for a fairly long time.
>>>>>
>>>>

>>>> Do you think there is a valid distinction here between code and non-code
>>>> modules? Clearly there's advantage to a code module owner being in place
>>>> for a long time. Is that equally true of all non-code modules?
>>>>
>>>
>>> I would argue that it is not equally true for non-code modules.
>>>
>>>>
>>>> In this case, it's effectively that a different peer becomes owner in
>>>> each period, then goes back to being a peer.
>>>>

>>>> than "the current chair" if that position rotates often and I'm not
>>>>> sure what that would look like. Perhaps the current and most recent
>>>>> former chair so that there's some coverage from the past at the same
>>>>> time?
>>>>>
>>>>

>>>> Can someone remind us of the frequency with which the chairmanship
>>>> rotates?
>>>>
>>>
>>> Chairmanship used to rotate on a monthly basis, but starting March 1st
>>> it will be every 2 months.
>>>
>>> - w
>>>
>>

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

[Gervase Markham]

On 20/02/13 19:28, Alina Mierlus wrote:
> I mostly agree with Lukas and Axel's comments. I also don't see the
> "chairman" as a module owner.
> And I don't see the "why?" for a REMO specific module (together with
> its submodules, including Council).

Modules are about either:

a) putting people in charge of stuff; or

b) acknowledging the people who are already in charge of stuff.

This is a case of b). REMO is a big project doing a great deal of stuff,
and is clearly large enough to be its own module. The reason it's
valuable to create one is because it makes it easier for people to see
how the REMO project is run and who is responsible for it.

(Obviously just saying "the chair of the council" is not all that
helpful; as my initial message mentioned, there would need to be either
an email address which automatically reached them, or a link to a page
where it said who the current chair is.)

Gerv

[William Quiviger]

On Feb 21, 2013, at 12:32 PM, Gervase Markham <ge...@mozilla.org> wrote:

> On 20/02/13 19:28, Alina Mierlus wrote:

>> I mostly agree with Lukas and Axel's comments. I also don't see the
>> "chairman" as a module owner.
>> And I don't see the "why?" for a REMO specific module (together with
>> its submodules, including Council).
>

> Modules are about either:
>
> a) putting people in charge of stuff; or
>
> b) acknowledging the people who are already in charge of stuff.
>
> This is a case of b). REMO is a big project doing a great deal of stuff,
> and is clearly large enough to be its own module. The reason it's
> valuable to create one is because it makes it easier for people to see
> how the REMO project is run and who is responsible for it.

Exactly.

>
> (Obviously just saying "the chair of the council" is not all that
> helpful; as my initial message mentioned, there would need to be either
> an email address which automatically reached them, or a link to a page
> where it said who the current chair is.)

Yes. The email of the chair will be an alias: reps-...@mozilla.com. I'll be updating the wiki page shortly and also add a link to https://wiki.mozilla.org/ReMo/Council#Council_Members

- w

>
> Gerv

[Gervase Markham]

On 21/02/13 12:05, William Quiviger wrote:
> Yes. The email of the chair will be an alias: reps-...@mozilla.com.

..org, I would hope :-)

Gerv

[davidweld...@gmail.com]

> Either way, I don't think any module operates in a bubble, success depends
> on interaction. It would be great to have someone from the participation
> metric module help guide Reps tools and practices in that area (if that
> isn't happening already).

Yes, I've been coordinating closely with the Reps program on plans for participation metrics as well as plans for other community building efforts I'm working on.

For example, I've been coordinating with William and Pierros about integrating the community building activities Reps do at events with the arewegrowingyet.com dashboard that currently tracks just online community building efforts.

I think the Reps module proposal makes sense and would definitely encourage close interactions among the different efforts that are encouraging community health and growth.

David

[davidweld...@gmail.com]

> Either way, I don't think any module operates in a bubble, success depends
> on interaction. It would be great to have someone from the participation
> metric module help guide Reps tools and practices in that area (if that
> isn't happening already).

[Gervase Markham]

On 19/02/13 10:45, Gervase Markham wrote:
> The Mozilla Reps program is not covered by the module owner system; we'd
> like to propose some new Activities Modules to cover it. The proposed
> module descriptions are here:
>
> https://wiki.mozilla.org/Modules/Mozilla_Reps

These are now final; an email alias has been created for the ReMo
Council Chair to allow people to contact the owner of the Council module
more easily.

Gerv