1 |
Rich Freeman: |
2 |
> On Mon, Dec 29, 2014 at 2:34 PM, hasufell <hasufell@g.o> wrote: |
3 |
>> Anthony G. Basile: |
4 |
>>> |
5 |
>>> I'd like to add a discussion on glep 39. In particular, under |
6 |
>>> specifications we have: |
7 |
>>> |
8 |
>>> "It may have one or many leads, and the leads are selected by the |
9 |
>>> members of the project. This selection must occur at least once every 12 |
10 |
>>> months, and may occur at any time." |
11 |
>>> |
12 |
>> |
13 |
>> That requirement imposes a specific structure on projects. There are |
14 |
>> ways to have a functional project without any lead. |
15 |
>> |
16 |
>> So that phrase should be removed altogether. |
17 |
>> |
18 |
> |
19 |
> I think we need to step back and think about why we have projects. |
20 |
> The whole point of projects is to have something in-between the |
21 |
> Council and anything-goes. So, if you want to know whether doing xyz |
22 |
> is acceptable for Python modules, you can ask the Python project. If |
23 |
> you REALLY disagree you can then complain to the Council, but they're |
24 |
> probably going to just side with the Python project since that is the |
25 |
> whole reason for having a Python project. |
26 |
> |
27 |
> Well, since projects are inanimate concepts you can't actually ask |
28 |
> them questions - you need people to talk for them. So, if 3 people on |
29 |
> the Python project say one thing, and 3 others say something else, |
30 |
> then what IS the opinion of the Python project? To settle that we |
31 |
> have project leads. |
32 |
> |
33 |
|
34 |
No, you don't need a project lead. You can just say any member can speak |
35 |
for the whole project at any time. Whether that works or not, is a |
36 |
different thing, but it's a valid model. |
37 |
Decisions can be reached by whatever method you want, with or without a |
38 |
lead. |
39 |
|
40 |
What matters is that the project is _functional_ and _responsive_. How |
41 |
they do that should be up to the and should not be specified anywhere. |
42 |
|
43 |
> I think that some of what sparked this question is that some projects |
44 |
> are fairly non-responsive, and devs don't feel at liberty to make |
45 |
> commits to packages under the authority of that project. IMHO the |
46 |
> simplest solution here is to tell people to just announce their |
47 |
> changes and go ahead and make them if there are no objections. The |
48 |
> onus has to be on the person blocking change to prevent it, unless we |
49 |
> want to fossilize. Of course, anybody can always go to the Council |
50 |
> for help, but the point isn't to micromanage every little decision |
51 |
> anybody wants to make. |
52 |
> |
53 |
|
54 |
Yeah, that's your diplomatic approach, but it doesn't work. |