| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
William Hubbs schrieb: |
| 5 |
> Here are some thoughts I have wrt this situation: |
| 6 |
> |
| 7 |
> 1. The QA and Devrel projects are directly accountable to the council. |
| 8 |
> This protects against abuse of power since the council can remove |
| 9 |
> people from these projects if they determine that power is being |
| 10 |
> abused. |
| 11 |
> |
| 12 |
> 2. The leads of these projects should be selected by the projects like |
| 13 |
> any other project, but confirmed by the council. |
| 14 |
> |
| 15 |
> 3. Since the leads are confirmed by the council, I don't think it is |
| 16 |
> necessary for them to go back to the council for approval for actions |
| 17 |
> they take. |
| 18 |
> |
| 19 |
> 4. Both of these projects require unique skill sets that most |
| 20 |
> developers may not have, so I don't think electing members of these |
| 21 |
> projects is a good idea. |
| 22 |
> |
| 23 |
> 5. Any actions these projects take can be appealed to the council (This |
| 24 |
> follows from point 1). |
| 25 |
> |
| 26 |
> Thoughts? |
| 27 |
|
| 28 |
These rules sound all ok, but which real problem are they intended to solve? |
| 29 |
|
| 30 |
Is there an actual documented instance where QA or devrel abused their |
| 31 |
power, and which could have been prevented by council confirmation? I am |
| 32 |
aware of wltjr's case, but even from his perspective it sounded more like |
| 33 |
bullying than abuse of power. |
| 34 |
|
| 35 |
If not, what indication exists that makes such abuse of power appear likely |
| 36 |
in the future? |
| 37 |
|
| 38 |
If such a thing has never occured, and there is nothing which indicates |
| 39 |
that it is going to occur, then I think we can drop the rule #2 as it |
| 40 |
introduces only unnecessary bureaucracy. If we start seeing actual abuse of |
| 41 |
power then requiring approval of Council for QA/devrel leads or actions can |
| 42 |
be reconsidered. |
| 43 |
|
| 44 |
|
| 45 |
Best regards, |
| 46 |
Chí-Thanh Christopher Nguyễn |
| 47 |
|
| 48 |
-----BEGIN PGP SIGNATURE----- |
| 49 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 50 |
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ |
| 51 |
|
| 52 |
iEYEARECAAYFAlHDYP0ACgkQ+gvH2voEPRA7hgCdFopvXWhx4jJ0rFwJzm9TLalw |
| 53 |
DvEAn1jFOOQ00O2sm6GD90w+P0P5W1ZH |
| 54 |
=116z |
| 55 |
-----END PGP SIGNATURE----- |
Archives