Organizational structure at Mozilla

Do we have any organizational structure at Mozilla which is visible to the community?
A detailed structure says, who works with the QA Team (example team) and who manage the QA Team? What is the parent team of this QA Team and what are the sub teams of the QA Team?

Having this governance information would help any mozillian, to contact someone related to any particular projects or program easily.

And if the mozillian is not getting the solution for a particular problem from the first point of contact or the first point of contact is unable to follow up, the mozillian can try to escalate that to the higher one.

An Input from @bking @rosana, @williamq or @pierros will be great as they have different hats around. ( list can go on with @r_oVhPfcJCUUC5wbm6i4_C2Q, @couci etc)

Governance and team structure aren’t the same thing.

Also, don’t try to get things from “first point of contact”, but try to work in the open by using public channels.

2 Likes

+1 to what @Pike says. Some groups have tried to publicly document their strutures, e.g. Engagement:

https://wiki.mozilla.org/Engagement

… but they tend to get out of date quickly. It might be worth having some high-level org structure solution, but it would need to map to our internal system to remain up-to-date.

True. But then what I’m hearing here is that some teams don’t have an easy public way to reach them? @pmjcreations?

Yes @nukeador, that is the case.
As @bking said, some teams tried to document their structure.

I can explain things with a use case.

One mozillian some how started contributing as a QA volunteer. He/she got a super mentor, for taking him/her on board. One day the QA mentor, in this case, his/her first point of contact, and unfortunately his/her only available point of contact took a one month break. This mozillian need to get/share an important information, but, he/she doesn’t know to whom need to ping.

In this situation, having this organizational structure, can help a lot.

1 Like

TBH, I don’t think that org structure would help in this case.

A new contributor can’t just go to the next person in the food chain and expect them to mentor in the same way their original mentor did.

A good mentor does get herself or himself out of being a single point of failure, too. Unless you are actually a single point of failure, and then things just fail.

Given the reorgs and shuffles that happened to QA lately, that could have been very much the case, sadly.