I may be missing some background. Can you explain what you would do as module owners that you can't do today, and/or whose code or actions you seek to influence as module owner?
On Tue, Feb 16, 2016, 7:44 PM Majken Connor <[email protected]> wrote: > > > On Tue, Feb 16, 2016 at 4:04 PM, David Ascher <[email protected]> > wrote: > >> Thanks Kensie -- >> >> I wholeheartedly support the general idea of trying to bring some >> cohesion to the systems that still allow decentralized expression by >> volunteers of Mozilla in their local context. We can and should make it >> easier for people to create web presences and collaborative spaces where >> they can communicate with each other, publish, build software, advocate, >> etc. >> >> Ideally this happens in a way that combines local customization and deep >> localization while neither requiring that everyone develop all of the >> skills needed to make world-class websites, and while providing >> coordination support so that activities in one location are effectively >> cut-off from activities elsewhere. >> >> Ideally this is also a system that makes it easy for there to be >> multi-way coordination between staff and volunteers, between locations, >> between people interested in a topic regardless of location or staff status. >> >> If this is the kind of thing you're talking about, I'm 100% in support, >> and I think the scope is broader than just technical website support. >> >> I suggest we separate the skills training benefits from the service >> definition and delivery models. The "what" of the service should be >> determined by a crisp analysis of what community activities make sense to >> encourage & facilitate -- it could be websites, it could be other things -- >> and the skills needed to implement those could range from design frameworks >> to security auditing, ops or even social media management and marketing. >> Regardless, I'm sure there will be opportunities for skills development to >> happen as part of service delivery. >> >> With that frame, it feels to me like defining a module isn't the obvious >> next step. I'd be more keen in an approach that, without needing a priori >> "authority", gathers a set of stakeholders who can articulate a vision & >> plan, identify "business needs" (including the needs of the local >> communities), and deliberately ignores how things are happening today. We >> can then map those needs to systems that we have and may want to adapt >> (including the current community websites and community ops, and the >> systems that IT are currently providing), or systems we need to build anew. >> >> I'm happy to help. >> >> --david >> >> > I have some objections here. First of all is the scope creep. It would be > great to do more, but just because it would be great to do more doesn't > mean that all of it should be done as a whole. We have real resources that > we're providing to real communities that frankly have been provided very > poorly for the past year because of the lack of structure and authority. I > don't see why this module can't exist, and then be swallowed up by a larger > module as such a program expands. As it is the scope here is pretty broad. > I'm sure everyone reading this understands that more than webdev goes into > a good website. We have included things like security audits, and branding > updates in our proposals. Branding tasks are left off of the initial > roadmap because consulting with Branding, they're in the midst of some > reorganizing and can't at the moment tell us what sorts of standards they > would suggest for sites. > > Also, a priori authority is necessary. Especially with volunteers. A staff > member has a place in the org chart and the authority structure is built > in, even if it's not explicit for a specific project. This is lacking for > volunteers and as I said, has been blocking those of us managing the > delivery of these resources from doing the kind of job we'd be proud of. If > you have a suggestion for providing us the authority to do this planning > work besides a module that would be worth considering. We can redesign what > services should happen, but we also can't ignore the ones that already > exist. One of the first tasks we plan to undertake is documenting a > definitive list of the stakeholders on the communities side, necessary work > if we're going to revisit entirely what value decentralized community sites > provide, and how they should exist. > > Basically it feels like this - we've been providing a product, with an > entirely volunteer team, and we're asking to officially be made owners of > the product, and you're suggesting that before that happens, the product > should be entirely revisited and reevaluated. Can we not do that as owners > of the product? > > I would be interested in discussing this more and better understanding > what you have in mind, but we'd also want assurances that formulating a new > approach will actually progress, and that we'd be given real authority in > these discussions, and to improve the services that are currently being > provided until such a time as they're being replaced. > > _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
