----- Original Message -----
From: "Josh Boyer" <jwboyer(a)fedoraproject.org>
To: "Discussions with the Fedora Council and community"
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
> 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
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,
> 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
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
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?)
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
council-discuss mailing list
Thank you for your feedback Josh,
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.