| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 07/22/2013 07:05 PM, Rich Freeman wrote: |
| 5 |
> On Mon, Jul 22, 2013 at 6:35 PM, Rick "Zero_Chaos" Farina |
| 6 |
> <zerochaos@g.o> wrote: |
| 7 |
>> The council really doesn't have the ability to just instantly vote on |
| 8 |
>> things outside of a meeting. The transparency of the body requires |
| 9 |
>> announcements about meetings, and their topics, with a reasonable amount |
| 10 |
>> of notice. It simply isn't possible to maintain these things and have |
| 11 |
>> the flexibility to instantly vote on things. Emergency action can be |
| 12 |
>> taken by many bodies, devrel, userrel, but the council is not expected |
| 13 |
>> to be the "quick fix" for things. |
| 14 |
> |
| 15 |
> I find it interesting that the Trustees, which are a legally regulated |
| 16 |
> body, can take action between meetings, but we feel that the Council, |
| 17 |
> which is not a legally regulated body, cannot. Legally the foundation |
| 18 |
> can even take action without any of the trustees present (it just |
| 19 |
> requires a LOT of members to support it). |
| 20 |
> |
| 21 |
> I'm not suggesting that we should just issue rapid decisions in the |
| 22 |
> middle of a flamewar. However, if we feel that all sides of a debate |
| 23 |
> have spoken we can perhaps announce a pending decision on -dev, |
| 24 |
> evaluate any responses, and then vote. Council members who do not |
| 25 |
> feel sufficient time has passed to evaluate the situation can vote to |
| 26 |
> postpone the decision. In order to pass a majority would still be |
| 27 |
> needed, so if 2 people vote aye, 3 vote nay, and 2 vote delay, then we |
| 28 |
> delay until one side or the other obtains a majority (as with any |
| 29 |
> body, the default is basically no action until there is a majority in |
| 30 |
> favor). |
| 31 |
> |
| 32 |
|
| 33 |
I think the real difference is that most of the devs don't care what the |
| 34 |
foundation does as long as it keeps the lights on around here. Most of |
| 35 |
us, on the other hand, seem to care greatly about the development |
| 36 |
process and key decisions around that. If the trustees need to take |
| 37 |
emergency action to keep the lights on I trust them to do the right |
| 38 |
thing. If the council has to take emergency action to allow systemd |
| 39 |
units to be added without maintainer approval.... well, you see how |
| 40 |
stupid that sounds? |
| 41 |
|
| 42 |
- -Zero |
| 43 |
|
| 44 |
> I don't suggest that this should be the ideal method of operation. I |
| 45 |
> just see it as an option. It wasn't even my idea... |
| 46 |
> |
| 47 |
> Rich |
| 48 |
> |
| 49 |
> |
| 50 |
|
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 53 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 54 |
|
| 55 |
iQIcBAEBAgAGBQJR7dTxAAoJEKXdFCfdEflK0l4QAKlVFy6xHHXnIlTzYzciCWvS |
| 56 |
qKq9v9tssIty//FvFYUlSv4cpudbO8jzThp2N9aB+2oMswT6vFaf+JlTIjZj4nvo |
| 57 |
fVW9pRzBPxmyLvQySW4YprpoUFYTKPDkEyxqT2wERPHEehY3mnw5b+6FKmWJRRgs |
| 58 |
v/XPCbuasV+HVHeLu2uIim4YtQcFcpuXF7E9qD7K7CTgUz0ZITDCyJG59N8jxlFE |
| 59 |
8//hVKIxe8LTuRm08WQDFWr4veqOdCyZACGz8/PJP8SeSgJ65kKt7j6i77OywwRe |
| 60 |
TnmcYlR2eHFLtFUd64blFoURLfhirZj/AFknURX7U54mdkXFxLYWYCnBj+ZzQibP |
| 61 |
Lb3h0Uh0DLgDw2QMVDYwfgjueqtmd+urQn+0cAmRs8r8HjQvPJeA7Rwl6KYIC7DG |
| 62 |
rIN7GyYKR5IFX4ISKgy4fZPh37rJ74v52bCNBKtVxRWz8oQpna09m+pQRGdgHXIx |
| 63 |
fbkTGIwiYr+X7cbTx6XBCNXl6KJjZ6hhgjj/EQ77Q+PIms6JebvgwosvF6fYxs/M |
| 64 |
1f+V2tGlHNbYgptoeoi/MTzqE+x1sQZZ0TDm/FImzp+ei4TfzZzUehwdh0fgAoLJ |
| 65 |
KLE7/NBy222NeX8WS8inj/sa0DHE/xSSsgpvKDiUcHFUA3nVGIBmWJqbKfEBYkos |
| 66 |
8gUik9Q03vXz7cwFMi2M |
| 67 |
=NYxW |
| 68 |
-----END PGP SIGNATURE----- |
Archives