| 1 |
Rich Freeman: |
| 2 |
> |
| 3 |
> Some options open to the council are: |
| 4 |
> 1. Let the games project keep its policy, and anybody who wants to |
| 5 |
> change this has to join the project and call for elections (the |
| 6 |
> council can shoe-horn members onto the project if necessary). |
| 7 |
|
| 8 |
You want to force-push members into a team while "preserving" the old |
| 9 |
structure? That calls for trouble. |
| 10 |
|
| 11 |
> 2. Directly tweak games policy but preserve the project and its |
| 12 |
> scope. So, games would still have to adhere to games project policy, |
| 13 |
> but the Council might change specific policies (use of eclass, group, |
| 14 |
> etc). |
| 15 |
|
| 16 |
That's contradictory, IMO. You are practically telling the games team |
| 17 |
"your policies suck, so we just changed them". That doesn't really mean |
| 18 |
they preserve their scope. |
| 19 |
|
| 20 |
> 3. Restrict the games project scope, such as giving it authority if |
| 21 |
> the package maintainer elects to put it in the games herd. |
| 22 |
|
| 23 |
This calls for trouble as well and will cause massive inconsistency. |
| 24 |
|
| 25 |
> 4. Do nothing. |
| 26 |
> |
| 27 |
|
| 28 |
Pretty common these days, but what about |
| 29 |
|
| 30 |
5. Have undertakers check for slacking project leads and accept related |
| 31 |
complaints. If a project has a slacking lead, then the project should be |
| 32 |
given a (long) deadline to fix it. If they don't fix it, then they |
| 33 |
should be disbanded. A project cannot function properly without an |
| 34 |
active lead (unless the project structure defines that there is no lead |
| 35 |
anyway). |
Archives