Schedule for Wednesday's FESCo Meeting (2013-09-11)

"J├│hann B. Gu├░mundsson" johannbg at gmail.com
Wed Sep 11 18:38:32 UTC 2013


On 09/11/2013 05:57 PM, Matthew Miller wrote:

>
>> You want to limit the project to three "official default products"
> I don't want to limit the project in that way.
>
> I think these three products are reasonable starting points.

I do not and from my perspective we should only be focusing on what I 
call "FedoraOS" ( core/baseOS )

>   I think _one_
> doesn't work because it's impossible to be all things to all people and we
> also can't (and shouldn't) simply choose one narrow case.

That's the fundamental disagreement I was talking about unlike you I 
think the sub communities that produce their product are the ones that 
should be focusing on this.

>   I also think
> chosing _none_ doesn't work, because there are concrete benefits to having a
> clear direction. So, when the idea of three products (Stephen Gallagher's
> proposal) came up at Flock, that seemed like a reasonable place to start.

The sub communities they themselves will set their own direction, their 
own target audience and their own goals as well be in full control how 
they will try to meet those goal after all they are the ones doing all 
the work necessary to achieve that goal in ( mostly in their spare time 
I might add ).

>
> The respective subgroups will need to define exactly what those products
> look like -- after establishing governing and communication strategies, this
> is their first deliverable. And if working groups other than these three
> want to form and start delivering the same, the board can choose to make
> those "primary" as well, just as they've approved these three initially.
>
>
>> that the community delivers at large, which to me, does not solve
> So, this depends a lot on what you mean by "community at large" here. I want
> Fedora to be inclusive, and the work of all of the subgroups to be
> considered part of the community.

By community at large I mean the entire project made up of ever 
community member sub-community or otherwise.

I did not call this subgroups but sub communities which I though clearly 
indicated they were part of the community at large.

>
>
>> existing problem in our community, narrows down the "scope" of the
>> project as well as hinders innovation and participation while I want
>> to liberate the community from the shackles of the "default" thus
>> finally put the default skeletons to their grave, reduce the
>> "bureaucracy" and allow for more innovation. more products, and
>> faster adoption for us as an community in whole to the constantly
>> changing open source environment and have us contribute shaping that
>> landscape.
> I'm not finding much to disagree with in the specifics here, but I don't
> think I understand some of the more vague parts. What "existing problem in
> our community" in particular do you want to address?

The discrimination problem that has existed this whole time between 
contributors as in not all contributors are treated equal nor their work 
is getting equal presentation from the project.

>   What do you mean by
> narrows down the scope, when we are going from that single default you
> clearly dislike into a broader world? Sure, each of the different products
> will no longer be expected to be all things to all people, but it's about
> _focus_, not excusion.

As see it it is indeed about exclusion since you will be excluding 
everyone that are not part of those three defaults as we are doing now 
with a single default.

>
> Now, about bureaucracy -- I don't think it's overly heavy-handed to require
> clear membership, governence model, and so on. Yes, that's more formal than
> a SIG, but the working groups don't *need* to have a heavyweight process if
> they don't want

The sub communities themselves already have existing governing structure.

The cloud community has theirs, the server community has theirs etc.

We dont need an additional layer on top of that other than arguably what 
Josh recently proposed on the advisory list.

JBG


More information about the devel mailing list