[FAmSCo] move on with FOSCo

[S.Kemter]

Hi,

adding Remy again as he asked for it long time ago in this thread

2016-03-17 0:55 GMT+07:00 Christoph Wickert <christoph.wickert at gmail.com>:

> 2016-02-18 2:02 GMT+01:00 S.Kemter <sirko.kemter at gmail.com>:
> >
> > First of all, wow just 3 weeks in the moderation queue :D
>
> Wow, just 10+ years of using mailing lists and you still don't get it. ;)
>
> SCNR, but you really should know this list is subscribers-only, so you
> need to use your subscribed address. You can look it up in every mail
> you get from the list. I even told I even told you which address I
> subscribed and where to change it if necessary. You your sarcasm is
> completely inappropriate. It's entirely your fault that your mails
> were stuck in the queue.
>
> And while we are at it: I really would appreciate if we all followed
> https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> > Second, I dont think its a good idea, that FAmSCo + (lets call them)
> > delegates, discuss that thing that are to many cooks and they get no soup
> > out on the end.
>
> Please bear with me, but I'm having problems following you. What
> delegates are you speaking of in this context?
>
> As FOSCo is to replace FAmSCo, there would not be any delegates in
> addition to FAmSCo but the delegates of FOSCo would replace the
> elected members of FAmSCo. By appointing delegates, we want to get
> back to a more meritocratic approach. This does not necessarily mean
> we will never have elections any more, we could have some elected
> representatives, too. The council has 2 elected seats.
>
> > Third, when it comes to the tasks of FOSCo. It must when it shall replace
> > FAmSCo take over his responsebilities, as I wrote before to say we have
> > delegated everything down to the regions doesnt work. We have to ensure
> that
> > FOSCo can take over this responsebility as well the leading role for the
> > Ambassadors as well.
>
> Not sure if I understand you right.
>
> In the past, we tried hard to delegate responsibilities down to the
> regions for a variety of good reasons:
> 1. People from the regions know best what they need.
> 2. Because of cultural and economical differences, we cannot enforce
> the same reasons globally. A limit that is perfectly fine for peer
> approval in EMEA or NA is probably way to high for APAC or LATAM.
> Again, the regions know best, what is right for them here.
> 3. If something does not work out, the people from the regions can
> easily change the process.
> 4. The more impact people have, the more motivated they are. It's hard
> to find a treasurer, a community credit-card holder or simply
> ambassadors to run an event, when they have no say whatsoever.
> 5. An open organization like Fedora is subject to constant change,
> even when there are no changes in governance or structure. People come
> and go and we need flexibility to adopt to changes.
>
> ASAICS delegating responsibility for the budget process and guidelines
> to the regions has worked out fine. All regions defined their own
> approval guidelines and reported back to FAmSCo. After a little back
> and forth between some of the regions and FAmSCo, we approved the
> guidelines.
>
> So on the process side we are good, but that doesn't mean we are good
> with the budget. Making a budget and keeping it updated requires time
> and effort. Unfortunately we have a lack of manpower in some regions
> (see #5), but that does not mean that the process and everything else
> FAmSCo did throughout the past years was wrong.
>
> So for me it boils down to two questions:
> * What tasks is FOSCo supposed to handle? Note this question might
> impact how FOSCo is constituted, so we need to discuss composition and
> duties together.
> * Global vs. regional: for the reasons outlined above, I'm a big fan
> of keeping things simple and local. But even I see there are some
> things that need to be defined on a global level, e.g. the deadlines.
> They are set by Red Hat, so we could not even change them on a global
> level. But generally speaking everything should be as simple and local
> as possible and only as hierarchic as necessary.
>
> > and last, we have to make some other decisions according to the
> Ambassadors
> > program before we transfer to FOSCo
>
> I agree we should think this through and discuss all open questions
> before we make decisions. I'm sure we have, there is plenty of stuff
> to be discussed. If you have anything particular in my mind, I'm
> looking forward to hear it.
>


First thing I have to say its unbelievable, first you say FOSCo is simple a
replacement and then you coming and say, you dont know what FOSCo is
supposed to do. Next thing I never said, delegate responsebilities to the
regions is bad, but as far as I see it doesnt work as it should be. Best
example APAC, there is been no meeting since, October to decide over some
tickets, the last tickets was all peer reviewed by a FAmSCo member, so do
you wanna say it works? Dont you see the problem with? Its to solve, who in
FOSCo can have that right in the future? Its not about a no say or such
nonsense, its about some problems we face in reality. The problem how I see
it is very simple, after me the deluge. Nobody looks if the proposed thing
works, it worked well for a while in EMEA but looking to the other regions,
I see it working not so well. So adaption might be needed. FAmSCo is
furthermore a structure who should watch that the found guidlines are
putted to action in the right way.

I repeat, FAmSCo is just responsible to ensure, that the remaining tasks
FAmSCo has can be taken over from future FOSCo, it is not responsible to
demand how this new committee shall look like. That has to be found out in
a discussion with all involved groups! And its even not our task to decide,
which groups shall be involved, its up to them!

br gnokii




Best regards,
> Christoph
> _______________________________________________
> famsco mailing list
> famsco at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/famsco
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/famsco/attachments/20160320/010bda29/attachment.html>