| 1 |
On 28/06/18 18:24, Rich Freeman wrote: |
| 2 |
> On Thu, Jun 28, 2018 at 12:14 PM Michał Górny <mgorny@g.o> wrote: |
| 3 |
>> a. the Council decision in question is final (i.e. a general |
| 4 |
>> resolution can not be used to bypass the Council), |
| 5 |
> One question that this brings up in my mind is the duration of these |
| 6 |
> decisions, because Council decisions are never really final. The |
| 7 |
> Council can override its own decisions, or the decision of a prior |
| 8 |
> Council. |
| 9 |
> |
| 10 |
> Presumably you wouldn't want the current Council to be able to |
| 11 |
> override a GR, but how about a subsequent one? A lot of decisions are |
| 12 |
> made on the basis of some context that could change. |
| 13 |
> |
| 14 |
> To use your example, suppose there is a GR to make OpenRC the default |
| 15 |
> service manager. Great. What happens in 10 years when it makes sense |
| 16 |
> to make some new service manager the default? Normally such a |
| 17 |
> decision wouldn't even require a Council vote, but if the previous GR |
| 18 |
> has no expiration, then does that mean that another GR is required to |
| 19 |
> make a decision that may not be as controversial in the future? |
| 20 |
> |
| 21 |
> To use a different example, consider GLEP 39. Many consider GLEP 39 |
| 22 |
> to be special and one that the Council cannot modify, but on the flip |
| 23 |
> side there is currently no real defined process for changing it. |
| 24 |
> (Perhaps GRs will become such a mechanism.) The result is that |
| 25 |
> sometimes changes that might make sense don't really get considered |
| 26 |
> because nobody feels empowered to make it happen. |
| 27 |
> |
| 28 |
> In any case, my point is mainly that the GR GLEP ought to indicate one |
| 29 |
> way or another how a GR can be modified. Presumably a GR can always |
| 30 |
> be used to modify a previous GR. However, do we want to relax things |
| 31 |
> further, such as by allowing GRs to be overriden by Council if there |
| 32 |
> has been a Council election in the interim? |
| 33 |
> |
| 34 |
> My last comment is more philosophical. I do support the concept |
| 35 |
> behind this, but I do want to note that it is a lot easier to vote for |
| 36 |
> something to happen than to actually make it happen. If devs |
| 37 |
> consistently vote for Council members who support position A, but then |
| 38 |
> vote via GR to impose position NOT A, it creates a bit of |
| 39 |
> organizational schizophrenia as there really is no executive process |
| 40 |
> to appeal council decisions and thus you end up tasking people to |
| 41 |
> execute a policy they don't actually agree with, as volunteers. The |
| 42 |
> likely result will be half-hearted at best, even if no outright |
| 43 |
> defiance takes place. So, this is a mechanism that will need to be |
| 44 |
> used carefully, but I think having it available as a recourse is |
| 45 |
> better than not having it available. |
| 46 |
> |
| 47 |
I think its about having a mechanism *to* do something, rather than |
| 48 |
necessarily have to use it. A bit like ComRel's existence, etc .. its |
| 49 |
there as a Last Resort when all other methods have failed, rather than a |
| 50 |
go-to method for causing discourse. If any such mechanism is being used |
| 51 |
regularly (or abused) then the status quo needs re-evaluating ... |
Archives