First off, I love that this conversation is happening and is really constructive with people commenting from everywhere!
I have a few things to add (hope I didn't miss someone already make them!) Alina used the word "normal," I think that is part of the problem. We are Mozilla, we're different!! There are some areas where I would love to see us work more to our values than to what's "normal" or "proven." My pet example is marketing in public. I know some things are easier to do privately, but I'm an idealist and I'd love to see us show how this can be done publicly and successfully! Gerv mentioned training on the culture, I'm glad to see this mentioned again as this is every important (I'm also very sad to hear that somehow talking about it would jeopardize a lauch? I guess this goes to the point above). Many of the people I think aren't being as open as they could be are new(er) and they are being more open than they would be at another job, so they don't even know. It makes them sad to hear they're not being open enough and I don't blame them for that! I once asked what the volunteer community contribution was to a project and the answer I got back was l10n. This answer bothered me a lot, because unless it's an l10n project, then using the l10n community isn't the same as using your team's community, but I don't blame that person or think any malice was intended and I'm sure many people don't realize to think further than l10n because that's what they're used to. I agree, too, I've seen some cases of teams handing off the left over tasks to the volunteers. I think, especially with volunteers, you have to let them do what they're passionate about, what they have the skills to do then fill in the blanks. I like the metaphor that Mozilla should be like a teaching hospital, I think Mitchell said something similar, that we should be trying to make ourselves redundant. Gavin says that we should be guiding people away from low-value projects, but I think we also need to see how we can maximize the value of projects people are passionate about. Thinking about the old release style, sometimes a feature that wasn't in the original plan suddenly came up and was the killer feature for the release. We should make sure people have realistic ideas of the impact of the project, what it would take to make the project high impact, what it would take to get more buy in, but I don't think we should do much discouraging unless the idea is actually flawed and possibly damaging. Regarding employees and trust, I have to disagree. I think we can't get around the idea that when someone is hired Mozilla is implicitly giving them tasks and rewards that they don't have to continually earn, with a long term commitment to those tasks and rewards. Especially in the case with employees instead of contractors. Not many people get fired. I think the solution is to embrace this, hold hiring to this standard, but also make sure part of employee's job description (and trust) is to support volunteers. Again in my idealistic perfect world, all employees are management level and are assisting and enabling the volunteer contributions (yes, I know this isn't really possible in reality, but maybe we can get close). At the engagement work week, I really loved (and I think everyone did) the approaches we took, in terms of having a "yes, and" period in the initial pitches where we didn't criticize but brainstormed and made suggestions. Even more, I think it was really great how the groups were made up across functional teams, focusing on the product, rather than handing a product from team to team as it progressed. I think even in the employee side of the community people can feel just as left out as volunteers do when the team mostly works with itself rather than collaborating across teams. I think changing some processes to work more collaboratively like this will also make it easier to include volunteers. So I guess those last points bring me around to what I think the real solution is, which isn't so much remembering to ask volunteers for help, but making sure the projects are being conceived and planned in the open as much as possible, so volunteers and employees from other teams can be involved from the beginning, and so the team is looking for ideas from volunteers, not just employees to work on. On Fri, Apr 5, 2013 at 2:28 PM, Rubén Martín <[email protected]>wrote: > El 05/04/13 19:14, Gavin Sharp escribió: > > This particular point is a tricky one: "we don't have the resources > > for this project" is often confused with "we don't think we should > > focus the resources that we have on this project". But indeed there is > > an important distinction between those two reasons. Helping guide > > where resources are used, and discouraging contributors (paid staff or > > otherwise) from pursuing low-value projects can be an important role > > for Mozilla leaders. "The community" or "volunteers" are not an > > infinite resource, and even if they were, there can be very real > > coordination/communication costs to losing focus as a group. > The problem is that a project is low-value depending on who look at it. > Probably a project on user education is not important for some but it's > really important for a great number of volunteers... it's tricky, and > for that reason there should be a discussion on reason why something is > high or low value and not just say "we don't have resources". > > With a bit of discussion probably more people would understand why we > should focus in other ones ;) > > Regards. > > -- > Rubén Martín [Nukeador] > Mozilla Reps Mentor > http://www.mozilla-hispano.org > http://twitter.com/mozilla_hispano > http://facebook.com/mozillahispano > > > > _______________________________________________ > governance mailing list > [email protected] > https://lists.mozilla.org/listinfo/governance > > _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
