1 |
On Sun, Aug 14, 2011 at 7:12 AM, Markos Chandras <hwoarang@g.o> wrote: |
2 |
> Quite a few of you know that Council acts as a court in case a developer |
3 |
> has unresolved disputes with Devrel or when he is not happy with a |
4 |
> Devrel's decision. The problem is that having the same people in the |
5 |
> Council and in Devrel makes no sense since the same people will vote |
6 |
> twice on that matter. |
7 |
|
8 |
So, the way I view it is the Council is the elected body elected by |
9 |
the Devs to govern the Devs. If they feel the best way to resolve |
10 |
disputes is to have Devrel first hear them then that is fine. If they |
11 |
want to personally hear all disputes and have no avenue of appeal |
12 |
whatsoever that is fine too. If they want to take turns hearing |
13 |
disputes and then only hear appeals if there is a majority vote to |
14 |
even hear the appeal in the first place, that is fine too. |
15 |
|
16 |
If Devs don't like the way it is being done, they can always elect |
17 |
somebody else. If a Dev doesn't like how they were treated they can |
18 |
ask all the other devs to elect somebody else to reinstate them, fork |
19 |
the project, or whatever. |
20 |
|
21 |
All that said, I think the current system works fine and see no need |
22 |
to change it. I'd view the Council as being the body that ultimately |
23 |
makes all DevRel decisions - they just have delegated this |
24 |
responsibility and only step in if needed. |
25 |
|
26 |
For these reasons, I see no reason with having overlapping membership |
27 |
- we're a community and we govern ourselves. The Council is elected |
28 |
by the community to speak for the community, and they're allowed to |
29 |
speak even if they've done so already. |
30 |
|
31 |
For the same sorts of reasons I also see no issue with having |
32 |
overlapping Council and Trustee membership (obviously allowing that |
33 |
the Bylaws would need to be amended if a majority of foundation |
34 |
members agreed with me). I do see the value in having more |
35 |
participation, but not the requirement. |
36 |
|
37 |
Rich |