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
