1 |
On 01/05/15 09:06, hasufell wrote: |
2 |
> Dean Stephens: |
3 |
>> Are you then proposing that some entity enforce GLEP 39 constraints? |
4 |
>> (Hint: a mechanism already exists for that.) |
5 |
>> Are you proposing that those constraints be relaxed in some specific way? |
6 |
>> If so, under what conditions? |
7 |
>> If a project has no leads, who is responsible for maintaining project |
8 |
>> roll call? |
9 |
>> If nobody is tasked with keeping the roll call up to date, as much as |
10 |
>> possible given technical constraints, how can a project page be |
11 |
>> determined to be definitely out of date? |
12 |
>> If there are no constraints with regard to a project page being kept up |
13 |
>> to date and no need for project leads for anything at all, what are your |
14 |
>> new constraints for a project to be considered active? |
15 |
>> Am I to keep guessing until you deign to reveal something resembling a |
16 |
>> proposal? |
17 |
> |
18 |
> I said earlier in this thread that it's a cultural problem (in some |
19 |
> degree also a technical, but not as much as people think and I think |
20 |
> some people try to downplay it to just the technical level). |
21 |
> |
22 |
> Rich said that "FOSS tends to be do-acracy", but do-acracy doesn't say |
23 |
> if the project is open to collaboration. Such projects usually end up |
24 |
> being a one-man project (we already have those and this thread is |
25 |
> exactly about them). Do we want gentoo as a whole to be a one-man |
26 |
> project again? |
27 |
> |
28 |
Reductio ad absurdum is itself absurd here, unless you actually have |
29 |
some examples of projects with a single developer who is refusing |
30 |
qualified applicants with whom they can maintain functional collaboration. |
31 |
|
32 |
Do "we" want to force people to work with anyone and everyone who claims |
33 |
any interest, regardless of technical and social mismatches between |
34 |
them? Regardless of whether their professed interest is beneficial to |
35 |
the goals of the project at hand? |
36 |
|
37 |
>> If this is all still about your witch hunt, do kindly consider the |
38 |
>> pocket veto article[1] I had referred you to earlier, it applies. Not |
39 |
>> everyone is necessarily going to want to work with everyone else, |
40 |
>> especially when there is negative personal history or indications that |
41 |
>> the prospective newcomer, to whatever role, is ill suited to that role |
42 |
>> to consider. Even if it is merely a matter of disinterest, if a project |
43 |
>> lead does not want to work with you, trying to force them to will only |
44 |
>> end badly. |
45 |
>> |
46 |
> |
47 |
> You again miss the point and ignore the fact that the council has |
48 |
> already agreed that SEVERAL (I'm not just talking about one) projects |
49 |
> are non-functional in the recent past. |
50 |
And you mistake asking you to make your point for missing what you have |
51 |
actually conveyed so far. |
52 |
|
53 |
Let us review these council findings. What follows is a list of Council |
54 |
meeting summaries for all votes regarding standing projects in the past |
55 |
two years. |
56 |
|
57 |
QA disbanded: |
58 |
http://www.gentoo.org/proj/en/council/meeting-logs/20131112-summary.txt |
59 |
|
60 |
Kolab, GSE and Gentoo/Alt AT disbanded: |
61 |
http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt |
62 |
|
63 |
Regarding the operational scope of the new QA team: |
64 |
http://www.gentoo.org/proj/en/council/meeting-logs/20131210-summary.txt |
65 |
|
66 |
An effectively null mention of the functional scope of QA, no summary: |
67 |
http://www.gentoo.org/proj/en/council/meeting-logs/20140225.txt |
68 |
|
69 |
Regarding games team work flow and scope, not its validity as a project: |
70 |
http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt |
71 |
|
72 |
Regarding games team, again not finding against it as a project: |
73 |
http://www.gentoo.org/proj/en/council/meeting-logs/20141021-summary.txt |
74 |
|
75 |
Another effectively null vote regarding the games team: |
76 |
http://www.gentoo.org/proj/en/council/meeting-logs/20141111-summary.txt |
77 |
|
78 |
With no meeting log nor summary yet posted for the 2014-12-09 meeting. |
79 |
|
80 |
In summary, no projects have been found to be "non-functional" in over a |
81 |
year, none. Prior to that, one active project was forcibly disbanded and |
82 |
three seemingly inactive projects were dissolved. |
83 |
|
84 |
Calling votes taken over a year ago "recent" seems somewhat pushing |
85 |
terminology, especially given your rather emphatic usage of several, |
86 |
which apparently related only to inactive projects. |
87 |
|
88 |
Even aside from it being rather sad that you knew exactly what was meant |
89 |
by "your witch hunt", which implies that you recognize on some level |
90 |
that it at least appears to others to be exactly that. |
91 |
|
92 |
> It's not just about not responding to membership applications (which is |
93 |
> NOT a rejection) which has happened to several gentoo devs and had to be |
94 |
> fixed by the council. |
95 |
It is certainly not acceptance, unless they silently add the applicant |
96 |
to their project page, IRC channel(s) (if applicable), and any relevant |
97 |
restricted access repositories; as such basic logic implies that what is |
98 |
not acceptance is not acceptance. One might even call that a tautology. |
99 |
|
100 |
> It's about being non-collaborative in the sense of |
101 |
> * almost never responding to users |
102 |
> * barely responding to gentoo devs (not just me, even if you think that) |
103 |
> * sometimes not reviewing (I am serious and can give several examples) |
104 |
> ebuild/eclass proposals at all (and don't tell me not reviewing |
105 |
> something is a rejection) |
106 |
> * not keeping a project functional in so many ways that it has to be |
107 |
> brought up to the council (this shouldn't happen... we have |
108 |
> theoretically two projects before this instance: undertakers and ComRel, |
109 |
> but both seem to think it's not within their scope) |
110 |
> |
111 |
Now that you have a problem statement that is not in the form of "the |
112 |
problem is not X", you are half way to making a proposal. |
113 |
|
114 |
> If you think this is something about a personal vendetta, then you |
115 |
> didn't follow the project ML in the last few months. It's not even about |
116 |
> a single person. |
117 |
> |
118 |
Actually, following this mailing list and gentoo-dev is in large part |
119 |
why I have the distinct impression that a personal problem is precisely |
120 |
what is driving your call for still ill-defined reform. |
121 |
|
122 |
> It's about do-acracy and the fact that it doesn't work without a |
123 |
> collaboration model AND mindest. |
124 |
> |
125 |
What are you actually proposing? |
126 |
|
127 |
> And yes... collaboration is also "no, we won't do it that way" or "no, |
128 |
> we do it differently". But it's not about "i don't give two shits what |
129 |
> bonsaikitten thinks" (some users get ComReld for saying similar things |
130 |
> on bugzilla... but if you have enough commits in gx86...) |
131 |
> |
132 |
> |