----- Original Message ----- > From: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > To: "Discussions with the Fedora Council and community" <council-discuss@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, April 28, 2015 4:03:41 PM > Subject: Re: A Modest FOSCo Proposal > > On Tue, Apr 28, 2015 at 3:22 PM, Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, Apr 27, 2015 at 03:48:31PM -0400, Remy DeCausemaker wrote: > >> tl;dr - Narrowly define FOSCo as a decision making body to handle > >> budgetary requests from subprojects, and revive/revamp the Fedora > >> Commarch Team. > > > > I'm not opposed to rethinking this, because the previous launch effort > > kind of ran aground. So, thanks for opening this up. > > > > A few initial questions... > > > > Previously, CommArch was a Red Hat internal group. The intention here > > is for the new group with that name to be a _community_ group, right? > > > > Also, if the only point of FOSCo is to handle budgetary requests, why > > not just have that be the Council directly? > Honestly, the reason why I want to narrowly define FOSCo is that FAMSCo has been in a holding pattern waiting for FOSCo to arrive. There is a certain amount of time-sensitivity in maintaining some continuity/momentum for FAMSCo that has been pushing this proposal forward. Currently my understanding of the FAMSCo budget process is as follows ($ in USD): 1) There are a limited number of cardholders who can make purchases in each region. 2) Those cardholders are empowered to spend up to $500 without approval. 3) Purchases above $500 and up to $1999 are required to have 5 votes from FAMSco. 4) Purchases of $2000+ require unanimous support from FAMSCo. I think it would be pretty straight forward to propose to FAMSCo that we s/FAMSCo/Council/g in the above process, and see what they think. My understanding is that FAMSCo has put a lot of effort into making sure each region was basically self-governing, and tried their best to only get involved when major purchases were proposed. I think that FAMSCo would likely be supportive of the council taking over this duty, but we should definitely confirm. > > In your document, I'm unclear if the sections on Delegation, Operating > > Principles, etc., is meant to apply to the New CommArch or to the > > "narrowed FOSCo". I *think* it's meant to be CommArch and doesn't > > address the FOSCo bit, right? In which case, maybe the previous > > question answers itself.... > > A couple of more questions: > > I'm a bit concerned at the size of the delegation pool here. While it > might make sense to include 13 subprojects (really, we have 13??) + 5 > WGs + SIGS + WHOEVER, I'm rather concerned such a large group will > amount to little progress on anything. With large groups, two things > tend to happen. Either everyone thinks someone else is doing $thing, > or there is disagreement how to do $thing and consensus can't be > reached. This Team is less about making decisions, and more about organizing and reporting. Organizing - The Design Team is my best example here, where they have both established leads and new contributors attend meetings where tickets from the issue tracker are brought to the group on a regular basis. Team members then self-select to tackle tasks, often with a mentor identified, within a 2 week window. If that ticket is stagnant, then it gets unassigned and goes to the group again to be reclaimed, or can be "renewed" by the original task-claimer for another 2 weeks. Execution is the primary mode of operation here. Reporting - Mostly, the reason why we need to cast a wide net is to begin to create a firehose of Fedora related content, that can then be curated and broadcast to the appropriate outlets and channels. The idea is to have the Community _____ Team be a central clearinghouse and switchboard that coordinates between all the subprojects, web properties, and groups. There is no central clearing house currently, and this will help Fedora as a whole bigtime. Ideally, most of the "reporting" that gets done by the delegation will be instrumented and automated through tools like zodbot, fedmsg, and eventually Hubs. The synchronous meetings will be available for folks to report on specific activities and claim action items, but I'm hoping most reporting will be done asynchronously. Coalition Building - Organizing often benefits from having a "big tent" strategy, and allowing people to self-select who are interested. Each group will choose a Delegate to represent them within their ranks, but *anyone* is welcome to join the Community ________ Team and participate by claiming tickets and submitting reports. The delegates are there to make sure each part of the whole has at least ONE interested party at the table in the coalition, but more would be helpful. > In a similar vein, how will decisions be reached in this group? > Consensus, majority vote of eligible delegates in tickets, or? This group's primary mode of operation is tackling tasks through tickets, which will fall into the general categories listed in the "Things that the Fedora Community _____ Team Helps With" Section within the proposal. I envision this group being about execution, and being task-oriented, but if there is a need to decide on things other that who is doing what tickets when, then I'd propose consensus as the reigning model, with the FCL holding a tie-breaking vote in the case of a deadlock. I'm absolutely open to other governance suggestions, but I'd prefer to keep it as flat as possible. > It's also unclear to me what the Comm Arch team (committee?) will > actually be doing. The things it can help with that are listed all > seem like "things we've known we could do better at for a while now", > which is great but how is this new team/committee/delegation going to > solve those problems? What new incentive does this body bring to > getting the work done here that isn't present today? You are exactly right. This is a list of things that "we've known we can do better at for a while now." The difference is that the Fedora Infrastructure Team has built an *absolutely amazing* suite of tools that are ready to help us break ground on these new (and old) initiatives. These new tools just need to get connected to people outside of Fedora Infra, who can then help us weave all the parts into a whole. Another difference is we are moving "Community" from being an implicit imperative of everyone, into an explicit mission with goals, a schedule, and tasks, with an identified delegation of representatives. The biggest incentive for people to participate in this Team is that our operating principle is to create a community layer that functions like "middleware" wrapping around existing activity, rather than detracting from the available cycles of your members repeatedly. Currently, if you want your subproject's activity to be communicated, measured, and supported by new contributors and resources, then your subproject has to handle all of that on your own. We want this to feel like "Community DevOps," where we help you build your playbooks and schedule them to run alongside other playbooks synergistically, rather than manually manage each task in your own bubble over and over again :) There will be extrinsic incentives. There will be press. There will be badges. There will be glory. There will be new contributors. Really though, I think that there is a new category of contribution to be had here, and we're supporting a new kind of Fedora contribution that meant to magnify and amplify existing effort, measure it, and draw new energy and resources. If your subproject takes the time to instrument your activity, the Community _______ Team can then help tell your story, identify your gaps, and fill them by cultivating new contributors. > > josh > _______________________________________________ > council-discuss mailing list > council-discuss@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/council-discuss Thank you for your feedback Josh, --RemyD. P.S. - Please forgive my usage of the word "synergistically" in the above text. I realize it is a super-duper-buzzword, but it is the best word to describe this concept of resonant benefit. _______________________________________________ council-discuss mailing list council-discuss@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/council-discuss
