| 1 |
On 01/04/15 18:27, hasufell wrote: |
| 2 |
> Dean Stephens: |
| 3 |
>> On 12/30/14 09:25, hasufell wrote: |
| 4 |
>>> Dean Stephens: |
| 5 |
>>>> On 12/29/14 15:06, Rich Freeman wrote: |
| 6 |
>>>>> I'll certainly agree that not everything needs a formal project. |
| 7 |
>>>>> However, if a project wants to have authority/autonomy beyond |
| 8 |
>>>>> anything-goes, then it should welcome members and elect a lead |
| 9 |
>>>>> regularly. |
| 10 |
>>>>> |
| 11 |
>>>> There is at least a defensible argument to be made that being able to |
| 12 |
>>>> reject applicants is more important to being able to maintain a coherent |
| 13 |
>>>> project than the often indicated duty to accept anyone who shows interest. |
| 14 |
>>>> |
| 15 |
>>> |
| 16 |
>>> What about projects that don't even reject, but rather ignore |
| 17 |
>>> devs/contributors? |
| 18 |
>>> |
| 19 |
>> If they have a maintained project page, have elected a lead in the past |
| 20 |
>> 12 months, and that lead is otherwise active; take it for what it is: |
| 21 |
>> rejection [1]. Otherwise, they either need to elect a new lead or allow |
| 22 |
>> the project to dissolve, according to GLEP 39 [2]. |
| 23 |
>> |
| 24 |
>>> We tell them to elect a new lead, so we don't have to deal with the |
| 25 |
>>> people who screwed up, but can say "here, they formally are a functional |
| 26 |
>>> project according to a random glep... problem solved". |
| 27 |
>>> |
| 28 |
>>> |
| 29 |
>> So, the document specifying the organizational structure of Gentoo as a |
| 30 |
>> whole [2, again] is just "a random glep" now? Is anyone supposed to take |
| 31 |
>> that rhetoric seriously or were you attempting to use humor? Either make |
| 32 |
>> a concrete proposal to update or entirely supersede the existing project |
| 33 |
>> structure or work within it, merely complaining about it is pointless. |
| 34 |
>> |
| 35 |
> |
| 36 |
> You did not get the point. The point is that the problem is not the GLEP |
| 37 |
> in the first place. By forging just the GLEP, you will not get the |
| 38 |
> problem solved. |
| 39 |
> |
| 40 |
Are you then proposing that some entity enforce GLEP 39 constraints? |
| 41 |
(Hint: a mechanism already exists for that.) |
| 42 |
Are you proposing that those constraints be relaxed in some specific way? |
| 43 |
If so, under what conditions? |
| 44 |
If a project has no leads, who is responsible for maintaining project |
| 45 |
roll call? |
| 46 |
If nobody is tasked with keeping the roll call up to date, as much as |
| 47 |
possible given technical constraints, how can a project page be |
| 48 |
determined to be definitely out of date? |
| 49 |
If there are no constraints with regard to a project page being kept up |
| 50 |
to date and no need for project leads for anything at all, what are your |
| 51 |
new constraints for a project to be considered active? |
| 52 |
Am I to keep guessing until you deign to reveal something resembling a |
| 53 |
proposal? |
| 54 |
|
| 55 |
If this is all still about your witch hunt, do kindly consider the |
| 56 |
pocket veto article[1] I had referred you to earlier, it applies. Not |
| 57 |
everyone is necessarily going to want to work with everyone else, |
| 58 |
especially when there is negative personal history or indications that |
| 59 |
the prospective newcomer, to whatever role, is ill suited to that role |
| 60 |
to consider. Even if it is merely a matter of disinterest, if a project |
| 61 |
lead does not want to work with you, trying to force them to will only |
| 62 |
end badly. |
| 63 |
|
| 64 |
> And I have been very specific indeed. |
| 65 |
> |
| 66 |
> |
| 67 |
Where, pray tell? |
| 68 |
|
| 69 |
The closest that you appear to have come to a concrete suggestion in |
| 70 |
this entire discussion is "No, you don't need a project lead. You can |
| 71 |
just say any member can speak for the whole project at any time." |
| 72 |
Is that supposed to be across Gentoo as a whole? |
| 73 |
If so, what about teams that actually want a designated external |
| 74 |
interface or technical decision maker? Are they just to individually |
| 75 |
reply "ask the person we decided to fill the role of lead, but we can't |
| 76 |
call them that because hasufell didn't like the terminology"? |
| 77 |
If not, how, exactly is that decision to be formally reached, and |
| 78 |
published, so that other projects can know that that is actually the |
| 79 |
intended interface for a given project? |
| 80 |
What about rescinding that decision? |
| 81 |
Is publishing it in their project pages enough? |
| 82 |
|
| 83 |
A the moment what, exactly, is stopping a project from electing every |
| 84 |
member as a co-lead, or a figurehead lead who leaves a note in their |
| 85 |
project page that anyone in the project can respond to anything for the |
| 86 |
project as a whole? (Nothing, in case you were wondering.) How would |
| 87 |
that functionally differ from what you have so vaguely suggested so far? |
| 88 |
(It wouldn't.) |
| 89 |
|
| 90 |
In short: what exactly are you proposing and could it be done without |
| 91 |
adding new rules? |
| 92 |
|
| 93 |
[1] http://en.wikipedia.org/wiki/Pocket_veto |
Archives