On Fri, Jun 15, 2018 at 6:08 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Thu, Jun 14, 2018, 10:42 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> >> On Thu, Jun 14, 2018 at 5:51 PM Till Maas <opensource@xxxxxxxxx> wrote: >> > >> > On Thu, Jun 14, 2018 at 03:57:36PM -0400, Josh Boyer wrote: >> > > On Thu, Jun 14, 2018 at 3:53 PM Randy Barlow >> > >> > > > Downside is that it would be possible (though I'd guess unlikely) for >> > > > all of FESCo to suddenly change to 9 different people and there'd be no >> > > > members who know the current state of things. We would also need to do >> > > > something a little awkward to get into this state since we currently >> > > > have staggered terms. >> > > >> > > The election structure was setup specifically to avoid this problem. >> > > The alternative solutions were all pretty poor. >> > >> > This seems to be a very theoretical problem because it would mean that >> > we have nine times the number of new candidates that we have now and >> > everyone is so unsatisfied with FESCo that only new candidates will be >> > elected. And if there is so deep dissatisfaction, a fresh start might >> > even be a good idea. Also there would still be other people around to >> > provide guidance or there is another problem. >> >> It was a solution to a practical problem when we came up with it. >> Fedora was young, core and extras had just merged. People were >> excited about guiding Fedora at a technical level. We needed the >> structure to ensure we didn't have massive swings in direction on >> technologies and sufficient transfer of knowledge. The overall number >> of contributors was smaller, but the interest level was greater. >> >> I'm not against reworking the election schedule or terms, but it's >> good to know why something was put in place before you change it. >> Dismissing it as theoretical does nothing but make me feel old, which >> is OK because I am. I'm not convinced a change in the election >> structure or term limits is really going to drum up interest in FESCo >> though. The problems we face there are more fundamental than that. >> >> josh > > > > Over the past five years or so, the membership in FESCo has rarely changed except when an existing member voluntarily gives up their seat. The elections rely heavily on name recognition and so being on FESCo is self-reinforcing. This isn't necessarily a bad thing, however. Clearly it has been working for Fedora, since the Project is thriving. Hm. I mean no disrespect by this, but it could also mean that FESCo is somewhat irrelevant to Fedora's current trajectory. It's likely a culmination of turning a crank at this point, with small nudges from FESCo to make sure nothing gets in the gears. I know we do a lot of rubber stamping because process requires it. I'm not sure that's what I'd call thriving, either for FESCo itself or how our project works. I think the reality lies somewhere in the middle though. To be clear, I think Fedora produces an outstanding set of Editions that have continued to work very well. We should be proud of that. That's our "product" though, not our project. > I'd like to suggest a more radical approach then: what if we only hold elections under two circumstances? > > 1) An existing member steps down and announces that a seat is opening. > > 2) A vote of no-confidence is raised for one or more individuals currently serving. In this case, those individuals can also remain on the ballot to retain their seat. The details of the no confidence clause would need to be worked out to avoid constant jeopardy and too frequent elections, but I think that could be feasible. I'd be OK with this, but no-confidence is really hard to nail down. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/RD345JRWBT7D5P2XB2NX6DLYO44HQ4B5/
