El 2014-09-11 08:44, Christoph Wickert escribió:
Am Donnerstag, den 11.09.2014, 09:36 -0400 schrieb Josh Boyer:
On Thu, Sep 11, 2014 at 9:23 AM, Christoph Wickert
<christoph.wickert@xxxxxxxxx> wrote:
> Am Donnerstag, den 11.09.2014, 08:16 -0400 schrieb Matthew Miller:
>> On Wed, Sep 10, 2014 at 08:34:05PM -0000, board wrote:
>> > I'll start working on a draft for what that might look like and post it to
>> > the discuss list in the next couple of days.
>>
>> That doesn't mean everyone should wait for me, by the way. :) Particularly,
>> I'd love to hear everyone's ideas for translating
>> https://plus.google.com/+ChristophWickert/posts/UuU81LNZ27F?pid=6045572712375942674&oid=114008335300241090782
>> into a reasonable number of council seats which cover the different areas in
>> a meaningful, representative way.
>
> When I brought up the idea of the council back in 2012, I wanted it to
> be an open group. Groups should be able to send representatives when
> they feel they need a liaison with the rest of the rest of the Fedora
> Project.
>
> Therefor I wanted it to not be limited to the big projects such as
> packagers and ambassadors, which may or may not already have their own
> bodies, but open for every little SIG or WG.
>
> During my presentation at FUDCon Blacksburg [1] Dave then brought up the
> issue of scalability and I think he has an important point. Imagine we
> have representatives of 20 groups and each of them just talks for 3
> minutes...
>
> So I think the size of the group should be somehow limited, at least if
> we decide to have regular phone or IRC meetings. If we go for the lazy
> consensus however, we are probably able to handle more people.
>
> This being said we should have permanent members for the biggest and
> most important groups but also be able to invite representatives from
> other groups if necessary.
>
> Say we had a group of 9 permanent members I propose the following
> permanent representatives (in no particular order)
> 1. Workstation WG
> 2. Server WG
> 3. Cloud WG
> 4. FESCo
> 5. FAmSCO
> 6. QA
> 7. Infrastructure
> 8. Release Engineering
> 9. Marketing
>
> And of course the FPL.
>
> If you are wondering why marketing is in here and think it's
> over-represented: I think we definitely want the marketing team to
> become more important.
>
> Auxiliary members:
> * Design
> * Docs
> * L10n
> * FPC
> * Spins
> * Websites
> * ...
>
> Some of these are already represented as sub-projects of other permanent
> members, e.g. websites is already (kind of) represented by
> infrastructure, but it might be necessary get in touch with somebody
> directly to get shit done.
>
> Summary: For the permanent members, I would like us to think of
> something similar to the release readiness meetings. All relevant
> stakeholders should have a representative.
> For the auxiliary members, ideally we would have a liaison to every
> single group out there and be able to contact them whenever we feel it
> is necessary. And of course they should already be able to contact the
> council at any given point in time.
>
> Questions, comments, rants?
I'm generally agreeable to all of this. It matches much of what I had
in my head when I re-proposed your idea independently. I particularly
like the idea of fixed members from major groups, with the ability to
pull in additional people in advisory roles when needed. Those
advisers don't even need to be from a SIG, but could be subject matter
experts for particular problems, etc.
+1
As Jaroslav said, the problem is probably not decision making but
communicating. I want us to have liaisons to every relevant group.
I agree with all this. This looks more o less like a fluid body that
shapes according the needs. Even can work the other way around. A member
of design team (just because it is on to of the list, may be any other
team) can came up to the permanent body and point out and issue. Thus
became part of the decision/agreement and help implement the solution
with liaison/task-force created for that specific issue.
I think that this will require more talking/communication (which was
already pointed out) within all participants with their team and with
other people in different teams. Which I think it is great, king of Big
Picture. In the other hand may also be overwhelming/time-consuming.
Neville
_______________________________________________
board-discuss mailing list
board-discuss@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/board-discuss
