| 1 |
On Sat, Nov 2, 2013 at 6:06 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> I think that the QA team should be given a chance to resolve the issue |
| 3 |
> within the framework of GLEP 48. |
| 4 |
|
| 5 |
++ |
| 6 |
|
| 7 |
> However, the council appointing a project |
| 8 |
> lead would be against the principles of both GLEP 48 |
| 9 |
|
| 10 |
Agree. |
| 11 |
|
| 12 |
> and (more |
| 13 |
> important) GLEP 39. |
| 14 |
|
| 15 |
In what way? I don't think GLEP 39 was really intended to cover |
| 16 |
"special" projects - in fact the whole point of it is that projects |
| 17 |
aren't special. Per GLEP 39 I could start my own "Quality" project if |
| 18 |
I wanted to, as well as my own "Developer Discipline" project too. |
| 19 |
That would of course be silly. Competing projects make sense on |
| 20 |
technical initiatives, but not on administrative ones. |
| 21 |
|
| 22 |
In any case, GLEP 48 already overrides GLEP 39 insofar as team |
| 23 |
composition goes, so the precedent has already been set for the |
| 24 |
Council making these sorts of decisions. |
| 25 |
|
| 26 |
> So maybe the council should rather admit new |
| 27 |
> members to the team. |
| 28 |
|
| 29 |
Not sure how that is any better than just confirming a lead. Are you |
| 30 |
suggesting that we can't have a say in who the lead is, but we can |
| 31 |
appoint any number of sock-puppets to the team? |
| 32 |
|
| 33 |
I really don't want to take action without hearing from the current |
| 34 |
team (assuming they comment). However, I don't see any reason that we |
| 35 |
shouldn't take action if there is a good reason to do so. This isn't |
| 36 |
Wikipedia - we don't need to cite the right combination of policies to |
| 37 |
get something done... |
| 38 |
|
| 39 |
Rich |
Archives