Thanks Kenzie. This set of reasons makes sense to me. My offer to help if/when scope changes stands. --David
On Wed, Feb 17, 2016, 7:25 AM Majken Connor <[email protected]> wrote: > On Tue, Feb 16, 2016 at 11:53 PM, David Ascher <[email protected]> > wrote: > >> I may be missing some background. Can you explain what you would do as >> module owners that you can't do today, >> > Make decisions. > > >> and/or whose code or actions you seek to influence as module owner? >> > > Firstly, the communities who are receiving the resources - we need to > document ownership of these resources (which could be done without a > module) but having a module serves these communities by establishing a > formal process for designating ownership and for changing ownership of > these assets. Having a module for this also empowers communities to have a > say in who maintains this list and makes decisions when there is conflict. > If we are not maintaining the list, or if we're are choosing sides in a way > these communities object to, this list and the module structure gives them > tangible recourse. > > After that we want to have fair, enforceable standards for how these > resources are used (this is all covered in the proposal). We want a plan > for inactive sites, and authority to enact those plans. We want communities > to commit to assigning owners that are responsive when contacted. Again, > using a module gives communities recourse if they disagree with the plans, > or how they are being enforced. Not only by making it clear who are making > these decisions, but again to appeal to the module governance structure if > they feel ownership should be changed. > > Next, there are several groups who have wanted to provide resources to > communities and have no idea how - at least because of the lack of > documented ownership of these sites. Bugs are filed in bugzilla against > community sites, for example for security issues. This module, and the > clear authority structure and communication channel it would provide will > make it very simple for functional teams to communicate with site owners. > It could be security wanting to help patch a vulnerability, WebDev wanting > to help improve a theme, branding wanting to help replace outdated logos. > There are also the Community X groups including, but not only, Community > Ops that could have a great impact servicing sites and growing skills, that > will also rely at least on the documentation of ownership of these sites. > > We also would like to have at least some control over budget. We have had > a plan to move to cheaper options for hosting for over a year now. We're > only now practically looking at moving things over. We don't pretend that > we can just ask teams for money and be able to determine how much we get > and use it without consultation, but right now we aren't even given a > number that we need to stick to. Maybe it's not that we as the owners get > control over budget at all, but at least that there is a clear item on > someone's budget for our things and we're invited to the table to discuss > how much is needed and if it's being well used. > > >> >> 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
