| 1 |
Dean Stephens: |
| 2 |
> On 01/04/15 18:27, hasufell wrote: |
| 3 |
>> Dean Stephens: |
| 4 |
>>> On 12/30/14 09:25, hasufell wrote: |
| 5 |
>>>> Dean Stephens: |
| 6 |
>>>>> On 12/29/14 15:06, Rich Freeman wrote: |
| 7 |
>>>>>> I'll certainly agree that not everything needs a formal project. |
| 8 |
>>>>>> However, if a project wants to have authority/autonomy beyond |
| 9 |
>>>>>> anything-goes, then it should welcome members and elect a lead |
| 10 |
>>>>>> regularly. |
| 11 |
>>>>>> |
| 12 |
>>>>> There is at least a defensible argument to be made that being able to |
| 13 |
>>>>> reject applicants is more important to being able to maintain a coherent |
| 14 |
>>>>> project than the often indicated duty to accept anyone who shows interest. |
| 15 |
>>>>> |
| 16 |
>>>> |
| 17 |
>>>> What about projects that don't even reject, but rather ignore |
| 18 |
>>>> devs/contributors? |
| 19 |
>>>> |
| 20 |
>>> If they have a maintained project page, have elected a lead in the past |
| 21 |
>>> 12 months, and that lead is otherwise active; take it for what it is: |
| 22 |
>>> rejection [1]. Otherwise, they either need to elect a new lead or allow |
| 23 |
>>> the project to dissolve, according to GLEP 39 [2]. |
| 24 |
>>> |
| 25 |
>>>> We tell them to elect a new lead, so we don't have to deal with the |
| 26 |
>>>> people who screwed up, but can say "here, they formally are a functional |
| 27 |
>>>> project according to a random glep... problem solved". |
| 28 |
>>>> |
| 29 |
>>>> |
| 30 |
>>> So, the document specifying the organizational structure of Gentoo as a |
| 31 |
>>> whole [2, again] is just "a random glep" now? Is anyone supposed to take |
| 32 |
>>> that rhetoric seriously or were you attempting to use humor? Either make |
| 33 |
>>> a concrete proposal to update or entirely supersede the existing project |
| 34 |
>>> structure or work within it, merely complaining about it is pointless. |
| 35 |
>>> |
| 36 |
>> |
| 37 |
>> You did not get the point. The point is that the problem is not the GLEP |
| 38 |
>> in the first place. By forging just the GLEP, you will not get the |
| 39 |
>> problem solved. |
| 40 |
>> |
| 41 |
> Are you then proposing that some entity enforce GLEP 39 constraints? |
| 42 |
> (Hint: a mechanism already exists for that.) |
| 43 |
> Are you proposing that those constraints be relaxed in some specific way? |
| 44 |
> If so, under what conditions? |
| 45 |
> If a project has no leads, who is responsible for maintaining project |
| 46 |
> roll call? |
| 47 |
> If nobody is tasked with keeping the roll call up to date, as much as |
| 48 |
> possible given technical constraints, how can a project page be |
| 49 |
> determined to be definitely out of date? |
| 50 |
> If there are no constraints with regard to a project page being kept up |
| 51 |
> to date and no need for project leads for anything at all, what are your |
| 52 |
> new constraints for a project to be considered active? |
| 53 |
> Am I to keep guessing until you deign to reveal something resembling a |
| 54 |
> proposal? |
| 55 |
|
| 56 |
I said earlier in this thread that it's a cultural problem (in some |
| 57 |
degree also a technical, but not as much as people think and I think |
| 58 |
some people try to downplay it to just the technical level). |
| 59 |
|
| 60 |
Rich said that "FOSS tends to be do-acracy", but do-acracy doesn't say |
| 61 |
if the project is open to collaboration. Such projects usually end up |
| 62 |
being a one-man project (we already have those and this thread is |
| 63 |
exactly about them). Do we want gentoo as a whole to be a one-man |
| 64 |
project again? |
| 65 |
|
| 66 |
> |
| 67 |
> If this is all still about your witch hunt, do kindly consider the |
| 68 |
> pocket veto article[1] I had referred you to earlier, it applies. Not |
| 69 |
> everyone is necessarily going to want to work with everyone else, |
| 70 |
> especially when there is negative personal history or indications that |
| 71 |
> the prospective newcomer, to whatever role, is ill suited to that role |
| 72 |
> to consider. Even if it is merely a matter of disinterest, if a project |
| 73 |
> lead does not want to work with you, trying to force them to will only |
| 74 |
> end badly. |
| 75 |
> |
| 76 |
|
| 77 |
You again miss the point and ignore the fact that the council has |
| 78 |
already agreed that SEVERAL (I'm not just talking about one) projects |
| 79 |
are non-functional in the recent past. |
| 80 |
It's not just about not responding to membership applications (which is |
| 81 |
NOT a rejection) which has happened to several gentoo devs and had to be |
| 82 |
fixed by the council. |
| 83 |
It's about being non-collaborative in the sense of |
| 84 |
* almost never responding to users |
| 85 |
* barely responding to gentoo devs (not just me, even if you think that) |
| 86 |
* sometimes not reviewing (I am serious and can give several examples) |
| 87 |
ebuild/eclass proposals at all (and don't tell me not reviewing |
| 88 |
something is a rejection) |
| 89 |
* not keeping a project functional in so many ways that it has to be |
| 90 |
brought up to the council (this shouldn't happen... we have |
| 91 |
theoretically two projects before this instance: undertakers and ComRel, |
| 92 |
but both seem to think it's not within their scope) |
| 93 |
|
| 94 |
If you think this is something about a personal vendetta, then you |
| 95 |
didn't follow the project ML in the last few months. It's not even about |
| 96 |
a single person. |
| 97 |
|
| 98 |
It's about do-acracy and the fact that it doesn't work without a |
| 99 |
collaboration model AND mindest. |
| 100 |
|
| 101 |
And yes... collaboration is also "no, we won't do it that way" or "no, |
| 102 |
we do it differently". But it's not about "i don't give two shits what |
| 103 |
bonsaikitten thinks" (some users get ComReld for saying similar things |
| 104 |
on bugzilla... but if you have enough commits in gx86...) |
Archives